[ale] TCP Sequence Number Approximation Vulnerability

[Michael H. Warfield]

On Wed, 2011-03-16 at 08:43 -0400, Chris Fowler wrote: 
> A security scan on a device running 2.4.24 came up with 'TCP Sequence
> Number Approximation Vulnerability'.  Is this fixed in a later kernel.

> I've googled and am confused.  Most posts say it does not matter but I
> do not control the bank running the scanning tool that is spewing FUD.

TCP sequence number approximation
Common Vulnerability Exposure (CVE) ID: CVE-2004-0230
Bugtrack ID: 10183
Impact: DoS against long lived TCP sessions (BGP, TCP VPN tunnels)
PoC and exploit code exists for resetting BGP sessions.

Multiple Vendor TCP Sequence Number Approximation Vulnerability
http://www.symantec.com/security_response/vulnerability.jsp?bid=10183

Symantec rates the risk as "high" which is total BS.  This is a reset
insertion vuln.  That's DoS only and not even a spectacular one at that
as most services will recover quickly.

It's not even an intercept or mitm vuln since if you were in a position
to perform a mitm or intercept, you won't need to be approximating the
sequence numbers since you would have the packets.

Multiple Vendor TCP Sequence Number Approximation Vulnerability
http://www.securityfocus.com/bid/10183

Security Focus rates the risk as a Medium, which is only a little less
BS.  It does not disclose information and doesn't even present the
attack profile of the old TCP sequence number predictability vuln that
let to the Robert Morris worm spoofing attack.

https://secure1.securityspace.com/smysecure/catid.html?id=12213

> Thanks,
> Chris

The primary attack profile is extremely long sessions such as BGP
sessions or persistent VPN tunnels over TCP where BOTH the source and
destination ports are either well known (BGP) or relatively easy to
guess.  Linux is not listed as vulnerable so it remains to be seen if
this is a false positive (sequence number prediction and sequence number
approximation are notoriously difficult to test for reliably).  Someone
has hinted that the 2.6 kernel may well have this fixed and I'm inclined
to concur.  Some hardening of Linux kernel has occurred in the random
number generation, tcp sequence number generation, and source port
randomization.  If someone is using BGP on Linux, they would almost
certainly be using the Zebra (defunct) or Quagga BGP daemon.  Only
recent versions of the BGP daemon support MD5 signatures on packets (I
wrote the code) and only recent 2.6 kernels support the MD5 signatures
in the TCP stack.  Anyone using 2.4 would not have even that basic
security feature that's common in BGP land and I wrote the code in the
daemon simply because I would have been prohibited from peering with
some connections I needed.  I seriously doubt they would have BGP in
production on a 2.4 kernel and even then it's a low risk threat
requiring you to bombard a known BGP peering link with packets you can
spoof into that session.  Longer term persistent VPNs, such as OpenVPN
over TCP and versions of stunnel and ssh tunnels, should all have auto
recovery mechanisms (which would then result in new random source ports)
if for no other reason than to over network transients.

IMNSHO...
Risk: Very Low
Threat: Almost non existent.  Insignificant.
Probability of a false positive: Rather high.
Platform: Old and inappropriate for types of impacted services.

Recommended action: Upgrade to a 2.6 kernel or ignore if the machine is
not supporting high persistence connections such as BGP.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110316/afa0f9b3/attachment.bin