Slashdot Mirror
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.
Who saw the name of the library, immediately went "oh, another C buffer attack," and rolled their eyes?
It's interesting how these things go.
If this would have been a vulnerability in MSVCRT, everyone would have mocked Microsoft and Windows.
However as this is a Linux vulnerability, the attention is turned to the used programming language instead.
Something to think about.
In the event you didn't see his constant ads, APK's activities were a commercial activity on this site, which an ad supported, non-government operated site has every right to block. The fact that he was incredibly annoying and abusive about dealing with criticism is just icing on the cake.
Get back to me when they start dealing with people who aren't billboards for a commercial product whose only other activity is trolling people who provide criticisms of said product.
If this would have been a vulnerability in MSVCRT, it would be concealed as long as possible, and who knows when it would be fixed?
However as this is a Linux vulnerability, it was openly discussed and it was fixed at once.
There, FTFY.
Anti-virus software is an arms race. This is a change to the fundamental behavior of the compiler toolchain and produced code.
Think like someone tells you dishwashers are dangerous because they use high-temperature hot water, and then your glasses all crack because they drop from 145F as they're exposed to the cold air when you open the door after a wash cycle. You then point out that your glassware is all borosilicate glass and can take a temperature drop of 120 degrees celsius across 1 second without damage. Going from boiling to ice water won't break your glass; heating it dry over an acetyloxy torch and then dumping it in an ice bath *will* shatter it.
What you're looking at here isn't a system that catches one specific attack signature. You're looking at an attack which fundamentally relies on overflowing a buffer on the stack, rewriting RETP with an address on the stack that contains code injected as part of the overflow, and then jumping into that code on RETL instruction. This executes your code from the stack.
Meanwhile, the software being attacked stores a runtime-randomized word between the stack variables and RETP, then verifies it hasn't changed before a call to RETL, so you have to guess a 32-bit or 64-bit integer (1 in 4 billion or 1 in 16 billion*billion). If that fails, the system *still* has randomized the stack base, so you have to load a value into RETP which points to your code on the stack, which can be in any of thousands or millions of locations. Should you manage to guess both a one-in-four-billion and a one-in-524-thousand value simultaneously (one-in-2251-billion-billion) (or bigger on 64-bit), the stack is still non-executable: the OS will claim a general protection fault due to trying to execute non-executable memory.
That means this attack can't be carried out successfully without extreme luck (1 in 9.7 billion billion billion) or advanced knowledge of the program's address space (which the attacker must inspect while the program is running--it changes on every run); and even then, the attack has to do something distinctly other than injecting code. Heap, main executable, and library load addresses are also randomized on each run, so luck in dodging out the primary protections leads directly to rolling bigger dice in hopes of getting lucky a third time.
In this particular attack, you can't just launch an attack at a target. You have to gain control of DNS responses for that target, then wait for the target to make a DNS query. All of the above then apply. Good luck.
Support my political activism on Patreon.