Adding qa@ to Cc:. Reminder: bug is non-public and must not be disclosed.
Just that you don't have to hack your way to the information. :-)

Bitte verscharrt euch aus diesem Bug, wenn ihr das unbändigbare Bedürfnis habt.
Thought it's wise to have you updated until there is a timeline.

Bindige Grüße,
Roman.

more information came from CERT (said thanks already):


From: CERT Coordination Center <cert@cert.org>
To: SuSE Security Team <security@suse.de>
Cc: CERT Coordination Center <cert@cert.org>
Date: Tue, 25 Nov 2003 21:58:14 -0500
Subject: Re: [security@suse.de] Publication Date for VU#734644 - suse


Roman,

Roman Drahtmueller <draht@suse.de> writes:

> I am sure that you agree that there is not much information that would
> help us any further down the road of roviding an update package for each
> of our products. Can you provide us with any patch or other detailed
> information on the issue? We'd be very grateful for it.

We don't have access to a patch for this vulnerability; the best we'd be
able to do is create a diff from the source that's on the ISC FTP site.
We've also not received any detailed technical description of the
vulnerability, but we do have something that might increase your
understanding of it...

I asked the ISC to tell us a bit more about where the vulnerability was,
and they provided the following example:

    You can demonstrate the fault in a cache by querying a server
    configured like the following for attack-www-uu-net.example.net.

    zone "example.net" {
         type master;
         file "example.db";
    };
    zone "uu.net" {             // zone under attack
         type master;
         file "empty.db";
    };

    example.db contains:
    $TTL 7200
    @       SOA     . . 1 3600 1200 840000 7200
    @       NS      <name of hosting server>.
    attack-www-uu-net CNAME www.uu.net.

    empty.db: (Just SOA and NS records)
    $TTL 7200
    @   SOA     . . 1 3600 1200 840000 7200
    @   NS      <name of hosting server>.

With this example and a bit of research on negative responses, I came up
with the following description of the vulnerability, which I'll be using
in our public document:

    Several versions of the BIND 8 name server are vulnerable to cache
    poisoning via negative responses.  To exploit this vulnerability, an
    attacker must configure a name server to return authoritative negative
    responses for a given target domain.  Then, the attacker must convince
    a victim user to query the attacker's maliciously configured name
    server.  When the attacker's name server receives the query, it will
    reply with an authoritative negative response containing a large TTL
    (time-to-live) value.  If the victim's site runs a vulnerable version
    of BIND 8, it will cache the negative response and render the target
    domain unreachable until the TTL expires.

Given the immediate need for vendors to understand this vulnerability and
prepare an appropriate response, if you find this information useful, you
may pass it along to your colleagues on vendor-sec.

If you have any other questions, please feel free to ask.

Thanks,

Jeffrey

-----------------------------
Jeffrey P. Lanza
Internet Security Analyst
CERT Coordination Center

The vulnerability type (network DoS) justifies to hurry up with the issue.
No patches yet.

patch attachment added: from Ryan W. Maple <ryan@guardiandigital.com> via 
vendor-sec.

Created attachment 15402 [details]
cachenegative patch for bind8.

I've written Mark Andrews <marka@isc.org> by encrypted PM.

Jeffrey talks in comment #0 and #2 only about BIND 8 and the patch is also BIND
8 only.

I'm working on packages now.

Patch adapted to all BINd 8 version for SL 7.3 - 8.2; 9.0 doesn't include BIND 8.

I'll copy all versions after mbuild finished.

brilliant. Rudi says that all of the hilberts will be online soon so that
building can start.
Do we know for sure that the issue affects bind8 only and not bind9?

I am writing the patchinfo files (box and BP) now.

Thanks!

The BIND 9 source is completly different. I didn't find the ns_resp() function
as from bin/named/ns_resp.c nor the relevant place where the new variable
cachenegative is used. IMHO BIND 9 is ok.

I'll test the BIND 8 package only on SLES 8 and add a short report.

I've additionally checked the BIND 9.2.3 release notes. There's no message like
'Security Fix: Negative Cache Poison Fix.' from the file
ftp://ftp.isc.org/isc/bind/src/8.4.3/8.4.3-REL or '1581. [bug]    apply
anti-cache poison techniques to negative answers.' from the CHANGES file of the
tar ball.

The bug was originally fixed with release 8.4.2, Thu Sep  4 06:58:22 PDT 2003.

Remove BIND 9 from summary. All SUSE versions fixed.

Since EnGarde Linux and Immunix OS announced new bind8 versions I approved our 
packages too. 

opening the bug scope to a broader audience.

CVE-2003-0914: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)