Various DNS service implementations generate multiple simultaneous queries for the same resource record

Overview

Various implementations of DNS services may allow multiple simultaneous queries for the same resource record, allowing an attacker to apply probabilistic techniques to improve their odds of successful DNS spoofing.

Description

Some implementations of DNS services contain a vulnerability whereby multiple requests for the same resource record (RR) will generate multiple outstanding queries for that RR. As a result, it is possible for an attacker to apply a ‘birthday attack’ technique to dramatically improve the probability of a successful DNS spoofing attack. When performed against a caching nameserver, this can result in cache poisoning; however, similar techniques could be applied to some stub resolvers as well.

The only distinction between this attack and the traditional brute-force approach (1 query with multiple spoofed replies) is the generation of multiple simultaneous queries. The attacker need not sniff any packets between the victim resolver and the legitimate nameservers for the RR being spoofed. An attacker’s success against any particular resolver instance will be probabilistic in nature, with a persistent attacker always being able to achieve a reasonable probability of success given enough attempts.

By rapidly generating multiple queries for an RR to a vulnerable resolver, the attacker can induce a condition whereby the vulnerable resolver has multiple open queries for that RR. The attacker then sends a number of spoofed responses to the vulnerable resolver. Given the right combination of open queries and spoofed responses, the attacker can achieve a high probability of success with far fewer packets (by several orders of magnitude) than the traditional brute-force approach would require.

This attack is quite effective against caching nameservers that provide recursive services. Recent research by Gummadi, Saroiu, and Gribble [GUMMADI] indicates that a large proportion of nameservers are configured to provide recursive services to the Internet at large, thereby laying them open to this kind of attack.

The specific number of packets required to exploit any particular DNS resolver vary by implementation, but the following table lists a few of the more common scenarios found in a number of implementations

| If the attacker has to guess…|…and is limited to the following number of open requests…|…it will take the following number of packets to achieve a 50% success rate
(includes both requests and responses)
—|—|—
TID only (16bits)| 1| 32.7 k (215)
TID only (16bits)| 4| 10.4 k
TID only (16bits)| 200| 427
TID only (16bits)| unlimited| 426
TID and port (32 bits)| 1| 2.1 billion (231)
TID and port (32 bits)| 4| 683 million
TID and port (32 bits)| 200| 15 million
TID and port (32 bits)| unlimited| 109 k
Table 1: Number of packets required to reach 50% success probability for various numbers of open queries
As expected, the traditional brute-force case where the attacker tries to guess the transaction ID or TID/port pair based on a single open request requires the attacker to search half the search space (15 or 31 bits, respectively) to achieve a 50% probability of success. However, when the attacker is able to induce the resolver into generating multiple simultaneous requests, the total number of packets required falls off rapidly.

There are, of course, more effective methods to achieve DNS spoofing in certain cases, including sniffing query packets directly or the predictable transaction ID issues discussed in CA-1997-22 “BIND - the Berkeley Internet Name Daemon”. Additionally, Michal Zalewski’s paper “Strange Attractors and TCP/IP Sequence Number Analysis” [ZALEWSKI] describes a method for analyzing the predictability of transaction IDs which we believe could be extended to analyze Transaction ID / UDP port pairs as well. Zalewski’s paper was also discussed in CA-2001-09 “Statistical Weaknesses in TCP/IP Initial Sequence Numbers”.

The ‘birthday attack’ method described here appears to be reasonably well known in the DNS developer community, but we have been unable to find significant public discussion of it and are thus documenting it here.

Further discussion of the probability calculations

Assume that the transaction IDs generated by the vulnerable resolver are unpredictable by the attacker (if they’re not, then the attack is far simpler than what we describe here; see CA-1997-22 for more). The attacker does not know what the transaction IDs are, but can control how many transaction IDs the vulnerable resolver has open for a particular query at a given time by generating a series of otherwise legitimate queries. (The total number of transaction IDs open on the vulnerable resolver does not factor into this – only the transaction IDs resulting from the attacker’s queries count.)

