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.
For being glib about it. (ba dump)
Those programmers are 'shitty, incompetent programmers' if they can't be bothered to learn about the problems their tools have. All tools have problems. It's their job to understand their tools.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
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.
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.
It should be obvious that "compiles" and "doesn't crash" isn't the same thing as "works as intended"
True. In fact, even rust can crash under certain circumstances. For example, when the stack gets too large, or when a heap allocation fails. But all crashes of rust are "safe", meaning that they usually don't allow for data modification. And yes, rust doesn't guarantee freedom from bugs. But it does eliminate whole classes of bugs. On the path to more secure programs we do need languages with more additional safety, not less.
What programmers need to learn is good programming habits and discipline.
And the rust compiler enforces precisely those. Without enforcement (or warnings) you go nowhere. Rust's ownership concepts allows one to do multithreading without any fears. Consider a codebase with 500k lines and multiple threads: do you know when and how some thread accesses a shared resource? Most times not.
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.
In the real world, getting work done means knowing the well understood problems with your tools. It's not like buffer overflows where not mentioned in everybody's introduction to C (course/competent self study). Explain to your boss that sanitizing inputs took to long, so all the tables in production got dropped...I hope you're 12 or at least don't code for living...seriously.
Thanks for volunteering to speak up for all the other shitty, incompetent programmers out there BTW. Way to jump on that grenade.
I'll grant you there are edge cases where tools are so shitty, you can't possibly know a tiny fraction of the serious problems. I'd argue those tools don't belong in production.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
We know its syntax is a step backward from C, C++, Java, C#, and even PHP.
Rust has many improvements over C/C++ syntax wise:
* syntactic macros, not "string replacement" macros
* scoped macros -- you don't pollute macro space
* scoped imports
* Nested comments -- no #if 0 trick needed to comment out code that contains block comments
* Blocks {} can have a return value, the ; sign is a separator, not a terminator
* If the compiler can find out the type of something, it is implied, otherwise you have to provide it. Only in recent C++ this is possible with the auto keyword.
Where is the "step backward" you talk about? Yes, they have abandoned the ? operator but that's no catastrophy, is it?
We know its resource management approach is confusing, even when you understand how it works and how to use it.
The resource management is in fact very useful, and I think the strong mutability requirements are a feature. I don't deny that sometimes its confusing, and that it contributes to rust's steep learning curve. But still, git has a steep learning curve as well, and there its certainly worth the effort, too.
according to its issue tracker it's really buggy
Yes, the repo counts 2302 open bugs, but they track feature requests in their issue tracker too. The actual bugs are much less.
We know there's only one implementation of it
Rust is a young language, and unfortunately there is only one implementation of it. Perhaps later on we'll get more implementations.
We know it took them fucking forever get Rust 1.0 out the door, and even then it wasn't stable.
Parts of rust are stable, parts aren't. If you use a release or beta channel rust compiler you only can use stable APIs. The fact that you see unstable features in the API docs as well is only to inform you what's upcoming.
We know that C++ has continued to evolve and can offer pretty much everything Rust offers.
You can write safe code in C++, but there is no guarantee. And C++ is promised to be backwards compatible. It has to support all the unsafe constructs that were introduced some day, most of them inherited from C. And yes, probably a C++ linter can do most of the job rust does as well, but as of now I haven't heard from a good free as in software linter that is as strict as rustc, and when you have to fix tons of linter warnings, you most times still have to basically do a rewrite of the program already. Then you can also rewrite it in rust.
We know that the Rust community is quite totalitarian, with an intolerant code of conduct and a mod team to take out anyone they don't like.
I agree, and think their "code of conduct" is very harmful to their project and makes people think that everybody who likes rust is an SJW. I claim to like rust and hate SJWs.
We question Mozilla's future
Mozilla is the biggest threat to rust's future, I agree. They had managed to publish a quite stable browser for ten years or so, but since 2014-ish they are acting weirdly, and this does impact rust negatively. I hope that rust will stay stable, and won't introduce breaking changes.
We ignore Rust because it just isn't a viable option!
Well yeah it isn't a viable option for super-big projects just yet, with less than one year of stability. Perhaps in five or more years rust has gained enough maturity and large enough support from the industry that its "too big to fail".
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.
Odd, I don't remember writing this.
However as this is a Linux vulnerability, it was openly discussed and it was fixed at once.
There, FTFY.
It was disclosed in July last year. That doesn't meet my definition of "at once".
https://sourceware.org/bugzilla/show_bug.cgi?id=18665
You might have an off-by-times-negative-one error in there, oops!
How can you preach about not making known C-language mistakes when you still make known English-language mistakes? Is it presumed that programmers have an easier time writing perfect C than writing perfect English?
If they stopped thrashing the code and put the new features in a new product, the existing product would reliably improve over time, regardless of what types of idiot mistakes they started out with. As long as the code is being frequently updated, it will have new bugs. Humans make mistakes, it is a fact and you are not immune. You are wrong to insist that it is somehow dysfunctional for humans to make known mistakes. Mistakes are the expected nominal condition!
How would they know to use C99, but not to switch to C17 or whatever comes in the future, that will doubtless have new bugs? And if they were using a clib from pre-C99... would it even be vulnerable to this bug? (no, it was introduced much later)
If the code is being continually updated, there is no escape from continually having new bugs and security holes. If you only fix real bugs, and don't add any features, then you still have new bugs in the fixes but the frequency will go down over time because less than 100% of new code is actually a bug, and so eventually the bug generation frequency would average less than a byte.
Automate catching a simple bug like buffer overflows and you leave developers too retarded to find the more serious memory map related exploits.
See also: Every Java only programmer you ever met.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Nobody is arguing about glibc. That's well understood to be a giant 'ball of mud', so nobody can know all it's problems.
We are arguing about the C language. To some extent the C++ language. AC in particular thinks knowing that unchecked buffer overflows exist as a class of exploits is too much to ask of C programmers.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
MS stopped being such a security concern once NAT came around then windows firewall as more of a standard apart from MSIE.