Message-ID: <47D95BFB.2090205@trusteer.com>
Date: Thu, 13 Mar 2008 18:53:15 +0200
From: Amit Klein <amit.klein@...steer.com>
To: bugtraq@...urityfocus.com
Cc: Amit Klein <amit.klein@...steer.com>
Subject: Update+Errata: Re: A paper by Amit Klein (Trusteer): "OpenBSD DNS
 Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability"

Update+Errata for "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability"
(http://www.trusteer.com/docs/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf)


Update
******


OpenBSD
=======
Apparently the OpenBSD team changed their mind (again...) and have
now incorporated a fix for the DNS server transaction ID
predictability, and the IP ID predictability, in the OpenBSD 4.3
branch. The solution in both cases resembles that of DragonFlyBSD
and NetBSD.
It seems that OpenBSD does not plan to address the DNS resolver
transaction ID predictability though.


FreeBSD
=======
As expected, FreeBSD 7.0 was announced recently without a fix. This
was communicated beforehand by the FreeBSD team and stated in the
original paper.


DragonFlyBSD
============
DragonFlyBSD 1.12.0 is the first BSD operating system to roll out a
solution to the IPv4 issue as part of the official version.


Apple MacOS X 10.5.2, MacOS X Server 10.5.2, Darwin 9.2
(all sharing the same kernel: xnu-1228.3.13)
=======================================================
Apple did NOT fix the predictable IP ID issue in its products
(in Leopard 10.5.2).


IPv6
====
None of the vendors addressed the similar issues in IPv6.


Misc.
====
NetBSD has not addressed the issue in the RPC XID code.


Errata
******
The original paper mentioned that MacOS X has a particular
implementation bug wherein it always sets seed=0. However, this is
not accurate. the tmp variable changes each time ip_randomid() is
called, and thus it is not guaranteed that seed=0. Nevertheless, it
can be easily shown that seed=0 in about 50% of the key intervals.
This is because at the re-keying time, tmp has probability of around
50% to have its higher 16 bits 0.

So the Mac/Darwin platform remains particularly vulnerable.


Thanks,
-Amit
CTO, Trusteer




Amit Klein wrote:
> Hello BugTraq
>
> Recently I've been looking at the OpenBSD PRNG implementation for
> DNS transaction ID (OpenBSD ported BIND 9 into their code tree,
> but rolled their own PRNG for the DNS transaction ID field). I
> discovered a serious weakness in OpenBSD's PRNG, which allows an
> attacker to predict the next transaction ID (typically up to 8-10
> guesses) given a series of consecutive 12-15 transaction IDs. As
> you may appreciate, this enables DNS cache poisoning for OpenBSD
> much like my earlier attacks on BIND 9, BIND 8 and Microsoft
> Windows DNS server.
>
> Interestingly enough, OpenBSD uses a flavor of this PRNG for
> another field, this time the IP fragmentation ID, part of the
> OpenBSD kernel network stack. The analysis carries out quite
> similarly to show that OpenBSD's IP ID is predictable as well,
> which gives way to O/S fingerprinting, idle-scanning, host alias
> detection, traffic analysis, and in some cases, even to TCP blind
> data injection.
>
> But it gets more interesting. Several other BSD operating systems
> copied the OpenBSD code for their own IP ID PRNG, so they're
> vulnerable too. This is particularly so with Apple's Mac OS X,
> Mac OS X Server and Darwin, but also with NetBSD, FreeBSD and
> DragonFlyBSD (the 3 latter O/S however only use this PRNG when
> the kernel flag net.inet.ip.random_id is set to 1; it is 0 by
> default, resulting in a sequential counter to be used instead...).
> OpenBSD, NetBSD and FreeBSD also use this PRNG for IP
> fragmentation ID normalization feature (e.g. "scrub out random-
> id") in the packet filter module.
>
> Somewhat more distant flavors are used for various IPv6 fields
> across many BSD operating systems, which may be affected, and
> some other O/S not mentioned here, including possibly non-BSD O/S
> may be affected, since this code seems to have been extensively
> copied and modified.
>
> All the above mentioned vendors were contacted November 2007.
> FreeBSD, NetBSD and DragonFlyBSD committed a fix to their
> respective source code trees. OpenBSD decided not to fix, and
> Apple refused to provide any schedule for such fix.
>
> The full paper is available at the following URL:
>
> http://www.trusteer.com/docs/dnsopenbsd.html
>
>
> The impact per O/S is summarized below:
>
>
> * OpenBSD 3.3-4.2
>
> o   DNS server cache poisoning (predictable DNS
>    transaction ID).
>
>
> * OpenBSD 2.6-4.2
>
> o   Idle-scanning, O/S fingerprinting, host alias
>    detection, traffic analysis, TCP blind data injection,
>    etc. (predictable IP fragmentation ID) in "regular" IP
>    packets and raw IP packets.
>
> o   Predictable IP fragmentation ID in Ethernet-inside-IP
>    encapsulation, IP-inside-IP encapsulation, the CARP
>    protocol, IP multicast routing, pfsync interface
>    protocol, packet filter (IP packet normalization), and
>    network bridge (ICMP error packets).
>
>
> * OpenBSD 2.5-4.2
>
> o   libc resolver predictable DNS transaction ID (the
>    source UDP port is random though).
>
>
> * Mac OS X 10.0-10.5.1, Mac OS X Server 10.0-10.5.1, Darwin
>  1.0-9.1
>
> o   Idle-scanning, O/S fingerprinting, host alias
>    detection, traffic analysis, TCP blind data injection,
>    etc. (predictable IP fragmentation ID) in "regular" IP
>    packets and raw IP packets.
>
> o   Predictable IP fragmentation ID in DHCP, IP multicast
>    routing and IPsec encapsulation in IP.
>
>
> * NetBSD 1.6.2-4.0
>
> o   Idle-scanning, O/S fingerprinting, host alias
>    detection, traffic analysis, TCP blind data injection,
>    etc. when the packet filter is used to normalize
>    outbound IP packets (predictable IP fragmentation ID).
>
> o   Predictable IP fragmentation ID in the CARP protocol.
>
>
> * NetBSD 1.6.2-4.0 (if the kernel flag net.inet.ip.random_id
>  is 1)
>
> o   Idle-scanning, O/S fingerprinting, host alias
>    detection, traffic analysis, TCP blind data injection,
>    etc. (predictable IP fragmentation ID) in "regular" IP
>    packets and raw IP packets.
>
> o   Predictable IP fragmentation ID in IP multicast
>    routing, IP-inside-IP encapsulation and IPsec
>    encapsulation in IP.
>
>
> * FreeBSD 4.4-7.0
>
> o   Idle-scanning, O/S fingerprinting, host alias
>    detection, traffic analysis, TCP blind data injection,
>    etc. when the packet filter is used to normalize
>    outbound IP packets (predictable IP fragmentation ID).
>
> o   Predictable IP fragmentation ID in the pfsync
>    interface protocol.
>
>
> * FreeBSD 4.4-7.0 (if the kernel flag net.inet.ip.random_id
>  is 1)
>
> o   Idle-scanning, O/S fingerprinting, host alias
>    detection, traffic analysis, TCP blind data injection,
>    etc. (predictable IP fragmentation ID) in "regular" IP
>    packets and raw IP packets.
>
> o   Predictable IP fragmentation ID in the CARP protocol,
>    IP multicast routing, SCTP, IP-inside-IP encapsulation
>    and IPv6 over GRE.
>
>
> * DragonFlyBSD 1.0-1.10.1 (if the kernel flag
>  net.inet.ip.random_id is 1)
>
> o   Idle-scanning, O/S fingerprinting, host alias
>    detection, traffic analysis, TCP blind data injection,
>    etc. (predictable IP fragmentation ID) in "regular" IP
>    packets and raw IP packets.
>
> o   Predictable IP fragmentation ID in the CARP protocol,
>    IP multicast routing, and IP-inside-IP encapsulation.
>
>
>
> Thanks,
> -Amit
>
> Amit Klein
> CTO
> Trusteer
>
>

Powered by blists - more mailing lists