Let

m = the number of possible transaction ID / UDP port combinations

q = the number of open queries initiated by the attacker

r = the number of bogus replies generated by the attacker

Note that if the UDP ports are predictable, m = 2__16. If they are not predictable, m_ = 2__32_. Of course, if both the transaction IDs and UDP ports are predictable, m approaches 1.

The goal for the attacker, therefore, is to find the smallest possible sum of (q + r) with a maximum probability of success.

The first bogus reply sent by the attacker will have a probability of success given by

P__1_ = q / m_

The attacker does not need to care whether any particular reply was successful or not. The only thing the attacker has to keep track of is what IDs have been sent in the bogus replies so there will not be any duplicates. Thus, since the attacker knows what the ID was in the first reply and doesn’t want to repeat IDs, he only has a pool of (m - 1) IDs to pick from on the second reply. Therefore, the second reply has a probability of success of

_P__2 _= q / (m - 1)

Likewise, for each successive iteration, the number of possible IDs the attacker will pick from shrinks by 1. In the generic case,

_P__n __= q / (m - (n - 1)) _

Each P__n represents the probability of success in the _n_th iteration, independently of all previous iterations. We can therefore represent the probability of a miss in the _n_th iteration as Qn where

Q__n_ = 1 - P__n__ = 1 - (q / (m - (n - 1))) _

The cumulative probability of having missed in all iterations up to and including the _n_th iteration is

CumulativeMiss__n_ = Q__1__Q__2__…*Q__n_

and therefore the cumulative probability of at least one success with r bogus replies is

CumulativeHit__r_ = 1 - CumulativeMiss__r_

Thus we can calculate the probability of compromise given q queries and r replies. We do this by iteratively fixing q and incrementing r until we reach the desired P__r. To find the optimal combination of q and r, we repeat the process for a number of values of q. “Optimal” is defined as the minimum sum of (q + r).

When one considers cases where q > 1, it quickly becomes evident that the attacker’s advantage grows significantly with relatively small numbers of queries (q << m). For example, performing the calculations as described above for m_ = 2__16_, the attacker’s probability of success reaches the 50% mark with as few as (q + r) ~= 425 packets.

References:

[GUMMADI] Krishna P. Gummadi, Stefan Saroiu, and Steven D. Gribble, “King: Estimating Latency between Arbitrary Internet End Hosts”, http://www.icir.org/vern/imw-2002/imw2002-papers/198.pdf

[ZALEWSKI] Michal Zalewski, “Strange Attractors and TCP/IP Sequence Number Analysis”, <http://razor.bindview.com/publish/papers/tcpseq.html&gt;

Impact

An attacker could leverage this vulnerability to remotely spoof DNS responses, which may lead to DNS cache poisoning.

---

Solution

Apply a patch from your vendor.

---

Disable recursion on any nameserver responding to DNS requests made by untrusted systems. As mentioned in “Securing an Internet Name Server”:

Disabling recursion puts your name servers into a passive mode, telling them never to send queries on behalf of other name servers or resolvers. A totally non-recursive name server is protected from cache poisoning, since it will only answer queries directed to it. It doesn't send queries, and hence doesn't cache any data. Disabling recursion can also prevent attackers from bouncing denial of services attacks off your name server by querying for external zones.
Non-recursive nameservers should be much more resistant to exploitation of the server vulnerabilities listed above.

---

Vendor Information

457875

Filter by status: All Affected Not Affected Unknown

Filter by content: __ Additional information available

__ Sort by: Status Alphabetical

Expand all

Javascript is disabled. Click here to view vendors.

Apple Computer Inc. __ Affected

Notified: October 29, 2002 Updated: December 03, 2002

Status

Affected

Vendor Statement

Affected Systems: Mac OS X and Mac OS X Server.

This is fixed in Security Update 2002-11-21.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

