Bugtraq mailing list archives
Re: TCP Timestamping and Remotely gathering uptime information
From: Chris Tobkin <tobkin () INTERSEC COM>
Date: Fri, 16 Mar 2001 14:47:51 -0600
The problem with releasing this information is that an attacker can see how long the system has been online and possibly correlate that with what patches are installed on the system telling whether it is likely to be vulnerable to certain exploit(s). 'uname' is a little different in that it only gives away the information to local users, once you're a local user, there are a lot of things you can do to find out how long the system has been online and such. Local vs. remote would be my argument here. Local users are more trusted and are therefore trused with "friendly" information, such as uptime. If the local users aren't trusted, then you've got a heck of a lot of work ahead of you to keep them in the dark. Like I always say, once they're on the system, most times it's not hard to get the entire box -- "Game Over, Man! Game Over!". Regarding linux and 500 days, it's more likely that a script kiddie would look for systems with 300+ days uptime, certain OS and version, and certain ports open which would be most likely to be systems that are "hands off" and good ones to attack. For example, if I found a system I nmap'd as and old version of linux, with port 53 open, I'd suspect it's probably unpatched. The trials and tribulations of "friendly" information... // Chris tobkin () intersec com -----Original Message----- From: Darren Reed [mailto:avalon () COOMBS ANU EDU AU] Sent: Thursday, March 15, 2001 11:53 AM To: BUGTRAQ () SECURITYFOCUS COM Subject: Re: TCP Timestamping and Remotely gathering uptime information So when do we change things like "uname" such that they no longer report the system "identity" (OS, OS rev) to anyone but root ? Why do you think all timestamps should not reveal uptime information ? What do you think is at risk here ? Are script kiddies going to say "ooh, he's been up for 500 days and he's not linux, lets flood him to death" ? Or is there something more fundamental ? One potential use of uptime information to an attackers advantage is in attacking things which use the current time (seconds, microseconds, whatever) as a seed for some sort of thing when the start up at boot time. An server which has a week PRNG or similar might be at risk, where it otherwise would not, do you think ? Darren
Current thread:
- Re: TCP Timestamping and Remotely gathering uptime information, (continued)
- 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 Bret (Mar 15)
- 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)