secdev
Preventing problems with segments out of order
Brief description
I detected an "out-of-order" TCP segment in the trace, could make the TCPSession stop inmediatly.
The fix is pretty simple, some out of order segments could generate a sequence number < 0, that make the StringBuffer used to collect all the data from the segments raises an error. To prevent it, we just check the seq number is > 0 before to continue with the append of the data.
The checks are not working because the last commit to the master branch does not pass all the tests: https://github.com/secdev/scapy/commit/4f42d2522915312ba2bbfb4c434a13ae9fc9ec8b
I get the point although I'm not sure if the behavior in this case will be intended :/
What do you mean with "Intended"? If a tool is running the "sniff" function with TCPSession and it receives an "out-of-order" TCP segment, it will crash inmediatly. Under my point of view, I think is better to manage that, instead to stop the execution abruptly.
An "out-of-order" TCP segment breaking TCPSession? Weird because the whole reason to use TCPSession is to reorder the segments that are out-of-order... Oh wait it's not doing its job at all because: https://github.com/secdev/scapy/blob/master/scapy/sessions.py#L323
Hi @shrddr, The problem is not when the packet is missing, in that case nothing wrong must happen. The problem is when the sequence number is invalid (<0 after calculus).
This sounds like a fun and useful bug. Will try to replicate and report back.
I tested tonight, got this:
ValueError: Incorrect type of value for field seq:
struct.error('argument out of range')
To inject bytes into the field regardless of the type, use RawVal. See help(RawVal)
Set [TCP].seq = -3. Scapy did let me do this, but upon trying to assemble into something useful scapy throws an Exception. Can you produce a pcap that will crash scapy @plutec via a sniff()?
Hi @stryngs Here is a video I made in February and the code to reproduce the error (included the pcap): https://github.com/plutec/scapy_poc
Regards,