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:

NetBSD Home
NetBSD PR Database Search

(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.