Bugtraq mailing list archives
Re: Remote fingerprinting/uptime (was Re: TCP Timestamping ...)
From: Jason R Thorpe <thorpej () zembu com>
Date: Wed, 21 Mar 2001 12:59:15 -0600
On Tue, Mar 20, 2001 at 08:23:52PM +1100, Darren Reed wrote:
So, does "fixing" the TCP timestamping actually help or make matters worse - i.e. easier for an attacker ? If I know a kernel is going to be OpenBSD pre-2.8 (for example), is that more or less useful than knowing it has been up 60 days ?
I was wondering about this myself until I read the "NetBSD" section of Newsham's "Problem with random increments" paper again. After reading it again, I decided that, for NetBSD at least, hiding the uptime makes it more difficult for an attacker to mount a TCP ISN attack. Background: Newsham's paper describes a statistical attack against the TCP ISN random increment method used by OpenBSD and FreeBSD (he actually includes code to exploit the problem in OpenBSD, and only says how it can be adjusted to exploit the problem in FreeBSD). He also describes why NetBSD is not susceptible to the attack; NetBSD's method makes the number space (much) larger, and doesn't leak as much information to the attacker. However, Newsham says that if an attacker knows how many times a certain internal variable has been incremented (by a fixed amount), the attacker can narrow down the search space. Now, if the attacker can see RFC1323 timestamps, it can now the minimum number of times this variable has been incremented -- tcp_now and tcp_iss_seq are incremented together in tcp_slowtimo(). This doesn't give an attacker the exact number of times tcp_iss_seq has been incremented, but it's a starting point. Observation of network traffic can provide more hints as to how many times an increment has occurred. So, if you can avoid leaking uptime by using 0-base RFC1323 timestamps, you remove a source of information an attacker can potentially use against you. -- -- Jason R. Thorpe <thorpej () zembu com>
Current thread:
- Re: TCP Timestamping and Remotely gathering uptime information, (continued)
- Re: TCP Timestamping and Remotely gathering uptime information Fyodor (Mar 14)
- Re: TCP Timestamping and Remotely gathering uptime information Bret (Mar 15)
- Re: TCP Timestamping and Remotely gathering uptime information Ted U (Mar 16)
- Re: TCP Timestamping and Remotely gathering uptime information Darren Reed (Mar 16)
- Re: TCP Timestamping and Remotely gathering uptime information Valdis Kletnieks (Mar 19)
- Re: TCP Timestamping and Remotely gathering uptime information Saint skullY the Dazed (Mar 19)
- Re: TCP Timestamping and Remotely gathering uptime information arivanov (Mar 19)
- Re: TCP Timestamping and Remotely gathering uptime information Stephen White (Mar 19)
- Re: TCP Timestamping and Remotely gathering uptime information bert hubert (Mar 20)
- Remote fingerprinting/uptime (was Re: TCP Timestamping ...) Darren Reed (Mar 20)
- Re: Remote fingerprinting/uptime (was Re: TCP Timestamping ...) Jason R Thorpe (Mar 22)
- Re: TCP Timestamping and Remotely gathering uptime information Chris Tobkin (Mar 19)
- Re: TCP Timestamping and Remotely gathering uptime information Ted U (Mar 19)
- Re: TCP Timestamping and Remotely gathering uptime information Matt Lewis (Mar 19)
- Re: TCP Timestamping and Remotely gathering uptime information Theo de Raadt (Mar 20)
- Re: TCP Timestamping and Remotely gathering uptime information Darren Reed (Mar 19)
- Re: TCP Timestamping and Remotely gathering uptime information van der Kooij, Hugo (Mar 20)