Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
severity 491809 important retitle 491809 DNS stub resolver could be hardened. thanks On Fri, Jul 25, 2008 at 10:06:01PM +, 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[EMAIL PROTECTED] OOOhttp://www.madism.org pgp0uU6riVYD6.pgp Description: PGP signature
Processed: Re: Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
Processing commands for [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
Processing commands for [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
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 `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
* 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
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 `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
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 `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
* 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
* 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
On Tue, Jul 22, 2008 at 03:24:06PM +, 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[EMAIL PROTECTED] OOOhttp://www.madism.org pgpdjnl4NkwlT.pgp Description: PGP signature
