NetBSD Problem Report #11288
Received: (qmail 25213 invoked from network); 22 Oct 2000 18:26:41 -0000
Message-Id: <200010221827.e9MIR4J13196@zorkmid.mit.edu>
Date: Sun, 22 Oct 2000 14:27:04 -0400 (EDT)
From: John Hawkinson <jhawk@mit.edu>
Reply-To: jhawk@mit.edu
To: gnats-bugs@gnats.netbsd.org
Subject: NetBSD's IP stack leaks information in the ip_id
X-Send-Pr-Version: 3.95
>Number: 11288
>Category: kern
>Synopsis: NetBSD's IP stack leaks information in the ip_id
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: jhawk
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Sun Oct 22 18:27:00 +0000 2000
>Closed-Date:
>Last-Modified: Thu Dec 08 10:03:59 +0000 2016
>Originator: John Hawkinson
>Release: -current 22 Oct 2000
>Organization:
MIT
>Environment:
System: NetBSD zorkmid.mit.edu 1.5E NetBSD 1.5E (ZORKMID-$Revision: 1.2 $) #54: Fri Aug 18 01:53:49 EDT 2000 jhawk@zorkmid.mit.edu:/usr/local/netbsd-current/src/sys/arch/i386/compile/ZORKMID i386
>Description:
NetBSD's IP stack leaks information in the form of the ip_id.
It does so in two ways:
1. The initial value of the ip_id is initialized to the wall-clock time.
2. The ip_id is incremented by one eveyr time a packet is transmitted.
I can see no good reason for (1). Presumably the intent is to prevent
multiple machines for syncrhonizing their initial ip_id values, however
that's manifestly not the case if machines reboot at the same time,
which is a well-understood phenomenon. On the flipside, it's really not
very concerning that an attacker could gain information about the boot time
of a machine.
(2) is somewhat more complicated. It can be terribly useful in debugging
network problems to know that consecutive packets have consecutive ip_id
values, and careful analysis of ip_ids in a stream of packets can give you
good information about loss and duplication characteristis of the network,
even if you only control one of the endsystems.
On the other hand, there's a serious information-leak. You can determine to
what extent a machine is utilizing its network interface, whether there is
any other network activity, etc. This can be utilized in nasty attacks
involving forging the source address of traffic to be a machine, and then
probing the forged machine to see if it transmitted packets, which might be
replies to the replies to the forged packets. etc.
>How-To-Repeat:
Inspection.
(1) initialization, in ip_init() in ip_input.c:
303 LIST_INIT(&ipq);
304 ip_id = time.tv_sec & 0xffff;
305 ipintrq.ifq_maxlen = ipqmaxlen;
(2) increment, in ip_output() in ip_output.c:
217 /*
218 * Fill in IP header.
219 */
220 if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) {
221 ip->ip_v = IPVERSION;
222 ip->ip_off &= IP_DF;
223 ip->ip_id = htons(ip_id++);
224 ip->ip_hl = hlen >> 2;
225 ipstat.ips_localout++;
226 } else {
>Fix:
For (1), presumably random initializtion would be better?
As for (2), I would suggest that there should be a sysctl to control this
behavior, with the default being the current status quo (though that could
change in the future), since that's the most useful for diagnostic purposes.
Additional possible behaviors:
a) A solution that doesn't leak information:
i. Something pseudorandom or cryptorandom -based.
ii. Something time-based.
b) A solution that limits the leaked information in a way that's
useful, for instance a solution involving a hash of the destination
ip address, such that data about lost IPs might be derived only for
your own host. I suppose this is likely prohibitive expensive
in terms of space and state.
>Release-Note:
>Audit-Trail:
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
To: jhawk@mit.edu
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: security/11288: NetBSD's IP stack leaks information in the ip_id
Date: Sun, 22 Oct 2000 14:54:33 -0400
This is not a security issue.
1) Synchronization of ip_id values between systems is not a concern
since the id is used in conjunction with the source address and
protocol of the packet for assembly.
In a world where efficiency was not a concern, the counter would be
preserved across reboot.
2) I fail to understand the concern regarding leaking information
about usage levels. On most moderately active systems, the 16-bit
ip_id counter will wrap one or more times a day. my main server
system at home typically wraps the counter 11 times a day; a laptop of
mine which spends most of its time suspended still sent somewhat over
1.1 million packets in 12 days -- i.e., the counter wrapped 18 times
Unless you can provide an efficient (i.e., <10 instruction) keyed
permutation function over the 16 bit integers, I suspect that a "cure"
may be worse than the current behavior.
- Bill
State-Changed-From-To: open->suspended
State-Changed-By: sommerfeld
State-Changed-When: Sun Oct 22 11:55:14 PDT 2000
State-Changed-Why:
not a reasonable request
Responsible-Changed-From-To: security-officer->jhawk
Responsible-Changed-By: sommerfeld
Responsible-Changed-When: Sun Oct 22 11:55:14 PDT 2000
Responsible-Changed-Why:
let submitter propose an implementable solution.
From: John Hawkinson <jhawk@MIT.EDU>
To: sommerfeld@orchard.arlington.ma.us
Cc: gnats-bugs@netbsd.org
Subject: Re: security/11288: NetBSD's IP stack leaks information in the ip_id
Date: Sun, 22 Oct 2000 15:32:19 -0400
In message <20001022185438.0B6432A2A@orchard.arlington.ma.us>, Bill Sommerfeld
writes:
>1) Synchronization of ip_id values between systems is not a concern
>since the id is used in conjunction with the source address and
>protocol of the packet for assembly.
The observation is that a machine that just returns to the network
after a long period of absence betrays whether it was just rebooted,
or just re-connected to the network after a long absence by virtue
of it's ip_id. This is not terribly concerning, but it is an
information leak.
>In a world where efficiency was not a concern, the counter would be
>preserved across reboot.
Fine with me.
>2) I fail to understand the concern regarding leaking information
>about usage levels. On most moderately active systems, the 16-bit
>ip_id counter will wrap one or more times a day. my main server
>system at home typically wraps the counter 11 times a day; a laptop of
>mine which spends most of its time suspended still sent somewhat over
>1.1 million packets in 12 days -- i.e., the counter wrapped 18 times
That's correct. Moderately active systems are not really the issue.
It is the case of idle systems.
a) An attacker can determine if an apparently idle system is actually idle,
or whether it is performing some reasonably amount of network activity.
Active polling of the machine for it's ip_id counter is required, of course.
b) Suppose someone wishes to perform a stealth port scan. Alan the
attacker is targetting Tom the target. Alan selects an innocent
bystander Innocent I who appars to be completely idle. Alan probes
Innocent I for his ip_id conuter. Alan forges SYN (or whatever) to Tom
sourced from Innocent I's IP address; Tom replies to Innocent I with
a SYN+ACK, and Innocent I replies to the SYN+ACK with an RST. Alan
probes Innocent I and discovers that Innocent I has transmitted a packet,
deducing that Tom has the port open. If Tom did not have the port open,
Innocent I would have received an RST, which would have been discarded.
There are probably other more ingenious attacks that might be able
to make use of such a feature.
>Unless you can provide an efficient (i.e., <10 instruction) keyed
>permutation function over the 16 bit integers, I suspect that a "cure"
>may be worse than the current behavior.
That might very well be.
It might be worth looking at other operating systems, also. For what it's
worth, NT4 (SP6, I believe, not 100%) appears to increment the ip_id by
256. I don't know why.
--jhawk
From: itojun@iijlab.net
To: jhawk@mit.edu
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: security/11288: NetBSD's IP stack leaks information in the ip_id
Date: Mon, 23 Oct 2000 09:06:56 +0900
>As for (2), I would suggest that there should be a sysctl to control this
>behavior, with the default being the current status quo (though that could
>change in the future), since that's the most useful for diagnostic purposes.
>
>Additional possible behaviors:
>
> a) A solution that doesn't leak information:
> i. Something pseudorandom or cryptorandom -based.
> ii. Something time-based.
> b) A solution that limits the leaked information in a way that's
> useful, for instance a solution involving a hash of the destination
> ip address, such that data about lost IPs might be derived only for
> your own host. I suppose this is likely prohibitive expensive
> in terms of space and state.
for (2), it is rather hard problem. we cannot just use random number
as we need to prevent reuse of the number for certain period of time
(and this is the reason for the use of sequential number).
we just need to do what openbsd is doing. they have special random
number generator, which has very long reuse period, for ip_id.
itojun
From: itojun@iijlab.net
To: jhawk@netbsd.org
Cc: gnats-admin@netbsd.org
Subject: Re: security/11288: NetBSD's IP stack leaks information in the ip_id
Date: 23 Oct 2000 00:08:02 -0000
The following reply was made to PR kern/11288; it has been noted by GNATS.
From: itojun@iijlab.net
To: jhawk@mit.edu
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: security/11288: NetBSD's IP stack leaks information in the ip_id
Date: Mon, 23 Oct 2000 09:06:56 +0900
>As for (2), I would suggest that there should be a sysctl to control this
>behavior, with the default being the current status quo (though that could
>change in the future), since that's the most useful for diagnostic purposes.
>
>Additional possible behaviors:
>
> a) A solution that doesn't leak information:
> i. Something pseudorandom or cryptorandom -based.
> ii. Something time-based.
> b) A solution that limits the leaked information in a way that's
> useful, for instance a solution involving a hash of the destination
> ip address, such that data about lost IPs might be derived only for
> your own host. I suppose this is likely prohibitive expensive
> in terms of space and state.
for (2), it is rather hard problem. we cannot just use random number
as we need to prevent reuse of the number for certain period of time
(and this is the reason for the use of sequential number).
we just need to do what openbsd is doing. they have special random
number generator, which has very long reuse period, for ip_id.
itojun
From: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: kern/11288
Date: Mon, 20 Nov 2000 13:49:41 +0100
JHawk writes:
> It might be worth looking at other operating systems, also. For what
> it's worth, NT4 (SP6, I believe, not 100%) appears to increment the
> ip_id by 256. I don't know why.
Easy. They increment by 1, then fail to htons() it.
-is
From: David Laight <david@l8s.co.uk>
To: gnats-bugs@gnats.netbsd.org
Cc:
Subject: Re: PR/11288
Date: Sun, 22 Nov 2009 21:10:18 +0000
Some time ago the kernel was changed to use 'random' ip_ids.
Unfortunately the random number used (and still in use) will
reuse id values sooner than it should.
David
--
David Laight: david@l8s.co.uk
State-Changed-From-To: suspended->open
State-Changed-By: maya@NetBSD.org
State-Changed-When: Thu, 08 Dec 2016 10:03:59 +0000
State-Changed-Why:
opening again because it's off by default
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.