Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

[Brian M. Carlson]

Package: libc6
Version: 2.7-12
Severity: critical
Tags: security

The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA
1605.  Since the vast majority of network-using programs use glibc as a
resolver, this vulnerability affects virtually any network-using
program, hence the severity.  libc6 should not be released without a fix
for this problem.

The vulnerability has been exposed:

http://demosthen.es/post/43048623/reliable-dns-forgery-in-2008

If Slashdot knows it, so does everyone else.

-- System Information:
Debian Release: lenny/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libgcc1                       1:4.3.1-6  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
pn  glibc-doc                     <none>     (no description available)
ii  locales-all [locales]         2.7-12     GNU C Library: Precompiled locale

-- debconf information:
   glibc/upgrade: true
   glibc/restart-failed:
   glibc/restart-services:

--
brian m. carlson / brian with sandals: Houston, Texas, US
[phone] | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[Aurelien Jarno]

brian m. carlson a écrit :

> Package: libc6
> Version: 2.7-12
> Severity: critical
> Tags: security
>
> The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA
> 1605.  Since the vast majority of network-using programs use glibc as a
> resolver, this vulnerability affects virtually any network-using
> program, hence the severity.  libc6 should not be released without a fix
> for this problem.
>
> The vulnerability has been exposed:
>
> http://demosthen.es/post/43048623/reliable-dns-forgery-in-2008
>
> If Slashdot knows it, so does everyone else.
>

With a recent kernel, I don't think the glibc stub resolver is
vulnerable: contrary to some other resolvers, the it binds to an
unspecified port and let the kernel decide the source port.

The source port randomization has been implemented in the kernel one
year ago [1], so all machines using a kernel >= 2.6.24 should be safe.

Also please note that the glibc as a stub resolver is less vulnerable
than a recursive resolver, as an attacker would have to spoof one of the
ISP's nameservers, which is much more unlikely than spoofing one of the
servers on a recursive resolution path.

[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@...         | aurelien@...
   `-    people.debian.org/~aurel32 | www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Weimer]

* brian m. carlson:

> The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA
> 1605.  Since the vast majority of network-using programs use glibc as a
> resolver, this vulnerability affects virtually any network-using
> program, hence the severity.  libc6 should not be released without a fix
> for this problem.
>
> The vulnerability has been exposed:
>
> http://demosthen.es/post/43048623/reliable-dns-forgery-in-2008

I fail to see how this attack has a chance to work against non-caching
stub resolvers like the GNU libc resolver.

However, we're working on a solution.



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

Florian Weimer a écrit :

> * brian m. carlson:
>
>> The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA
>> 1605.  Since the vast majority of network-using programs use glibc as a
>> resolver, this vulnerability affects virtually any network-using
>> program, hence the severity.  libc6 should not be released without a fix
>> for this problem.
>>
>> The vulnerability has been exposed:
>>
>> http://demosthen.es/post/43048623/reliable-dns-forgery-in-2008
>
> I fail to see how this attack has a chance to work against non-caching
> stub resolvers like the GNU libc resolver.
>
> However, we're working on a solution.

As already said previously on this bug log, I don't think there is
something to do for the glibc resolver. glibc stub resolver uses an
unspecified UDP port, so it is eventually chosen by the kernel. As a
consequence this has to be handled in the kernel, and is already fixed
in kernel >= 2.6.24 [1].

tcpdump show that using a >= 2.6.24 kernel (lenny kernel), the ports are
correctly randomized. With a 2.6.18 kernel (etch kernel), the ports
*are* not randomized.

IMHO, the UDP randomization commit has to be backported to the etch
kernel. The advantage of this solution, is that it potentially fixes
other bugs/vulnerabilities in other protocols/programs using UDP.

Cheers,
Aurelien

[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=32c1da70810017a98aa6c431a5494a302b6b9a30
--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@...         | aurelien@...
   `-    people.debian.org/~aurel32 | www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Weimer]

* Aurelien Jarno:

> IMHO, the UDP randomization commit has to be backported to the etch
> kernel. The advantage of this solution, is that it potentially fixes
> other bugs/vulnerabilities in other protocols/programs using UDP.

Currently, there is no suitable patch to backport.  I hope that improved
port randomization will be available shortly.



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

Florian Weimer a écrit :
> * Aurelien Jarno:
>
>> IMHO, the UDP randomization commit has to be backported to the etch
>> kernel. The advantage of this solution, is that it potentially fixes
>> other bugs/vulnerabilities in other protocols/programs using UDP.
>
> Currently, there is no suitable patch to backport.  I hope that improved
> port randomization will be available shortly.

You mean a patch for the kernel?

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@...         | aurelien@...
   `-    people.debian.org/~aurel32 | www.aurel32.net



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Florian Weimer]

* Aurelien Jarno:

>> Currently, there is no suitable patch to backport.  I hope that improved
>> port randomization will be available shortly.
>
> You mean a patch for the kernel?

Yes, one for the kernel, and one for the transaction ID generation in
the libc resolver, too.

(Oh, and "shortly" == "next week or so".)



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Pierre Habouzit-2]

On Tue, Jul 22, 2008 at 03:24:06PM +0000, Florian Weimer wrote:

> * Aurelien Jarno:
>
> >> Currently, there is no suitable patch to backport.  I hope that improved
> >> port randomization will be available shortly.
> >
> > You mean a patch for the kernel?
>
> Yes, one for the kernel, and one for the transaction ID generation in
> the libc resolver, too.
>
> (Oh, and "shortly" == "next week or so".)

  Assuming the TID generator for the glibc is "good enough" and that the
flaw is the one described in [0], then the glibc code (even nscd) isn't
vulnerable, because it doesn't cache or even look at the additional
records.

  The problems with QID randomization are quite orthogonal, and it's a
problem known for 20 years now (using last QID+1 isn't really an option
;p). Having a better random number generator will probably help, but
quite doesn't require such a severity (as there is already randomization
of the QIDs, maybe not a perfect one).

  So unless you have further non yet disclosed informations, I'd
suggest reconsidering the DSA.


  [0] http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-forgery.html

--
·O·  Pierre Habouzit
··O                                                madcoder@...
OOO                                                http://www.madism.org

[Debian Bug Tracking System]

Your message dated Wed, 23 Jul 2008 16:26:49 +0200
with message-id <20080723142649.GD20614@...>
and subject line Re: Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
has caused the Debian Bug report #491809,
regarding libc6: DNS spoofing vulnerability [CVE-2008-1447]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@...
immediately.)


--
491809: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491809
Debian Bug Tracking System
Contact owner@... with problems

Package: libc6
Version: 2.7-12
Severity: critical
Tags: security

The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA
1605.  Since the vast majority of network-using programs use glibc as a
resolver, this vulnerability affects virtually any network-using
program, hence the severity.  libc6 should not be released without a fix
for this problem.

The vulnerability has been exposed:

http://demosthen.es/post/43048623/reliable-dns-forgery-in-2008

If Slashdot knows it, so does everyone else.

-- System Information:
Debian Release: lenny/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc6 depends on:
ii  libgcc1                       1:4.3.1-6  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
pn  glibc-doc                     <none>     (no description available)
ii  locales-all [locales]         2.7-12     GNU C Library: Precompiled locale

-- debconf information:
   glibc/upgrade: true
   glibc/restart-failed:
   glibc/restart-services:

--
brian m. carlson / brian with sandals: Houston, Texas, US
[phone] | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


On Tue, Jul 22, 2008 at 04:02:13PM +0000, Pierre Habouzit wrote:

> On Tue, Jul 22, 2008 at 03:24:06PM +0000, Florian Weimer wrote:
> > * Aurelien Jarno:
> >
> > >> Currently, there is no suitable patch to backport.  I hope that improved
> > >> port randomization will be available shortly.
> > >
> > > You mean a patch for the kernel?
> >
> > Yes, one for the kernel, and one for the transaction ID generation in
> > the libc resolver, too.
> >
> > (Oh, and "shortly" == "next week or so".)
>
>   Assuming the TID generator for the glibc is "good enough" and that the
> flaw is the one described in [0], then the glibc code (even nscd) isn't
> vulnerable, because it doesn't cache or even look at the additional
> records.
>
>   The problems with QID randomization are quite orthogonal, and it's a
> problem known for 20 years now (using last QID+1 isn't really an option
> ;p). Having a better random number generator will probably help, but
> quite doesn't require such a severity (as there is already randomization
> of the QIDs, maybe not a perfect one).
>
>   So unless you have further non yet disclosed informations, I'd
> suggest reconsidering the DSA.

  Kaminsky agrees confirm the issue, so I can say for sure that the
glibc isn't vulnerable to the attack he describes, as it needs a
resolver that caches additionnal RRs, which the glibc doesn't do.

  As of attacks that would use non randomized source port use, this is
addressed by recent kernels hence is fixed enough. Note that such
answers are only cached when nscd host caching is in used, and it's off
by default in Debian nscd default setup.

  I'm hence closing the bug.

--
·O·  Pierre Habouzit
··O                                                madcoder@...
OOO                                                http://www.madism.org

[Florian Weimer]

reopen 491809
thanks

* Pierre Habouzit:

>   Kaminsky agrees confirm the issue, so I can say for sure that the
> glibc isn't vulnerable to the attack he describes, as it needs a
> resolver that caches additionnal RRs, which the glibc doesn't do.

>   As of attacks that would use non randomized source port use, this is
> addressed by recent kernels hence is fixed enough.

I've trouble parsing what you wrote.

Based on information provided at the DNS summit, I do think we should
harden the glibc stub resolver.



--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Debian Bug Tracking System]

Processing commands for control@...:

> reopen 491809
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
Bug reopened, originator not changed.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


--
To UNSUBSCRIBE, email to debian-glibc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Pierre Habouzit-2]

severity 491809 important
retitle 491809 DNS stub resolver could be hardened.
thanks

On Fri, Jul 25, 2008 at 10:06:01PM +0000, Florian Weimer wrote:

> reopen 491809
> thanks
>
> * Pierre Habouzit:
>
> >   Kaminsky agrees confirm the issue, so I can say for sure that the
> > glibc isn't vulnerable to the attack he describes, as it needs a
> > resolver that caches additionnal RRs, which the glibc doesn't do.
>
> >   As of attacks that would use non randomized source port use, this is
> > addressed by recent kernels hence is fixed enough.
>
> I've trouble parsing what you wrote.

  What I mean, is that the glibc performs no additionnal RR caching,
which is how the attack poisons caches. Moreover the glibc is _not_ a
recursive resolver either. And finally it also uses random source ports,
which is the simplest way to prevent Kaminsky's attack.

> Based on information provided at the DNS summit, I do think we should
> harden the glibc stub resolver.

  That's another matter which doesn't warrant a critical severity at
all. The glibc stub resolver is already "safe enough" by many standards.
I don't deny it could be hardened though (Improving the RNG is probably
not a bad idea).

--
·O·  Pierre Habouzit
··O                                                madcoder@...
OOO                                                http://www.madism.org

[Debian Bug Tracking System]

Processing commands for control@...:

> severity 491809 important
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
Severity set to `important' from `critical'

> retitle 491809 DNS stub resolver could be hardened.
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
Changed Bug title to `DNS stub resolver could be hardened.' from `libc6: DNS spoofing vulnerability [CVE-2008-1447]'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


--
To UNSUBSCRIBE, email to debian-glibc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...