search menu icon-carat-right cmu-wordmark

CERT Coordination Center


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

Vulnerability Note VU#457875

Original Release Date: 2002-11-19 | Last Revised: 2004-10-18

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 = 216. If they are not predictable, m = 232. 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

P1 = 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

P2 = 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,

Pn = q / (m - (n - 1))

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

Qn = 1 - Pn = 1 - (q / (m - (n - 1)))

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

CumulativeMissn = Q1*Q2*...*Qn

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

CumulativeHitr = 1 - CumulativeMissr

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 Pr. 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 = 216, 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

advisory-CAIS-vagner.pdf

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
Expand all

Apple Computer Inc.

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

Status

  Vulnerable

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.

Debian

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

Status

  Vulnerable

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.

Fujitsu

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

Status

  Vulnerable

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.

ISC

Updated:  November 18, 2002

Status

  Vulnerable

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.

InfoBlox

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

Status

  Vulnerable

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

MetaSolv Software Inc.

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

Status

  Vulnerable

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.

Microsoft Corporation

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

Status

  Vulnerable

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.

NetBSD

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

Status

  Vulnerable

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.

Openwall GNU/*/Linux

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

Status

  Vulnerable

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.

Check Point

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

Status

  Not Vulnerable

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.

GNU glibc

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

Status

  Not Vulnerable

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.

Network Appliance

Updated:  November 19, 2002

Status

  Not Vulnerable

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.

Xerox Corporation

Updated:  May 30, 2003

Status

  Not Vulnerable

Vendor Statement

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

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.

adns

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

Status

  Not Vulnerable

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.

BSDi

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

BlueCat Networks

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Conectiva

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Cray Inc.

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Data General

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Engarde

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

FreeBSD

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Hewlett-Packard Company

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

IBM

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Lucent Technologies

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

MandrakeSoft

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Men&Mice

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

MontaVista Software

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

NEC Corporation

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Nixu

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Nortel Networks

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

OpenBSD

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.

Red Hat Inc.

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

SGI

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

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
security-info@sgi.com.

                      ------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
security-info@sgi.com.

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 wiretap-request@sgi.com
subscribe wiretap <YourEmailAddress such as zedwatch@sgi.com >
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
security-info@sgi.com.

For reporting *NEW* SGI security issues, email can be sent to
security-alert@sgi.com 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.

Sequent

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

ShadowSupport

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Sony Corporation

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

SuSE Inc.

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Sun Microsystems Inc.

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

The SCO Group (SCO Linux)

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

The SCO Group (SCO UnixWare)

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Threshold Networks

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Unisys

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Wind River Systems Inc.

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.

Wirex

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

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding 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.


CVSS Metrics

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A

References

Credit

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: 2002-11-19
Date First Published: 2002-11-19
Date Last Updated: 2004-10-18 15:01 UTC
Document Revision: 47

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.