171–180 of 254 posts
Relevant AWS thread https://forums.aws.amazon.com/thread.jspa?threadID=170359&ts...
https://alas.aws.amazon.com/ALAS-2015-473.html
As usual, the Elastic Beanstalk team (with their forked yum repositories) are lagging behind on a fix.
Here's a quick writeup I made with all of the information I found in this thread. Feedback welcome: http://product.reverb.com/2015/01/28/patching-cve-2015-0235-...
Good writeup, I liked the gists you picked out. I've got some feedback though: The bug has been fixed (May 21, 2013, between the releases of glibc-2.17 and glibc-2.18). So your statement "This bug effects all versions of libc6 greater than 2.2+ (which was released Nov, 10, 2000) so you’ll be really lucky if you’re not vulnerable." is wrong. For example, Ubuntu 14.04 uses glibc-2.19-1 which isn't affected.
Earlier quoted context omitted.
Reason why people defend unsafe languages: If you make it idiot-proof, someone will make a better idiot.
Care to point out all the RCEs that exist in the millions of lines of C# and Java out there? Apart from exec/eval I don't recall seeing a single one (I'm sure there's a few where they interop or use unsafe code.)
That's 12 just in one of the more popular Java web frameworks.
RCE is possible in any language.
This is embarrassing. We now know that the line "with many eyes, all bugs are shallow" is just wrong. What we do know now is that the open source process does not converge to a no-bugs state. It's time to start phasing out C/C++. Languages which don't know how big their arrays are have to go. If it can run efficiently in a garbage-collected environment, it should be in Go or some scripting language. If it can't use G…
Nobody to be taken serious has ever thought or said this -- it says about as much as "You know, I'm not perfect...".
Go itself (as of 1.3) is still itself coded in C, and I have no idea if/how C and Rust are related... C isn't going away, and tooling (Coverity, valgrind, nice compilers like clang) are our friends, as well as work like OpenBSDs string-handling ammendments, malloc() guards, etc.
I really am sympathetic to the complaints against C, but "Burn it!! It's a witch!" doesn't grab me.
Earlier quoted context omitted.
All the time: SQLi, XSS, arbitrary file upload, ...
XSS is a totally different level. When's the last time a bunch of networked devices needed patches because of XSS? And even if these problems were as widespread, eliminating a huge class of errors is a big step up. Nearly every serious vulnerability in Microsoft's code for the past years is from memory unsafeness. Hell, why bother with malaria or smallpox vaccines, since people just die from something else anyways.
Of course we should work to eliminate problems, but you have to consider the bigger picture and whether abandoning the language is worth it. So far the pros outweigh the few unique cons.
Earlier quoted context omitted.
You're piping random executables from the internet without even looking at them to see what they do if you run that command.
There's no pipe involved in the GPs posting. It downloads a source file and the post even points out to check the file before compiling. I actually copied and pasted the test code from the original advisory. Should I have typed it in with my own bare fingers to be more secure? I agree with your sentiment in general, you just picked the wrong example to bash here.
Earlier quoted context omitted.
Having a shorthand makes it a lot easier for people to freak out and panic unnecessarily, too. "Heartbleed" was big enough to warrant a world-wide freakout, but this is a remote buffer overflow with many requirements for success. From http://www.openwall.com/lists/oss-security/2015/01/27/9 : --[ 3 - Mitigating factors ]-------------------------------------------------- The impact of this bug is reduced significantly…
>You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit would you? If you want to exploit something that does unauthenticated gethostbyaddr(), then yes, for that you need to control a DNS server (which, btw, isn't harder than controlling a web server to serve malware with). On the other hand, if you can make your target call gethostbyname() on an…
Fetching a user-supplied URL is not enough to exploit remotely. You have to exploit the target's DNS resolver, because you have to feed it invalid or impossible records. All existing DNS resolvers will reject these because they break RFC.
It would be much easier to exploit a web app and drop your payload and exploit it locally, which is what everyone currently does to pwn servers with rootkits.
This is embarrassing. We now know that the line "with many eyes, all bugs are shallow" is just wrong. What we do know now is that the open source process does not converge to a no-bugs state. It's time to start phasing out C/C++. Languages which don't know how big their arrays are have to go. If it can run efficiently in a garbage-collected environment, it should be in Go or some scripting language. If it can't use G…
> We now know that the line "with many eyes, all bugs are shallow" is just wrong.
Remains approximately similar to saying, while watching the tide go out, that sea levels aren't rising. Anyone who ever thought it meant they were fixed instantaneously, and who uses the fact they get fixed and found as counter-proof of the sentiment, was wrong. It doesn't make the idea fundamentally wrong.
Earlier quoted context omitted.
> I find it pretty funny how no matter how many times we're shown that unsafe languages blow up on all sorts of code by all sorts of programmers, anyone would still try to defend the language. Heartbleed, Shellshock, Ghost. OpenSSL implemented their own memory allocator, so you would get the same result in another language. Shellshock was a parsing failure, memory safety had nothing to do with it, still arbitrary cod…
Shellshock is somewhat atypical for systems vulns no? Looking at all the CVEs for Microsoft for a couple of years, essentially all critical security exploits are due to their use of C/C++. Heartbleed would not happen just because of a custom allocator. Eg Rust allows you to do so, but would have prevented that code from compiling. Basically, using C/C++ means that in addition to all the normal security logic errors l…
You're kind of answering your own question. Most OS bugs are in C because most OS code is in C.
> Heartbleed would not happen just because of a custom allocator. Eg Rust allows you to do so, but would have prevented that code from compiling.
If you get a large buffer and then "allocate" it by returning pointers to pieces of it (or offsets if you don't have pointers), now the compiler/runtime only knows where the end of the buffer is, not where the end of the allocation is supposed to be. You can write dumb code in any language.
> Basically, using C/C++ means that in addition to all the normal security logic errors like command injection, you've got to worry that an errant copy or overflow hands total execution control to an attacker. It's bizarre to not realise this is a huge language failing and that most of the systems level exploits are purely due to poor languages.
The problem with this reasoning is that it's solving the problem in the wrong place. Yes, if you screw up very badly then it's better for the language to blow up the program than let the attacker control it. But you still have to solve the other problem, which is that the attacker can blow up the program or possibly do other things even with "safe" languages because the program is parsing unvalidated input etc. And solving that problem, which needs to happen regardless, causes the first problem to go away.