6213398 2001-03-13 00:54 -0500 /448 rader/ Bret <bret@REHOST.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-14 01:10 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: bret@REHOST.COM
Mottagare: Bugtraq (import) <15894>
Ärende: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Bret <bret@REHOST.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200103130554.AAA10381@rehost.com>
TCP Timestamping - Obtaining System Uptime Remotely
By Bret McDanel bret@rehost.com
March 11, 2001
TCP Timestamping can be used to retrieve information about your
system that you may not wish to be public. I started investigating
this after some discussion of NetCraft's (http://www.netcraft.com/)
server uptime stats, and their reliability. Ant Mitchell was very
polite in telling me NetCraft would not disclose how they obtain
these figures, only that he feels they are reliable. So I started
looking into how they could get this information. What I discovered
was TCP Timestamping is equal to the uptime (after a fashion) of many
systems, and as such can give you extra information about the running
system.
What is Timestamping? How can it be used to gain information about a
running system? Timestamping is a TCP option, which may be set, and
if set takes 12 bytes in the header (for each packet) in addition to
the 20 bytes a TCP header normally takes. This is exclusive of any
other options. What good is this overhead? According to RFC1323:
"The timestamps are used for two distinct mechanisms: RTTM (Round Trip
Time Measurement) and PAWS (Protect Against Wrapped Sequences).".
I suggest that anyone interested in TCP Timestamps read RFC1323
(these are not the IP timestamping options). The fact that
timestamping exists isn't anything special in itself, but how the
value is populated and how the value is set is somewhat interesting.
4.4BSD increments the timestamp clock once every 500ms and this
timestamp clock is reset to 0 on a reboot -- TCP/IP ILLUS v1,
p349
The timestamp value to be sent in TSval is to be obtained from a
(virtual) clock that we call the "timestamp clock". Its values
must be at least approximately proportional to real time, in order
to measure actual RTT. -- RFC1323 May 1992
Note that the RFC does not dictate that the timestamp clock be tied
to system uptime, so any system that doesn't conform to this is
perfectly valid (ie Windows 2000). Additionally the rate at which
each system increments the clock need not be disclosed either, as the
timestamp value is only echoed back to the sender for the sender to
process.
This means that in 4.4BSD we can use this number to directly tell the
time that a system has been up. All we have to do is make a
connection and record the received timestamp. Not everyone
implements timestamping this way however. This yields various
results on different operating systems. Linux for instance
increments every 1 ms, Cisco IOS increments every .1 ms. Windows
95/98/NT4 do not support Timestamping (although rumor has it that
there is a patch to enable RFC1323 functionality on 95/98/NT4) Win2k
does, but this value does not appear to be directly related to
uptime. This means that in order to tell the uptime we need to know
what OS we are looking at, or at the very least make multiple
connections and try to guess what the increment is based on elapsed
time vs increment.
There are some limitations to using this method for recording uptime.
Certain systems have a maximum limit on how long their 'uptime' can
be. The timestamp is a 32 bit number (signed). As such it will
overflow into the sign bit after 2147483647 ticks. Based on the
number of ticks per second, you can easily determine when this will
roll over.
(leap year included)
OS Ticks/sec Rollover time
4.4BSD 2 34 years, 8 days, 17:27:27
Solaris 2 10 6 years, 293 days, 22:53:00
Linux 2.2+ 100 248 days, 13:13:56
Cisco IOS 1000 24 days, 20:31:23
One can also map out the number of systems in a load balanced
environment by connecting repeatedly to the group of machines, and
inspecting the Timestamps. For each different time you have a
different machine.
RFC1323 talks about the frequency the 'timestamp clock' should be
updated
The receiver algorithm does place some requirements on the
frequency of the timestamp clock.
(a) The timestamp clock must not be "too slow".
It must tick at least once for each 2**31 bytes sent.
In fact, in order to be useful to the sender for round
trip timing, the clock should tick at least once per
window's worth of data, and even with the RFC-1072
window extension, 2**31 bytes must be at least two
windows.
To make this more quantitative, any clock faster than 1
tick/sec will reject old duplicate segments for link
speeds of ~8 Gbps. A 1ms timestamp clock will work at
link speeds up to 8 Tbps (8*10**12) bps!
(b) The timestamp clock must not be "too fast".
Its recycling time must be greater than MSL seconds.
Since the clock (timestamp) is 32 bits and the
worst-case MSL is 255 seconds, the maximum acceptable
clock frequency is one tick every 59 ns.
However, it is desirable to establish a much longer
recycle period, in order to handle outdated timestamps
on idle connections (see Section 4.2.3), and to relax
the MSL requirement for preventing sequence number
wrap-around. With a 1 ms timestamp clock, the 32-bit
timestamp will wrap its sign bit in 24.8 days. Thus,
it will reject old duplicates on the same connection if
MSL is 24.8 days or less. This appears to be a very
safe figure; an MSL of 24.8 days or longer can probably
be assumed by the gateway system without requiring
precise MSL enforcement by the TTL value in the IP
layer.
Based upon these considerations, we choose a timestamp clock
frequency in the range 1 ms to 1 sec per tick. This range
also matches the requirements of the RTTM mechanism, which
does not need much more resolution than the granularity of
the retransmit timer, e.g., tens or hundreds of milliseconds.
As you can see all of these systems are within the RFC in their
timings, however varied.
It has come to my attention that nmap 2.54beta20 released March 09,
2001 included support for detecting (multiple pass, guess at tick
rate) uptimes.
If you want to quickly get the Timestamp value, you can fire up tcpdump, and
watch for it. Here is an example of what you may see and how to interpret
the data:
> myhost.12345 > theirhost.22: . 1:1(0) ack 1 win 5840
<nop,nop,timestamp 6426701 865450440> (DF)
The timestamps are located near the end of the line, where the TCP
Options are printed. The first timestamp is sent by 'myhost', the
second is what 'theirhost' last sent us (we are expected to return
that to them). The numbers are the number of ticks that have
accumulated in the 'timestamp clock' and if the OS supports it, can
reveal an uptime.
I have included below information obtained by myself and several
people running various OSs that let me scan them and compare the
actual uptime vs the timestamp returned. I do not have access to all
systems to test, however I tried to include as much vendor
information on RFC1323 compliance as reasonably possible.
If you are considering disabling timestamping on your system please
read RFC1323 for more information (especially if you are on a fast
network).
Windows
Win2k sends the timestamp after the syn/ack handshake is complete
(sends 0 TS during the 3-way handshake)
95/98 does not support TS
NT 3.5/4 does not support TS
2000 increment every 100ms initial number random
Linux
Sends TS on first packet replied to - default always get TS
To disable echo 0 >/proc/sys/net/ipv4/tcp_timestamps
To enable echo 1 >/proc/sys/net/ipv4/tcp_timestamps
Increments 100 ticks/sec
2.0.x does not support TCP Timestamps
2.1.90+ Supports Timestamps
2.2.x Supports Timestamps
2.4.x Supports Timestamps
4.4BSD - OpenBSD BSDi BSD/OS (2.1 & 3.0) FreeBSD (2.1.5)
To enable/disable sysctl -w TCPCTL_DO_RFC1323={true,false}
Or sysctl -w net.inet.tcp.rfc1323={true,false}
4.4BSD spec is applied, 2 ticks/sec
MacOS (Open Transport)
Supports Timestamps
Novell Netware
5 Does not support Timestamps
IRIX
5.3+ Support Timestamps
5.3-6.1
/var/sysgen/master.d/bsd contains the kernel variables
after editing you must use /etc/autoconfig and reboot (WTF!)
6.5 edit /var/sysgen/mtune/bsd or use systune (like BSDs
sysctl) tickrate 2/sec
HPUX
9.x No (9.05 and 9.07 have patches to support Timestamps)
To enable you must poke the kernel variable tcp_dont_tsecho to 0
10.00,01,10,20,30 Support Timestamps
11 Enabled by default
AIX
3.2 & 4.1 Support Timestamps
Tunable via the 'no' command
SunOS
4.1.4 No (May be purchased as a Sun Consulting Special)
Solaris
To Enable
2.5 No (May be purchased as a Sun Consulting Special)
2.6 may be uptime but rolls over quickly, increments 1000 ticks/second
2.7 tickrate 100/sec (its not exactly uptime there was a 5 minute
skew on a 112 day uptime)
8 it is uptime, 100 ticks/second
to enable ndd /dev/tcp tcp_tstamp_always 1
If the parameter is set (non-zero), then the TCP timestamp option will
always be negotiated during connection initiation. The scale option will
always be used if the remote system sent a timestamp option during
connection initiation. To use the timestamp, both hosts have to support
RFC 1323.
ios (cisco)
By default disabled To change [no] ip tcp timestamp
I tested only against a Cisco 2524 running 12.0(9)
cisco 2524 (68030) processor (revision J) with 14336K/2048K bytes of memory.
Updates 1000 ticks/sec resets to 0 at boot
comos (livingston/lucent portmasters)
Do not support TS
Netopia
Do not support TS
ConvexOS
11.0 Supports Timestamps
CRI Unicos
8.0 Supports Timestamps
(Compaq) Digital Unix
3.2 & 4.0 Does not support Timestamps
Thanks go out to (in no particular order)
cstone cstone@pobox.com
Solaris 2.6 box to scan
Solaris 8 box to scan
Tim Helton thelton@1115.net
BSD configuration options
Netopia scan
IOS scan
TCP/IP Illustrated Quote
Proof reading
Phear jhm@santacruz.org
Linux 2.0.x kernel (who knew anyone still had one of those up
:) Storm
BSDI box to scan
Nefarius
For insisting that if Netcraft's uptime reports were even close
to accurate then Windows would be at the top of the list.
And for letting me scan your Windows 2000 box Anyone else
that knowingly or unwittingly helped me while I was ranting about
this over the last week.
--------------------- Appendix A --- Source Code ------------------------------
I did my testing under linux, and in order to easily retrieve the
remote Timestamp I had to make a small kernel change. Because I am
running 2.4.x and a lot of people may not be I will try to document
this as generically as possible, note this should work fairly easily
on 2.2 kernels however your results may be different (therefore I am
not responsible if you choose to do this and it breaks *anything*,
use at your own risk). I will be submitting these changes to Linux
Kernel developers so that it may become part of the official release
(there is no reason to deny access to the timestamp information and
who knows maybe someone will use timestamps as a covert data channel
:)
If these directions are not clear enough then you probably shouldn't
be editing your kernel. I could have included diffs, however 2.2
kernels are quite different so line numbers would not match, and I
have other mods that would prevent patch from working correctly
anyway.
Here is what I did:
All of these start at your kernel root directory (ie /usr/src/linux)
include/linux/tcp.h -- Add the following to the section 'TCP socket options'
#define TCP_RCV_TIMESTAMP 12 /* The received Timestamp */
#define TCP_SND_TIMESTAMP 13 /* The sent Timestamp */
net/ipv4/tcp.c -- Add to the routine tcp_getsockopt() in the select statement
case TCP_RCV_TIMESTAMP:
if (tp->tstamp_ok)
val = tp->rcv_tsval;
else
val = 0;
break;
case TCP_SND_TIMESTAMP:
if (tp->tstamp_ok)
val = tp->rcv_tstamp;
else
val = 0;
break;
remake your kernel and reboot. Now you need a program that will
connect and display the timestamps.. That is fairly straight forward
now.
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#include <netdb.h>
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <unistd.h>
#include <netinet/tcp.h>
#define TCP_RCV_TIMESTAMP 12 /* The received Timestamp */
#define TCP_SND_TIMESTAMP 13 /* The sent Timestamp */
int connserver(char *host,int port)
{
int sd,addr,flag=1;
struct hostent *he;
struct sockaddr_in sa;
/* try to resolve the host */
if((addr=inet_addr(host))!= -1) {/* dotted decimal */
memcpy(&sa.sin_addr,(char *)&addr,sizeof(addr));
} else {
if((he=gethostbyname(host))==NULL) {
printf("Unable to resolve %s\n",host);
return(-1);
}
memcpy(&sa.sin_addr,he->h_addr,he->h_length);
}
sa.sin_port=htons(port);
sa.sin_family=AF_INET;
if((sd=socket(AF_INET,SOCK_STREAM,0))<0) {
perror("socket");
return(-1);
}
/* make sure that we use timestamping if the kernel has it defaulted to not send them
* This is not required for the linux systems I have seen as they always try to
* negotiate timestamps if they are enabled in the kernel, but better safe than
* wondering why it doesn't work
*/
if(setsockopt(sd, IPPROTO_TCP, TCPOPT_TIMESTAMP, (char *) &flag, sizeof(int))<0)
perror("setsockopt TCP_TIMESTAMP");
if(connect(sd,(struct sockaddr *)&sa,sizeof(sa))<0) {
perror("connect");
exit(1);
}
return(sd);
}
unsigned int get_ts(char *host,int port)
{
int optsize=sizeof(long);
unsigned int l;
char buff[15];
int sd;
if((sd=connserver(host,port))==-1) exit(0);
if (!getsockopt(sd, IPPROTO_TCP, TCP_RCV_TIMESTAMP, &l, &optsize)) {
if(l!=0) {
close(sd);
return(l);
} else {
/* Win2k workaround, If we are here, either the box doesnt support
* Timestamps or its win2k which sends a 0 TS in the handshake
*/
sprintf(buff,"ooga booga\n");
send(sd,buff,strlen(buff),0);
/* wait for data
* potential problem with it hanging forever if no data is returned
*/
while(!recv(sd,buff,sizeof(buff),0)) ;
if (!getsockopt(sd, IPPROTO_TCP, TCP_RCV_TIMESTAMP, &l, &optsize)) {
close(sd);
return(l); /* 0 if remote system doesnt support Timestamping */
} else perror("getsockopt");
}
} else perror("getsockopt");
close(sd);
return(0);
}
int main(int argc, char **argv)
{
int ts1,ts2,tickrate;
int sec,min,hour,day;
if(argc!=3) {
printf("Usage: %s <ip> <port>\n",argv[0]);
exit(0);
}
ts1=get_ts(argv[1],atoi(argv[2]));
sleep(1); /* wait for the remote system to increment the counter a bit */
ts2=get_ts(argv[1],atoi(argv[2]));
printf("TimeStamp1: %d\n",ts1);
printf("TimeStamp2: %d\n",ts2);
tickrate=(ts2-ts1);
printf("Unmodified tickrate %d\n",tickrate);
/* compensate for network delays +-30% */
if(tickrate) {
if(tickrate<1300 && tickrate > 700) tickrate=1000;
else if(tickrate<130 && tickrate > 70) tickrate=100;
else if(tickrate<30 && tickrate > 7) tickrate=10;
else if(tickrate<4 && tickrate > 1) tickrate=2;
else printf("Unknown tickrate - will try but may be incorrect\n");
day=(ts2/tickrate)/86400;
sec=(ts2/tickrate)%86400;
hour=sec/3600;
sec=sec%3600;
min=sec/60;
sec=sec%60;
printf("%s (Tickrate %d/sec) Uptime: %u days, %02d:%02d:%02d\n",argv[1],tickrate,day,hour,min,sec);
} else
printf("The remote system does not appear to support TCP Timestamping\n");
return(0); /* as per C89 spec main() returns an int */
}
(6213398) --------------------------------(Ombruten)
6218296 2001-03-14 00:30 -0800 /68 rader/ Fyodor <fyodor@INSECURE.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-14 22:10 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: fyodor@INSECURE.ORG
Mottagare: Bugtraq (import) <15918>
Kommentar till text 6213398 av Bret <bret@REHOST.COM>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Fyodor <fyodor@INSECURE.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0103140023170.9392-100000@amy.yuma.net>
On Tue, 13 Mar 2001, Bret wrote:
> TCP Timestamping - Obtaining System Uptime Remotely
> By Bret McDanel bret@rehost.com
> March 11, 2001
[ CUT ]
>
> I did my testing under linux, and in order to easily retrieve the remote
> Timestamp I had to make a small kernel change.
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 .
Another under-exploited TCP/IP property is IP.ID prediction. Antirez
and others have posted in recent years about the fun you can have
with systems that simply increment this field for each packet sent.
Yet most operating sytems remain vulnerable. Recent versions of Nmap
will report on this with the "-O -v" options.
One other known TCP/IP sequencing problem is ISN prediction. Over
the years this hole has been gradually declining. Lately we have
seen that even Cisco has began to recognize the problem! But there
are still plenty of susceptible machines out there. Nmap offers a
report on this as well (not a new feature).
Here is a simple usage example (some verbose output elided):
amy~#nmap -sS -O -F -v ssh.com
Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
Interesting ports on www.fi.ssh.com (193.64.193.132):
(The 1082 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
53/tcp open domain
80/tcp open http
6001/tcp open X11:1
Remote operating system guess: NetBSD 1.3 - 1.3.3 little endian arch
Uptime 320.671 days (since Thu Apr 27 09:03:19 2000)
TCP Sequence Prediction: Class=random positive increments
Difficulty=182669 (Good luck!)
IPID Sequence Generation: Incremental
Nmap run completed -- 1 IP address (1 host up) scanned in 15 seconds
amy~#
Anyway, sorry to plug my own software. But I thought some people
might find this useful.
Cheers,
Fyodor
[1] http://lists.insecure.org/nmap-dev/2001/Jan-Mar/0006.html
(6218296) --------------------------------(Ombruten)
6224304 2001-03-14 17:43 -0500 /42 rader/ Bret <bret@REHOST.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-15 20:16 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: bret@REHOST.COM
Mottagare: Bugtraq (import) <15935>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Bret <bret@REHOST.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200103142243.RAA11917@rehost.com>
> 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.
(6224304) --------------------------------(Ombruten)
6242131 2001-03-18 00:17 -0500 /28 rader/ Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-19 19:23 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Valdis.Kletnieks@VT.EDU
Mottagare: Bugtraq (import) <15963>
Kommentar till text 6229374 av Darren Reed <avalon@COOMBS.ANU.EDU.AU>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200103180517.f2I5H9d16883@foo-bar-baz.cc.vt.edu>
On Fri, 16 Mar 2001 04:52:47 +1100, Darren Reed <avalon@COOMBS.ANU.EDU.AU> said:
> 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
The first use *I* thought of was as follows:
If you know (via careful extended observation) that a given server
reboots every alternate Thursday at 4:30AM (or whenever their test
time is), it allows you to lay the groundwork for a spoofing attack
or other mischief while the spoofed machine is down for the reboot
and unable to complain about the impostor...
As a bonus - they probably will skip the reboot unless they had a config
change staged. As a result, you *know* what will get blamed for any and
all weirdness seen during the reboot - every sysadmin I know will look at
a weird message at 4:30AM and think "What did I just change, and how the
<bleep> did it cause THAT error?". ;)
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
(6242131) /Valdis Kletnieks <Valdis.Kletnieks@VT.EDU>/(Ombruten)
6242179 2001-03-17 00:31 +0000 /32 rader/ Stephen White <swhite@OX.COMPSOC.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-19 19:43 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: swhite@OX.COMPSOC.NET
Mottagare: Bugtraq (import) <15966>
Kommentar till text 6224304 av Bret <bret@REHOST.COM>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Stephen White <swhite@OX.COMPSOC.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010317003122.A15097@benji.the-roost>
On Wed, Mar, 2001, Bret wrote:
> either by creating a new 'timestamp clock' for
> each TCP session (that uses timestamps)
You can't do this .. it breaks the use of such timestamps for things
like TCP Sequence number wrap-around protection on fast networks
(gigabit).
> or by starting the timestamp clock off with some random number.
I don't think this breaks any rules or functionality and shouldn't
even hit performance. A series of observations would still enable
you to obtain uptime information, since the readings would be linear
until a reboot. If you sampled timestamps from a machine
periodically you could work out it's probably uptime to within the
length of that period. Obviously you're readings would be
meaningless until you witness a reboot, but beyond that point you
should still be able to tell.
There is a slight issue over whether you actually care that people
know your system uptime.
--
Stephen White \ OU Compsoc System Administration Team
PGP Key ID: 0xC79E5B6A \ System Administration Co-ordinator
<swhite@ox.compsoc.net> \ http://ox.compsoc.net/~swhite/
(6242179) /Stephen White <swhite@OX.COMPSOC.NET>/(Ombruten)
6242185 2001-03-16 14:47 -0600 /58 rader/ Chris Tobkin <tobkin@INTERSEC.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-19 19:45 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: tobkin@INTERSEC.COM
Mottagare: Bugtraq (import) <15967>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Chris Tobkin <tobkin@INTERSEC.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <F04118150BBED211819500104B6FC175602821@postino.intersec.com>
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
(6242185) /Chris Tobkin <tobkin@INTERSEC.COM>/(Ombruten)
6242518 2001-03-16 20:56 +0000 /74 rader/ <arivanov@SIGSEGV.CX>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-19 21:31 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: arivanov@SIGSEGV.CX
Mottagare: Bugtraq (import) <15972>
Kommentar till text 6229374 av Darren Reed <avalon@COOMBS.ANU.EDU.AU>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: arivanov@SIGSEGV.CX
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <XFMail.20010316205641.arivanov@sigsegv.cx>
-----BEGIN PGP SIGNED MESSAGE-----
On 15-Mar-2001 Darren Reed wrote:
> 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 ?
Just two examples of the top of my head.
1. Detecting subversion of an operating system that are vulnerable
but not distinguishable by normal fingerprinting. Example: Linux
2.2.x that has an uptime of more than 500 days is guaranteed to be a
pre-2.2.8 and vulnerable to the specific IP stack issue reported on
bugtraq for 2.2.7. A more recent is quite likely to be something
that has been patched.
Similar examples can be made with BSD.
2. Some OSes require reboot for fixes that are expected to
be userland. There you have a sure indication that a fix has not
been applied. I would say that this is a very good and almost
undetectable method of collecting vulnerable IIS installations ;-)
You can even use third parties (netcraft) for some of them.
List of course can be extended.
- ----------------------------------
Anton R. Ivanov
ARI2-RIPE
Today's deliverables will have to be delayed because:
Recursive traversal of loopback mount points
- ----------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iQEVAwUBOrJ+CSlWAw/bM84zAQEZlwf/YKVBSLmFhfWSAYraRG+wzYu9MEK7I+yD
bAVUicuHwVzznRAKPiqUF0eEOa6cISXpH6LmUd6tU9ngXEDdNVFmn0WSsqVaPJ9r
d5NmIgIvCIiKrFKKGkqF1QfwYo0/BMhjQRreFUU0Lz0rC0852OpejPOiosvt0Bvs
nLVdA3zvBNz1nEQWd/cwcPF5t5VJ3dmg2xBOvjalPitQLmZ7GGrmnryRPrQS+QeK
jZXD7nxofDdnexsLQJS4d2N8L0tsrwIkDeyaiNxXNqFRk4ubKAkmuRsvJmKsgnjD
CKdMjX7OmT980rL1jU4EInvSBLGMfDPnDXR/BbA3L+NgK/2Qw8ZifA==
=hZh4
-----END PGP SIGNATURE-----
(6242518) / <arivanov@SIGSEGV.CX>/------------------
6242527 2001-03-17 14:16 +1100 /34 rader/ Darren Reed <avalon@COOMBS.ANU.EDU.AU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-19 21:33 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: avalon@COOMBS.ANU.EDU.AU
Mottagare: Bugtraq (import) <15973>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200103170316.OAA29790@cairo.anu.edu.au>
In some mail from Bill_Royds@pch.gc.ca, sie said:
>
> Actually, the logic is "This has been up for 300 days. It probably is not
> being maintained so it likely has that unpatched exploit avaialable".
I thought about this before I posted that email but decided against
any inclusion of it. Why ?
There are systems running around the world, today, that *need* to run
24x7 and security patches are no reason for a reboot. That aside,
that a system has been up, since its release, longer than it takes
the time information to wrap, do you *really* know how long it has
been up ?
Upgrading of software running on a host has little or nothing to do with
how long it has been running - so long as you're not running M$ - if it's
not something like a library file. Last I checked, you didn't need to
reboot to patch up sendmail, named or apache :)
Good sysadmin practice should involve regular, scheduled, rebooting
of systems to ensure that over time the "tinkering" which happens on
a day to day basis never gets to a point where things that are meant
to be in the bootup process are left out. Well, that's my theory
anyway :)
A large uptime of a machine may mean it is quite vulnerable, but does
it really tell you it is unmaintained ? Does a short uptime mean it
is really maintained or does it just tell you it was rebooted not
long ago ?
Darren
(6242527) /Darren Reed <avalon@COOMBS.ANU.EDU.AU>/(Ombruten)
6242944 2001-03-16 21:20 -0800 /38 rader/ Ted U <grendel@HEOROT.STANFORD.EDU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-19 22:42 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: grendel@HEOROT.STANFORD.EDU
Mottagare: Bugtraq (import) <15981>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Ted U <grendel@HEOROT.STANFORD.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.BSO.4.31.0103162107270.31657-100000@heorot.stanford.edu>
On Fri, 16 Mar 2001, Emre Yildirim wrote:
> I might be completely wrong here but.... what about
>
> sysctl -w net.inet.tcp.rfc1323=0
no, that disables timestamps. rfc1323 support is needed (or will be)
for high speed networks, where the sequence numbers can roll over.
then delayed packets might be accepted when they shouldn't. the
timestamp prevents this from happening. for today's internet, you
can turn rfc1323 off. but that's not a solution to the "problem", if
indeed there is a problem.
it's not a major issue if someone can determine your uptime, as has
been pointed out. darren doesn't think so, bret did. anyway, as
bret pointed out, it can be used to count the machines behind a load
balancing system. another area is nat detection. let's say i've got
three servers running irc, www, and ftp behind a nat firewall. by
examing the timestamps, you could determine that my.host.com:80 and
my.host.com:21 are not the same machine. usefulness? i don't know.
but why advertise if you don't have to?
it was pointed out to me that openbsd -current sets the initial
timestamp to a random number, so the uptime detected is incorrect.
but this still allows someone to count the machines behind a
firewall. the way i did it, every connection is at zero initially,
so it's much harder to tell.
-- Ted Unangst - grendel@heorot.stanford.edu -
http://heorot.stanford.edu/ "If you don't believe in the existence of
evil, you have a lot to learn."
(6242944) /Ted U <grendel@HEOROT.STANFORD.EDU>/(Ombruten)
6243326 2001-03-16 12:04 -0800 /33 rader/ Matt Lewis <barkode-bugtraq@NINJAS.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-19 23:48 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: barkode-bugtraq@NINJAS.ORG
Mottagare: Bugtraq (import) <15985>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Matt Lewis <barkode-bugtraq@NINJAS.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AB271B3.55B6004A@ninjas.org>
Darren Reed said:
> Why do you think all timestamps should not reveal uptime information ?
Well, not to speak on Bret's behalf per se, but personally, I've seen
plenty of software (the quality of which may be in question) that uses
uptime (or clock-ticks-since-boot, whatever) for a variety of things,
albeit ususally trivial.
However, take for example a weak IP stack that uses this data to do
ISN generation for tcp sessions, for instance a trivial time
dependency that takes the uptime of a machine and uses it to compute
a poorly-generated psuedo-random number for use as an ISN.
Not to say this is actually the case, but there's definitely software
in userland that this could affect.
To generalize, if someone knew that a particular application they were
attempting to attack used the uptime of the machine as a seed to
generate some sort of serial, tracking, or sequencing number, or a
temp-file-naming-scheme, etc, it may not be the straw that breaks the
camel's back, but it certainly may help the attacker.
Of course, you're asking for it if you're using uptime as a seed for
anything you want to call a decent PRNG.
-Matt
(6243326) /Matt Lewis <barkode-bugtraq@NINJAS.ORG>/(Ombruten)
6247839 2001-03-19 18:43 +0000 /81 rader/ Stephen A. Zarkos <obsid@SENTRY.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-20 20:29 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: obsid@SENTRY.NET
Mottagare: Bugtraq (import) <16002>
Kommentar till text 6242625 av Bret <bret@REHOST.COM>
Ärende: Re: nmap and linux 2.4 (was Re: TCP Timestamping ...)
------------------------------------------------------------
From: "Stephen A. Zarkos" <obsid@SENTRY.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AB6533C.36C5C1BC@sentry.net>
Hello,
I'd like to just add a couple things to this. We've been discussing
this problem a bit on the netfilter mailing list available at
http://lists.samba.org/mailman/listinfo/netfilter,
so this may be the best place to continue this thread, and offer
solutions, etc.
Obviously, the netfilter nat code breaks nmap while using the -O flag
or using decoy options. The (sendto in send_tcp_raw: sendto....)
error is a symptom of this. It also breaks other packet shaping
utilities such as hping, etc., so this does not appear to be an nmap
problem.
I don't believe the connection tracking portion of netfilter is to
blame in this case. In my tests the connection tracking code,
whether it was loaded as a module or built statically into the
kernel, didn't seem to get in the way. The cause of the 'sendto..'
errors seems to be caused solely by the iptable_nat.o module(which is
huge, of course). Once you load that one, or build it into the
kernel, "nmap -O" no worky. Without it, nmap/hping/everything works
just peachy.
Best Regards,
Steve
Bret wrote:
>
> I am posting this in the hopes that this thread can die on bugtraq and go where
> it is most likely more appropriate (nmap-dev perhaps). Anyway, since I have
> gotten so many different people saying so many different things to me, I
> in response to my previous comments about nmap and linux 2.4 I thought I would
> post this (hopefully) final message in that thread.
>
> Using nmap and linux 2.4 I started noticing some problems. Other people that
> I talked to confirmed they too were having problems. I mentioned this on
> bugtraq, and some people there said they too had sendto() errors, while others
> said they did not.
>
> I started looking around and it appears that the iptables code is what is
> causing the EPERM error. Specifically
> 'Connection tracking (required for masq/NAT)' located in the kernel
> configuration under Networking Options=>IP: Netfilter Configuration.
>
> I have debugging on (dont know if that is required) and get this message
>
> NAT: 3 dropping untracked packet d1c95b20 6 127.0.0.1 -> 127.0.0.1
>
> This is from the connection tracking code that is required for Linux 2.4
> to do NAT. I looked briefly at the source code to this module
> (/usr/src/linux/net/ipv4/netfilter/ip_nat_standalone.c) and it appears that
> if you just not drop the packet, everything will be fine. I really have
> no idea what else may result of doing this, and I really didnt look at this
> part of the code AT ALL. At the time of this writing I have been unable
> to test NAT functionality (although I guess it will work)
>
> One side note to this, you may now see multiple kernel errors as the packet
> goes through the different filters (in, nat, out, etc). I see 3 different
> ones for each packet, but that is not a big deal.
>
> So there are multiple solutions to the sendto() problem with Linux 2.4 + NAT
> 1. Dont use Linux 2.4 + NAT (connection tracking)
> 2. Ignore the sendto() EPERM error, note Test 2 will not be sent
> 3. Alter the kernel to not drop the packet
> I do not know what is going to happen if you do this, so use at
> your own risk. Diff from a linux 2.4.2 kernel
> # diff ip_nat_standalone.c ip_nat_standalone.c.orig
> 81c81
> < return NF_ACCEPT;
> ---
> > return NF_DROP;
>
> For other 2.4 kernels you may want to look for the line:
> printk(KERN_DEBUG "NAT: %u dropping untracked packet %p %u %u.%u.%u.%u -> %u.%u.
> %u.%u\n",
>
> The next statement should be the return.
(6247839) /Stephen A. Zarkos <obsid@SENTRY.NET>/(Ombruten)
6249187 2001-03-19 19:48 +0100 /27 rader/ bert hubert <ahu@DS9A.NL>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-21 03:54 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ahu@DS9A.NL
Mottagare: Bugtraq (import) <16014>
Kommentar till text 6242179 av Stephen White <swhite@OX.COMPSOC.NET>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: bert hubert <ahu@DS9A.NL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010319194822.A17350@home.ds9a.nl>
On Sat, Mar 17, 2001 at 12:31:22AM +0000, Stephen White wrote:
> On Wed, Mar, 2001, Bret wrote:
> > either by creating a new 'timestamp clock' for
> > each TCP session (that uses timestamps)
>
> You can't do this .. it breaks the use of such timestamps for things
> like TCP Sequence number wrap-around protection on fast networks
> (gigabit).
Yes you can. PAWS is not needed to differentiate *different*
sessions, unless you also cycle through all your local ports in a few
seconds. Which is exceedingly unlikely.
Regards,
bert hubert
--
http://www.PowerDNS.com Versatile DNS Services
Trilab The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
(6249187) /bert hubert <ahu@DS9A.NL>/-----(Ombruten)
6249191 2001-03-19 20:49 +0100 /42 rader/ van der Kooij, Hugo <Hugo.van.der.Kooij@CAIW.NL>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-21 03:58 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Hugo.van.der.Kooij@CAIW.NL
Mottagare: Bugtraq (import) <16015>
Kommentar till text 6242527 av Darren Reed <avalon@COOMBS.ANU.EDU.AU>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: "van der Kooij, Hugo" <Hugo.van.der.Kooij@CAIW.NL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.30.0103192041590.5473-100000@bastion.hugo.vanderkooij.org>
On Sat, 17 Mar 2001, Darren Reed wrote:
> In some mail from Bill_Royds@pch.gc.ca, sie said:
> >
> > Actually, the logic is "This has been up for 300 days. It probably is not
> > being maintained so it likely has that unpatched exploit avaialable".
>
> I thought about this before I posted that email but decided against any
> inclusion of it. Why ?
>
> There are systems running around the world, today, that *need* to run
> 24x7 and security patches are no reason for a reboot. That aside, that
> a system has been up, since its release, longer than it takes the time
> information to wrap, do you *really* know how long it has been up ?
So if a system can't be brought down for a reboot what do you do in
case of a system failure. Be it hardware or software you have a
problem way beyond a reboot.
If anything is that mission critical you should make it redundant.
In the past our company used to accept a no-reboot-now policy by the
customer. However we stopped to do this because any mission critical
system must be made redundant. So we can reboot a firewall at 17:00
if we need to install security fixes.
we usually don't need to play it hard. But if a 5 minute interruption
is unacceptable you should make things redundant because hardware
will breakdown when it is extremely inconvinient.
Hugo.
--
Hugo van der Kooij; Oranje Nassaustraat 16; 3155 VJ Maasland
hugo@vanderkooij.org http://hvdkooij.xs4all.nl/
--------------------------------------------------------------
(6249191) /van der Kooij, Hugo <Hugo.van.der.Kooij@CAIW.NL>/(Ombruten)
6249215 2001-03-19 13:18 -0700 /23 rader/ Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-21 04:23 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: deraadt@CVS.OPENBSD.ORG
Mottagare: Bugtraq (import) <16018>
Kommentar till text 6243326 av Matt Lewis <barkode-bugtraq@NINJAS.ORG>
Ärende: Re: TCP Timestamping and Remotely gathering uptime information
------------------------------------------------------------
From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200103192018.f2JKIi502180@cvs.openbsd.org>
> Darren Reed said:
>
> > Why do you think all timestamps should not reveal uptime information ?
>
> Well, not to speak on Bret's behalf per se, but personally, I've seen
> plenty of software (the quality of which may be in question) that uses
> uptime (or clock-ticks-since-boot, whatever) for a variety of things,
> albeit ususally trivial.
Lots of such things exist. One example is RPC, which used to generate
it's initial XID (which are subsequently incremented per transaction)
from tv.tv_sec ^ tv.tv_usec ^ getpid(). On systems with predictable
boot sequences, predictable pids, and known boot time, it is possible
to figure out the window of XID usage, and spoof replies.
Other such thigns do exist, get discovered, etc etc etc, and fixed on
their own. However, ... it's nice to fix problems by accident.
(6249215) /Theo de Raadt <deraadt@CVS.OPENBSD.ORG>/-
6249253 2001-03-20 20:23 +1100 /32 rader/ Darren Reed <avalon@COOMBS.ANU.EDU.AU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-21 05:20 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: avalon@COOMBS.ANU.EDU.AU
Mottagare: Bugtraq (import) <16020>
Kommentar till text 6242179 av Stephen White <swhite@OX.COMPSOC.NET>
Ärende: Remote fingerprinting/uptime (was Re: TCP Timestamping ...)
------------------------------------------------------------
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200103200923.UAA08191@cairo.anu.edu.au>
I'm not sure the "TCP timestamping allows fingerprinting" holds a lot
of water. nmap's capabilities for determining what version of an OS
is at the other end are pretty complete. So far as TCP fingerprints
go, it's how often it changes (and by how much) that's at issue, not
just what it gets seeded to. While nmap fingerprinting may not tell
you how long a box has been up, it has capabilities to tell you what
version the kernel is regardless of how long it has been up.
Changing a system's algorithm for TCP timestamping just introduces
yet another mechanism for nmap to use in determining what version of
kernel is at the other end.
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 ?
Just to recap, knowing a host has been up for n days only means you
know it can't be an OS/kernel that has been released in those n days
and any associated information that goes with that.
You know nothing else. If a box has been up 50 days then that
doesn't tell you it is 2.0 or 2.2 or 2.3 or 2.4. It just tells you
it can't be anything that's been released in less than 50 days.
Darren
(6249253) /Darren Reed <avalon@COOMBS.ANU.EDU.AU>/(Ombruten)
6258836 2001-03-21 12:59 -0600 /46 rader/ Jason R Thorpe <thorpej@ZEMBU.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-22 21:34 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: thorpej@zembu.com
Mottagare: Bugtraq (import) <16061>
Kommentar till text 6249253 av Darren Reed <avalon@COOMBS.ANU.EDU.AU>
Ärende: Re: Remote fingerprinting/uptime (was Re: TCP Timestamping ...)
------------------------------------------------------------
From: Jason R Thorpe <thorpej@ZEMBU.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010321125915.D3681@dr-evil.wireless.meeting.ietf.org>
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>
(6258836) /Jason R Thorpe <thorpej@ZEMBU.COM>/(Ombruten)