Magnitude of glibc Vulnerability Coming To Light (threatpost.com)

msm1267 writes: The glibc vulnerability disclosed this week has some experts on edge because of how DNS can leveraged in exploits. Dan Kaminsky said that while man-in-the-middle attacks are one vector, it would appear that it's also possible to exploit the bug and attack most Linux servers via DNS caching-only servers. 'This would be substantially worse if it went through the caching ecosystem; 99 percent of attack vectors go through that system,' Kaminsky said. Glibc, or the GNU C library, is used by most flavors of Linux and also a number of popular web services and frameworks, giving attacks potentially massive horizontal scale. The major Linux distros have patched and pushed updates to servers; source code is also available for homegrown Linux builds.

Comments

Defense

[Anonymous Coward]

iptables -t raw -A PREROUTING -p udp --sport 53 -m length --length 28:2000 -j DROP
The above line will block any attack based on this vulnerability.
It may impact some unusual but legitimate queries, though. Normal DNS queries usually have small enough responses to fit in this range.
If the above line is on a Linux machine that is performing as a trusted caching DNS server, it will also protect the clients from the attack.
You might be able to get a few more bytes into the threshold (because there are headers in the DNS protocol) and I am not exactly sure where the overflow happens (raw packet, UDP payload, DNS payload, etc.). As a bonus, this will also drop unreasonably small packets.

strlcpy() isn't good enough for glibc.

[emil]

No, it "only leads to other errors".

Funny, I haven't heard of any showstopper bugs in OpenBSD libc - not this year, not ever. And it's ubiquitous, since I'm running it on my phone.

This bug, after ghost, would be a good opportunity to take a step back for a serious assessment of what must be removed for a secure system.