Re: TCP Timestamp Vulnerability

[Andy Ruhl]

On Thu, Mar 29, 2018 at 10:43 AM, Richard Sass  wrote:
> "The remote host implements TCP timestamps, as defined by RFC1323. A
> side effect of this feature is that the uptime of the remote host can be
> sometimes be computed."
>
> Additional: http://www.securiteam.com/securitynews/5NP0C153PI.html
>
> I think the thought behind this is that if a person can determine the uptime
> of a system then this might be additional information that could be used to
> target an attack. For example: if a system has been up for a year then it
> probably hasn't been patched with recent security patches giving the
> attacker another piece of information on how to attack the system. I'm not
> sure if there may be more to it than that.

Is this a similar problem then?

# hping --icmp-ts -c 1 127.0.0.1
HPING 127.0.0.1 (lo0 127.0.0.1): icmp mode set, 28 headers + 0 data bytes
len=40 ip=127.0.0.1 ttl=255 id=0 icmp_seq=0 rtt=0.5 ms
ICMP timestamp: Originate=15774697 Receive=15774697 Transmit=15774697
ICMP timestamp RTT tsrtt=1


--- 127.0.0.1 hping statistic ---
1 packets tramitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.5/0.5/0.5 ms

I'm not aware of a way to prevent this reply without blocking all ICMP
which isn't always a good idea. Maybe npf can do it?

Andy

Re: TCP Timestamp Vulnerability

[Christos Zoulas]

In article <000901d3c785$7e7486a0$7b5d93e0$@seqent.com>,
Richard Sass  wrote:
>   "The remote host implements TCP timestamps, as defined by RFC1323. A
>side effect of this feature is that the uptime of the remote host can be
>sometimes be computed."
>
>Additional: http://www.securiteam.com/securitynews/5NP0C153PI.html
>
>I think the thought behind this is that if a person can determine the uptime
>of a system then this might be additional information that could be used to
>target an attack. For example: if a system has been up for a year then it
>probably hasn't been patched with recent security patches giving the
>attacker another piece of information on how to attack the system. I'm not
>sure if there may be more to it than that.

Oh no, not this again :-)

https://mail-index.netbsd.org/tech-net/2016/07/20/msg006018.html

And we have not had the uptime issue in ~forever; look at how "tcp_now" is
computed.

christos

Re: TCP Timestamp Vulnerability

[Manuel Bouyer]

On Thu, Mar 29, 2018 at 01:43:48PM -0400, Richard Sass wrote:
>   "The remote host implements TCP timestamps, as defined by RFC1323. A
> side effect of this feature is that the uptime of the remote host can be
> sometimes be computed."
> 
> Additional: http://www.securiteam.com/securitynews/5NP0C153PI.html
> 
> I think the thought behind this is that if a person can determine the uptime
> of a system then this might be additional information that could be used to
> target an attack. For example: if a system has been up for a year then it
> probably hasn't been patched with recent security patches giving the
> attacker another piece of information on how to attack the system. I'm not
> sure if there may be more to it than that.

Probably no such big deal, but it could be easy to use a per-connection
relative timespamp ... just use (uptime - time_of_connection)

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: TCP Timestamp Vulnerability

[Manuel Bouyer]

On Wed, Mar 28, 2018 at 07:44:56AM -0400, Richard Sass wrote:
> McAffe's Technical article KB78776  -
> https://kc.mcafee.com/corporate/index?page=content
> 
> =KB78776=RSS
> 
>  
> 
> .Suggests that there is a low vulnerability issue with TCP Timestamps but
> disabling this could result in performance issues.

They don't explain why this would be a vulnerability issue.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--