[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #24596] Vulnerability on faulty TCP options length

From: Simon Goldschmidt
Subject: [lwip-devel] [bug #24596] Vulnerability on faulty TCP options length
Date: Fri, 17 Oct 2008 19:17:22 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de; rv: Gecko/2008092414 Firefox/3.0.3


                 Summary: Vulnerability on faulty TCP options length
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Fr 17 Okt 2008 19:17:20 GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.3.0



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

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,


Reply to this item at:


  Nachricht geschickt von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]