buglwIP - A Lightweight TCP/IP stack - Bugs: bug #24596, Vulnerability on faulty TCP...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #24596: Vulnerability on faulty TCP options length

Submitter:  Simon Goldschmidt <goldsimon>
Submitted:  Fri 17 Oct 2008 07:17:20 PM UTC
   
 
Category:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  1.3.0

Mon 20 Oct 2008 12:20:36 PM UTC, comment #3: 


> On the other hand it is a good idea (especially in our scenario)
> to just ignore the wrong parts and accept the rest of the packet
> to increase the robustness.


The main reason for doing so is smaller code, I guess... I'd still vote for discarding malformed packets, but that's not really related to fixing this bug.

Simon Goldschmidt <goldsimon>
Group administrator
Mon 20 Oct 2008 07:46:28 AM UTC, comment #2: 

I still think it is best practice to drop packets that do not conform to RFC 793.
On the other hand it is a good idea (especially in our scenario) to just ignore the wrong parts and accept the rest of the packet to increase the robustness.

TabascoEye <tabascoeye>
Sat 18 Oct 2008 03:24:16 PM UTC, comment #1: 

The solution for this is really simple: the variable indexing the options was an u8_t. Adding an option-length of nearly 0xff lead to that u8_t overflowing which is why tcp_parseopt looped endlessly.

However, in contrast to the suggestion to drop this packet, I decided to stay with ignoring further options if such a malformed packet is received: it's what we did until now. After all, the only option we can handle is MSS...

Thanks for the submitting this, Fabian.
Checked in the fix.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 17 Oct 2008 07:17:20 PM UTC, original submission:  

Fabian Koch has reported this on lwip-devel:

Hello everyone,

we have discovered some potential errors in LwIP while putting our device to a series of security related stress/error/fuzz-testing on the Ethernet.
The Stack seems to crash when subjected to specifically crafted Packets where the actual TCP Options length does not match the length value that the packet says it will be.
(We are using a slightly modified version of LwIP 1.3.0-stable release)

Our security testingcenter has the following comment:

It is recommended to have a proper boundary checking (i.e., value in the fields to be
checked against the actual values of a particular field) while processing a received TCP
packet. <Device> should discard a packet with TCP Options Length field that does not match
the actual length of the TCP Options field. If this length does not match the actual value, the
packet should then be discarded. This should be fixed by the TCP/IP stack vendor.

I attach two screenshots of Wireshark to this mail. These show the crafted packets with their intentionally wrong TCP Options.
Please consider fixing this issue by doing correct boundary checking of the TCP header and its options field in tcp_input() in 1.3.1.

yours sincerely,
Fabian

Simon Goldschmidt <goldsimon>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tabascoeye (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-01-21 goldsimon Open/ClosedOpen Closed
    2009-01-21 goldsimon StatusReady For Test Fixed
    2008-10-18 goldsimon StatusNone Ready For Test
        Assigned toNone goldsimon

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code