-----BEGIN PGP SIGNED MESSAGE-----
Security Update 2002-11-21 is now available. It contains BIND version 8.3.4 to address multiple potential vulnerabilities.
CVE IDs: CAN-2002-1219, CAN-2002-1220, CAN-2002-1221, CAN-2002-0029
Description: Several of these vulnerabilities may allow remote attackers to execute arbitrary code with elevated privileges. The other vulnerabilities could allow remote attackers to disrupt the normal operation of DNS name service running on servers.
Further information is available at: ``<http://www.cert.org/advisories/CA-2002-31.html>`` ``<http://www.kb.cert.org/vuls/id/457875>``
Affected systems: Systems that have enabled BIND and are using BIND versions 8.1, 8.2 to 8.2.6, and 8.3.0 to 8.3.3.
Mitigating Factors: BIND is not enabled by default on Mac OS X or Mac OS X Server
System requirements: Mac OS X 10.2.2
If BIND is enabled on Mac OS X systems prior to 10.2.2, the recommendation is to either upgrade to Mac OS X 10.2 Jaguar then apply this Security Update, or to update BIND to version 8.3.4 from the ISC site at: ``<http://www.isc.org/products/BIND/bind8.html>``
Security Update 2002-11-21 may be obtained from:
* Software Update pane in System Preferences (for 10.2.2 or later)
* Apple's Software Downloads web site: ``<http://www.info.apple.com/kbnum/n120169>``
To help verify the integrity of Security Update 2002-11-21 from the Software Downloads web site, the download file is titled: SecurityUpd2002-11-21.dmg Its SHA-1 digest is: 9137fc5c1b8922475939ec93ab638494ff6e69be
Information will also be posted to the Apple Support website: ``<http://docs.info.apple.com/article.html?artnum=61798>``
This message is signed with Apple's Product Security PGP key, and details are available at: ``<http://www.apple.com/support/security/security_pgp.html>``
-----BEGIN PGP SIGNATURE----- Version: PGP 7.0.3
iQEVAwUBPd62ayFlYNdE6F9oAQH3DQf+PJNRB5NlLZim8i7hr0ef/obrjGrQ/PNL mpQ0bdgB7huFpUYw52YJcjIIFeI6XSgyP/QEEFfApy98y5CuEDXnC+raMniokD6D L4A25nhRByyxOC5lziKjQKLDWIEktQGXSHYr9cq7oIuo66gAxdQbZrT/brubu9sI p/4g7sO1CuD5P/31RZUdHizG5lbN8dRGNgeh59FYQhpdYMbflrSolFL0FyxVc6aQ UwYbdnlt+wPiDqqWGL+YKv7GXV/XBk29mty6sLHqExx2bL8CH8ttUpZcFa8H+8VM yBXHJ0pnsCPrX+Q32o93ibm3HASXG+JcOrIC1kzvqlldSUvni1w6Kw== =/AHs -----END PGP SIGNATURE-----

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Debian __ Affected

Notified: October 29, 2002 Updated: July 24, 2003

Status

Affected

Vendor Statement

Debian can’t say anything about the vulnerability itself, except that since ISC refers to using tools from bind9, our bind8 packages are probably vulnerable.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Fujitsu __ Affected

Notified: October 29, 2002 Updated: December 03, 2002

Status

Affected

Vendor Statement

Fujitsu’s UXP/V o.s. is vulnerable. The relevant fix (PUF) will be announced at a later date.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

ISC __ Affected

Updated: November 18, 2002

Status

Affected

Vendor Statement

The correct fix is “deploy dnssec”.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

InfoBlox __ Affected

Notified: October 29, 2002 Updated: October 18, 2004

Status

Affected

Vendor Statement

The Infoblox DNS One product is vulnerable when deployed in hostile territory with recursion enabled, for example, as a public Internet name server. See <http://www.infoblox.com/solutions/whitepapers_external.cfm&gt; for details on how to configure the DNS One appliance to avoid this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

MetaSolv Software Inc. __ Affected

Notified: October 29, 2002 Updated: November 18, 2002

Status

Affected

Vendor Statement

MetaSolv Response REF:Vulnerability Note #457875

