CVE-2004-0230 RST DoS vulnerability in Lenny?
JW
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-test...@lists.alioth.debian.org/msg01390.html
which possibly indicates it's fixed, or someone tried to fix it in 2005.
Does anyone know anything about this? I'm needing some kind of fix or
work-around so I can satisfy the scan vendor.
Thanks,
JW
--
----------------------
System Administrator - Cedar Creek Software
http://www.cedarcreeksoftware.com
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Török Edwin
> 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-test...@lists.alioth.debian.org/msg01390.html
> which possibly indicates it's fixed, or someone tried to fix it in 2005.
>
That says:
CVE-2004-0230 (TCP, when using a large Window Size, makes it easier for remote
...)
NOT-FOR-US: famous TCP RST bug
See here for more information, it seems it is something to care about
only if you do BGP routing:
http://lwn.net/Articles/81560/
See also redhat's statement on this:
http://www.redhat.com/security/data/cve/CVE-2004-0230.html
> Does anyone know anything about this? I'm needing some kind of fix or
> work-around so I can satisfy the scan vendor.
>
Not-a-bug?
Best regards,
--Edwin
Michael Gilbert
> 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-test...@lists.alioth.debian.org/msg01390.html
> which possibly indicates it's fixed, or someone tried to fix it in 2005.
>
> Does anyone know anything about this? I'm needing some kind of fix or
> work-around so I can satisfy the scan vendor.
It looks to be a known issue, which has been determined to be
unimportant in pretty much all circumstances (i.e. even if it is
successful, it just causes a disconnect, which isn't even an issue
since most configurations will just automatically restablish).
So unless you are doing BGP (Border Gateway Protocol) where disconnects
do have a major impact, I would seriously question the value you are
getting from a scan vendor who makes you worry about issues without
understanding the problem themselves first.
Mike
Justin Steven
> 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-test...@lists.alioth.debian.org/msg01390.html
> which possibly indicates it's fixed, or someone tried to fix it in 2005.
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
--
Justin
Elmar Stellnberger
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