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
* router says
DSL Connection: Up
Downstream Bandbreite: 8920 Kbps
Upstream Bandbreite: 765 Kbps
> ping web4.dotplex.de
PING web4.dotplex.de (18.104.22.168) 56(84) bytes of data.
64 bytes from web4.dotplex.com (22.214.171.124): icmp_seq=1 ttl=53
64 bytes from web4.dotplex.com (126.96.36.199): icmp_seq=2 ttl=53
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
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
Linux 3.6 implemented two SHOULD's (and an accompanying challenge ACK
throttling mechanism) in commits 282f23c6ee343126156dd41218b22ece96d747e3 and
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