lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] handle RST spoofing? CVE-2004-0230


From: Fabian Koch
Subject: Re: [lwip-users] handle RST spoofing? CVE-2004-0230
Date: Thu, 18 Sep 2014 16:49:17 +0000

Hey Simon, Hey all,

 

it took even longer for me to respond this time ;o)

 

I took the FreeBSD approach and Nessus scans no longer show the vulnerability.

 

You can check out the changes here:

https://github.com/tabascoeye/lwip/commit/5a5452c2952a4aa72a02ffd2581ef82c9b702062?diff=split

 

The build is compiling  with all unit-tests still passing:

https://travis-ci.org/tabascoeye/lwip/builds/35650124

 

but that RST behavior is not covered by the unit tests yet…:

https://coveralls.io/files/294103460#L666

 

Anyways:

it’s compact and even makes the code more readable imho (because that “acceptable = 1” thingie vanishes)

 

kind regards,

Fabian

 

From: lwip-users-bounces+address@hidden [mailto:lwip-users-bounces+address@hidden On Behalf Of address@hidden
Sent: Montag, 19. Mai 2014 21:06
To: Mailing list for lwIP users
Subject: Re: [lwip-users] handle RST spoofing? CVE-2004-0230

 

Fabian Koch wrote:

according to a nessus scan, LwIP is vulnerable to CVE-2004-0230, which means that it accepts a spoofed Packet with RST flag if the packets sequence number fits somewhere in the current window.

[..]

The easiest way to handle this attack would be only accept an incoming RST if the ackno matches the expected sequence. In the other case currently implemented in tcp_process() where the number only matched into the current window, only an ACK is sent back, expecting a re-send of the RST with a correct pair of sequence and ackno.

(also the way FreeBSD fixed it)

 

Do you think that would be feasible for LwIP or are you more in the Linux Boat, saying “meh.”?


Sorry for replying so late, this question might have been better off on the lwip-devel list...

As an lwIP user, after reading the CVE description, I think we're good with leaving it the way it is. I think so because I can't say to fully understand the implications of the suggested change.

Things might look differently depending on the kind of application used, though, so we might want to fix this anyway...

Would you care for a patch implementing the suggested change?


Thanks,
Simon


reply via email to

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