Bugtraq mailing list archives
Re: TCP Timestamping and Remotely gathering uptime information
From: Bret <bret () REHOST COM>
Date: Wed, 14 Mar 2001 17:43:54 -0500
Your report provides an excellent description (and background) of the problem. But for people who want to explore this without kernel recompilation and for those who aren't using Linux, I would like to add that this remote-uptime capability has been available to Nmap users (using raw TCP packets) for more than a month. Troels Walsted Hansen posted a patch to the nmap-dev list on Feb. 3 [1]. I have also included my own implementation in the last few Nmap releases. Nmap is available for free download (with source) at http://www.insecure.org/nmap/ . Grab version 2.54BETA22 .
Yeah too bad it doesnt work right on some systems (patch is being worked on by an associate and he should send it to you :) Not being part of the nmap-dev list I was unaware of the patch, and only noticed that 2.54BETA20 (first version to include TCP Timestamping/uptime guessing) came out last Friday. But hey you cant run nmap on linux 2.4 anyway :) You do not have to run linux, not apply the kernel patch to get the timestamps as stated in the paper tcpdump does a fine job of gathering them and printing them in decimal (just format it for the date, as the last part of my program did). My kernel patch just made it a little easier (and makes it so you dont have to get root to look at them :) My point wasnt to write a scanner to compete with you (you 'advertisement' of nmap seems to indicate that you think this) it was instead to show that information is out there, but more importantly that several systems release this information and according to the RFC it does not have to be tied to the uptime (the RFC neither specifically states it must be nor it must not be). I think that some redesign by kernel developers is in order on this so that such information is not given out (no matter how useless it may appear), either by creating a new 'timestamp clock' for each TCP session (that uses timestamps) or by starting the timestamp clock off with some random number. But that is just my opinion.
Current thread:
- TCP Timestamping and Remotely gathering uptime information Bret (Mar 13)
- Re: TCP Timestamping and Remotely gathering uptime information Fyodor (Mar 14)
- <Possible follow-ups>
- 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)