The BIND code embedded in the DNS Server (Based on ISC BIND 8.2.3) on both MetaSolv Policy Services 4.1 and 4.2 (base) are open to Vulnerability Note #457875. This also applies to the BIND 8.2.6 Base in Policy services 4.2 Service Pack 1 efix 1. This issue is being tracked by MetaSolv under Case #28233. The customer base will be advised as to the potential vulnerability, and when ISC publishes sanctioned libraries these will be applied and published as an efix on Policy Services 4.2 Service Pack 1. MetaSolv Policy Services 5.0 is based on BIND 9.2.2 rc-1 and does not demonstrate the same predilection to the vulnerability as outlined in the note.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Microsoft Corporation __ Affected

Notified: October 29, 2002 Updated: November 19, 2002

Status

Affected

Vendor Statement

The Microsoft DNS Server implementation closely follows the DNS standard. DNS is an insecure protocol and until such time as the protocol describes a method for securing queries, a determined attacker could poison the cache of a DNS Server. A number of precautions in the Microsoft DNS server make this style of attack more difficult, but not impossible. Microsoft is considering additional improvements to its DNS implementation in future versions of the Microsoft DNS sever to reduce the effectiveness of attacks like this.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

NetBSD __ Affected

Notified: October 29, 2002 Updated: November 21, 2002

Status

Affected

Vendor Statement

NetBSD is shipped with ISC BIND nameserver (BIND8). See ISC’s statement for more details.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Openwall GNU/*/Linux __ Affected

Notified: October 29, 2002 Updated: December 04, 2002

Status

Affected

Vendor Statement

One of the features added with BIND 4.9.x-OW patches has always been the addition of unpredictable query IDs, thus making BIND 4 with these patches applied more resistant against the described attacks. The randomization of source port numbers is, however, currently left up to the operating system kernel (and thus doesn’t occur on most systems). Future versions of the patches might add this functionality.

Similarly, the glibc resolver code on Openwall GNU/*/Linux (Owl) has been modified to use unpredictable query IDs (including in the very first version of Owl available to the public), but doesn’t explicitly randomize source port numbers.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Check Point __ Not Affected

Notified: October 29, 2002 Updated: November 04, 2002

Status

Not Affected

Vendor Statement

Check Point products are Not Vulnerable (we don’t employ any caching DNS code).

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

GNU glibc __ Not Affected

Notified: October 29, 2002 Updated: November 18, 2002

Status

Not Affected

Vendor Statement

The GNU C library does not contain a name server; it has only a stub resolver.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Network Appliance __ Not Affected

Updated: November 19, 2002

Status

Not Affected

Vendor Statement

NetApp products are not vulnerable to this problem.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Xerox Corporation __ Not Affected

Updated: May 30, 2003

Status

Not Affected

Vendor Statement

A response to this vulnerability is available from our web site:
<http://www.xerox.com/security&gt;.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

adns __ Not Affected

Notified: October 29, 2002 Updated: November 15, 2002

Status

Not Affected

Vendor Statement

adns is not vulnerable. It is a stub resolver library, not a full-service resolver, and does not forward queries.

If the communication between adns and nameserver can be faked up by the attacker, there can be situations where a similar attack might be made to work. These kind of problems are why the adns documentation tells you that you need to make sure that only packets really from your nameserver can arrive at adns with the nameserver’s source address and port.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

BSDi Unknown

Notified: October 29, 2002 Updated: November 15, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

BlueCat Networks Unknown

Notified: October 29, 2002 Updated: November 18, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Conectiva Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Cray Inc. Unknown

Notified: October 29, 2002 Updated: November 15, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Data General Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Engarde Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

FreeBSD Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Hewlett-Packard Company Unknown

Notified: October 29, 2002 Updated: November 15, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

IBM Unknown

Notified: October 29, 2002 Updated: November 15, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Lucent Technologies Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

MandrakeSoft Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Men&Mice Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

MontaVista Software Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

NEC Corporation Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Nixu Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Nortel Networks Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

OpenBSD __ Unknown

