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

Re: CVE-2004-0230 RST DoS vulnerability in Lenny?



Recently, I had repeated problems with uploading files over ftps onto my website www.elstel.org. The connection always got broken when it should have listed the directory or uploaded the file. Filezilla said 'no response from server for 30 seconds' and thereupon it quitted the connection in order to re-estabilsh it. However filezilla had soon made that much re-connect attempts that the ftps server from dotplex rejected any connection-attempts; as a result I had to wait 10 minutes until I could make the next attempt. We have tried to fix the problem by making the server allow more connections from the client and by raising the timeout limit up to two minutes. However all of that was of very little help. Lately my stie was again brought down for a couple of hours because the upload precisely stopped at the index.html and failed to re-initiate for hours. Unfortunately filezilla does not upload files under another name first in order to rename them after having uploaded successfully but it first truncates the target file to a size of zero and then starts to upload so that the file can not be accessed during the upload or at all if the upload should become interrupted. Long problem description, but I`ll finally have to come to the point. There was nothing unusual about the parameters of my internet connection and I could surf the net as fast as always in the background while the attempted upload of a single file was failing and failing all over again for hours:

* router says
DSL Connection: Up
Downstream Bandbreite: 8920 Kbps
Upstream Bandbreite: 765 Kbps

> ping web4.dotplex.de
PING web4.dotplex.de (91.102.11.177) 56(84) bytes of data.
64 bytes from web4.dotplex.com (91.102.11.177): icmp_seq=1 ttl=53 time=39.9 ms 64 bytes from web4.dotplex.com (91.102.11.177): icmp_seq=2 ttl=53 time=39.5 ms

Yours,
Elmar Stellnberger



Am 2016-07-13 um 08:00 schrieb Justin Steven:
JW said (in 2010):
Recently we've had a scanning vendor tell us our Debian Lenny 5.0.3 is
vulnerable to CVE-2004-0230:

TCP/IP Sequence Prediction Blind Reset Spoofing DoS

"It may be possible to send spoofed RST packets to the remote system."

" . . . vulnerable to a sequence number
approximation bug, which may allow an attacker to send
spoofed RST packets to the remote host and close established
connections . . . "

When I tried to look up info about it - one pages lists "Linux" as vulnerable
(with no additional information) and I am not able to find anything about
Debian's status or relationship to it except possibly for
http://www.mail-archive.com/secure-testing-commits@lists.alioth.debian.org/msg01390.html
which possibly indicates it's fixed, or someone tried to fix it in 2005.

RFC 5961 provides some SHOULD's for "Improving TCP's Robustness to Blind
In-Window Attacks"

https://tools.ietf.org/html/rfc5961

Linux 3.6 implemented two SHOULD's (and an accompanying challenge ACK
throttling mechanism) in commits 282f23c6ee343126156dd41218b22ece96d747e3 and
0c24604b68fc7810d429d6c3657b6f148270e528

I've seen CVE-2004-0230 in some places (e.g. OP's message) refer just to TCP,
and in other places (e.g. NVD) refer to TCP "when using a large Window Size".
RFC 5961 (and one of the two SHOULD's implemented in Linux) sees to it that
injected RST packets need to guess the exact TCP sequence number, not just fall
within the TCP window.

Is this enough to have Jessie, Stretch and Sid marked as Not Vulnerable at
https://security-tracker.debian.org/tracker/CVE-2004-0230 (provided their
kernels incorporate the fix introduced in 3.6) and start to clean up the mess
that this "issue" has made, or am I off-base in thinking that RFC 5961 should
sufficiently mitigate the (arguably non-) issue that CVE-2004-0230 claims to
be.

Cheers



Reply to: