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
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
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
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
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
* 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
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
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
* 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
* 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
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
11 matches
Mail list logo