Notified: October 29, 2002 Updated: November 18, 2002

Status

Unknown

Vendor Statement

OpenBSD uses non-repeating psuedo-random transaction IDs in all aspects of DNS.

I am not sure about the other parts yet.

But this is in a highly hacked BIND4.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Red Hat Inc. Unknown

Notified: October 29, 2002 Updated: November 15, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

SGI __ Unknown

Notified: October 29, 2002 Updated: December 05, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

-----BEGIN PGP SIGNED MESSAGE-----

______________________________________________________________________________ SGI Security Advisory
`Title : BIND Name Server DNS Spoofing Vulnerability
Number : 20021203-01-A
Date : December 5, 2002
Reference: CERT Vulnerability Note VU#457875
Reference: SGI BUG 874059

---

- -----------------------

• — Issue Specifics —

---

SGI acknowledges the BIND name server vulnerability reported by Vagner
Sacramento in CERT VU# 457875 (<http://www.kb.cert.org/vuls/id/457875> and
<http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html>) and is
currently investigating. No further information is available at this time.
For the protection of all our customers, SGI does not disclose, discuss
or confirm vulnerabilities until a full investigation has occurred and
any necessary patch(es) or release streams are available for all vulnerable
and supported Linux and IRIX operating systems.
Until SGI has more definitive information to provide, customers are
encouraged to assume all security vulnerabilities as exploitable and take
appropriate steps according to local site security policies and requirements.
As further information becomes available, additional advisories will be
issued via the normal SGI security information distribution methods
including the wiretap mailing list.
`

`- ------------------------

• — Acknowledgments ----

---

SGI wishes to thank Vagner Sacramento, CERT, and the users of the Internet
Community at large for their assistance in this matter.
`

`- --------------

• — Links ----

---

SGI Security Advisories can be found at:
<http://www.sgi.com/support/security/> and
<ftp://patches.sgi.com/support/free/security/advisories/>
SGI Security Patches can be found at:
<http://www.sgi.com/support/security/> and
<ftp://patches.sgi.com/support/free/security/patches/>
SGI patches for IRIX can be found at the following patch servers:
<http://support.sgi.com/irix/> and <ftp://patches.sgi.com/>
SGI freeware updates for IRIX can be found at:
<http://freeware.sgi.com/>
SGI fixes for SGI open sourced code can be found on:
<http://oss.sgi.com/projects/>
SGI patches and RPMs for Linux can be found at:
<http://support.sgi.com/linux/> or
<http://oss.sgi.com/projects/sgilinux-combined/download/security-fixes/>
SGI patches for Windows NT or 2000 can be found at:
<http://support.sgi.com/nt/>
IRIX 5.2-6.4 Recommended/Required Patch Sets can be found at:
<http://support.sgi.com/irix/> and <ftp://patches.sgi.com/support/patchset/>
IRIX 6.5 Maintenance Release Streams can be found at:
<http://support.sgi.com/colls/patches/tools/relstream/index.html>
IRIX 6.5 Software Update CDs can be obtained from:
<http://support.sgi.com/irix/swupdates/>
The primary SGI anonymous FTP site for security advisories and patches is
patches.sgi.com (216.32.174.211). Security advisories and patches are
located under the URL <ftp://patches.sgi.com/support/free/security/>
For security and patch management reasons, ftp.sgi.com (mirrors
patches.sgi.com security FTP repository) lags behind and does not do a
real-time update.
`

