[Snort-users] decode.c:DecodeTCP

Martin Roesch roesch at ...421...
Thu Jan 18 03:18:04 EST 2001


Damn, that checksum is valid?  That's the most screwed up packet I've
seen in a while.  IMHO, the IP stack code listed below is asking for
trouble if that packet really is truncated, you could easily walk off
the end of your buffer if you're not careful there....

    -Marty

Phil Wood wrote:
> 
> Folks,
> 
> I've noticed some interesting packets on the net which apparently actually
> work in most TCP stacks.  There common feature is the following:
> 
>    The "Data Offset" is less than 5.
> 
> FYI:
> 
>    From RFC 793 (TRANSMISSION CONTROL PROTOCOL)
>    "  Data Offset:  4 bits
> 
>        The number of 32 bit words in the TCP Header.  This indicates where
>        the data begins.  The TCP header (even one including options) is an
>        integral number of 32 bits long.
>    "
> 
> I'd like you folks with kernel source to take a look at how your OS would
> handle a packet with a TCP data offset less than 5.
> 
> Mine essentially says for input packets:
> 
>   int length=(th->doff*4)-sizeof(struct tcphdr);
>   ...
>   while(length>0) {  <=== here we only deal with offsets greater than 5
>     ... process any tcp options.
>   }
>   ... now go on and find the data (using sizeof struct tcphdr + any size of
>       any options)
> 
> There is some old tried and true Internet phrase running around inside
> my head about being somewhat generous in what you accept and fastidious
> in what you spew into the Internet.  What we have below is a piece of shit
> from stock.entrypoint.com*.( Data Offset [OFF] = 1) that will probably work
> in the Internet because of that old maxim.  However, the owners should move
> on to a better platform.  As far as I can tell my linux 2.[2-4]* systems
> dish out well crafted headers.
> 
> * The length variable mentioned above will be negative for the following packet
> seen in the wild.
> 
>               RFC791: INTERNET PROTOCOL, September 1981
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | VER=4 | IHL=5 | ROU | | | | | | Total Length = 1500           |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Identification = 7632         | |D| | Fragment Offset = 0     |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |    TTL=57     | Protocol = 6  | Header Checksum = 45583       |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Source Address  = 205.228.184.4                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Destination Address  = 172.16.1.2                        |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         RFC793: TRANSMISSION CONTROL PROTOCOL, September 1981
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Source Port = 80              | Destination Port = 3417       |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Sequence Number = 2775446373                                  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Acknowledgment Number = 566867674                             |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | OFF=1 | | | | | | | |A|P| | | |  Window = 32120               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Checksum = 60642              | Urgent Pointer = 0            |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                 Data
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   :  48545450  2f312e31  20323030  204f4b0d    : HTTP/1.1 200 OK  :
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Then again, this could be a malicious packet which could take down some
> less than generous OS.
> 
> Anyone know?
> 
> Thanks,
> 
> --
> Phil Wood, cpw at ...440...
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/mailman/listinfo/snort-users

--
Martin Roesch
roesch at ...421...
http://www.snort.org




More information about the Snort-users mailing list