`- -----------------------------------------

• — SGI Security Information/Contacts —

---

If there are questions about this document, email can be sent to
[email protected].
------oOo------
SGI provides security information and patches for use by the entire SGI
community. This information is freely available to any person needing the
information and is available via anonymous FTP and the Web.
The primary SGI anonymous FTP site for security advisories and patches is
patches.sgi.com (216.32.174.211). Security advisories and patches are
located under the URL <ftp://patches.sgi.com/support/free/security/>
The SGI Security Headquarters Web page is accessible at the URL:
<http://www.sgi.com/support/security/>
For issues with the patches on the FTP sites, email can be sent to
[email protected].
For assistance obtaining or working with security patches, please
contact your SGI support provider.
------oOo------
SGI provides a free security mailing list service called wiretap and
encourages interested parties to self-subscribe to receive (via email) all
SGI Security Advisories when they are released. Subscribing to the mailing
list can be done via the Web
(<http://www.sgi.com/support/security/wiretap.html>) or by sending email to
SGI as outlined below.
% mail [email protected]
subscribe wiretap <YourEmailAddress such as [email protected] >
end
^d
In the example above, <YourEmailAddress> is the email address that you wish
the mailing list information sent to. The word end must be on a separate
line to indicate the end of the body of the message. The control-d (^d) is
used to indicate to the mail program that you are finished composing the
mail message.
`

------oOo------
SGI provides a comprehensive customer World Wide Web site. This site is located at ``<http://www.sgi.com/support/security/>`` .
------oOo------
If there are general security questions on SGI systems, email can be sent to [email protected].
For reporting *NEW* SGI security issues, email can be sent to [email protected] or contact your SGI support provider. A support contract is not required for submitting a security report.
______________________________________________________________________________ This information is provided freely to all interested parties and may be redistributed provided that it is not altered in any way, SGI is appropriately credited and the document retains and includes its valid PGP signature.
-----BEGIN PGP SIGNATURE----- Version: 2.6.2
iQCVAwUBPe+EALQ4cFApAP75AQEaSQP+OG8GYq1CVDuI+n5Nshn1YOMyiZyLmtId QX9hg1H/kooI5jq0MQdx75iU/9yqRhrtRStrAbjh1IU/Phc5gkXKB9SWBOVHBP1k IaURN2ok6SPCr6yu+/O/bWBlD9c0GHcws70aMrp3NdggaMEOS4Zs4dnJblvTmN7m +DtKIuifJJQ= =AKR/ -----END PGP SIGNATURE-----

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Sequent Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

ShadowSupport Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Sony Corporation Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

SuSE Inc. Unknown

Notified: October 29, 2002 Updated: November 15, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Sun Microsystems Inc. Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

The SCO Group (SCO Linux) Unknown

Notified: October 29, 2002 Updated: November 15, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

The SCO Group (SCO UnixWare) Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Threshold Networks Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Unisys Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Wind River Systems Inc. Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

Wirex Unknown

Notified: October 29, 2002 Updated: October 29, 2002

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23457875 Feedback>).

View all 44 vendors __View less vendors __

CVSS Metrics

Group	Score	Vector
Base
Temporal
Environmental

References

• <http://www.dimap.ufrn.br/&gt;
• <http://www.icir.org/vern/imw-2002/imw2002-papers/198.pdf&gt;
• <http://razor.bindview.com/publish/papers/tcpseq.html&gt;
• <http://mathworld.wolfram.com/BirthdayProblem.html&gt;
• <http://mathworld.wolfram.com/BirthdayAttack.html&gt;
• <http://www.securityfocus.com/guest/17905&gt;
• <http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html&gt;
• <http://www.rnp.br/cais_en/&gt;
• <http://www.cert.org/advisories/CA-1997-22.html&gt;
• <http://www.cert.org/advisories/CA-2001-09.html&gt;
• <http://www.cert.org/archive/pdf/dns.pdf&gt;

Acknowledgements

Thanks to Vagner Sacramento, DIMAp-UFRN. This vulnerability was discovered by Vagner Sacramento during the development of his master thesis in the DIMAp/UFRN (Department of Computer Science and Applied Mathematics / Federal University of Rio Grande do Norte) under the orientation of Prof. Thais Vasconcelos Batista and Prof. Guido Lemos de Souza Filho. CAIS/RNP (the Brazilian Research Network CSIRT) publicly reported the vulnerability after conducting several experiments in order to validate its claims.

This document was written by Allen Householder & Ian A Finlay.

Other Information

CVE IDs:	None
Severity Metric:	40.50 Date Public: