Live data from Hacker News

CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

openwall.com

191–200 of 254 posts

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#191

Earlier quoted context omitted.

> 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++. 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 fro…

You're not reading it correctly. Microsoft's critical vulns are nearly all of the class of errors that, say, Rust, solves. Memory safety issues. If Windows was written in, e.g. Rust, all those security issues simply would not have happened. I'm not sure how I can make this more clear. While you can write dumb code in any language, programmers somehow end up not writing remote code execution from simple copies in othe…

> You're not reading it correctly. Microsoft's critical vulns are nearly all of the class of errors that, say, Rust, solves. Memory safety issues. If Windows was written in, e.g. Rust, all those security issues simply would not have happened. I'm not sure how I can make this more clear.

And what I'm saying is that you're solving the problem in the wrong place. I'll take a static analysis tool that will find a buffer overrun at compile time over a runtime that blows up the program in production, every time.

> While you can write dumb code in any language, programmers somehow end up not writing remote code execution from simple copies in other languages. Yet in C, this keeps happening.

Shellshock, eval, SQL injection, people will write dumb code that results in remote code execution using whatever you like.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#192
post #48
post #26

RedHat has patches out for RHEL5 only so far https://rhn.redhat.com/errata/RHSA-2015-0090.html

The Qualys security advisory says that it was fixed independently in 2013, so RHEL6 and 7 might already have the fix. http://www.openwall.com/lists/oss-security/2015/01/27/9

I spent most of the day tracking down the status of various Linux distros. Blog post forthcoming, but the TL;DR is that you need to patch RedHat.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#193

Earlier quoted context omitted.

You're not reading it correctly. Microsoft's critical vulns are nearly all of the class of errors that, say, Rust, solves. Memory safety issues. If Windows was written in, e.g. Rust, all those security issues simply would not have happened. I'm not sure how I can make this more clear. While you can write dumb code in any language, programmers somehow end up not writing remote code execution from simple copies in othe…

> You're not reading it correctly. Microsoft's critical vulns are nearly all of the class of errors that, say, Rust, solves. Memory safety issues. If Windows was written in, e.g. Rust, all those security issues simply would not have happened. I'm not sure how I can make this more clear. And what I'm saying is that you're solving the problem in the wrong place. I'll take a static analysis tool that will find a buffer…

Cool, well in all this time, all the C static and dynamic security features are still failing. So today, in the real world, your choices seem to be either fail at runtime or fail and execute arbitrary code.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#194
post #187

Earlier quoted context omitted.

Except, "just use another language! All problems of this huge category solved!" is true in this case. You can't have buffer overflows on a memory-safe language. Sure, this is only true assuming the VM and all the stuff it depends on is formally verified not to have buffer overflows either, which is unlikely to happen. But even so, you get the slightly weaker guarantee: "just use another language! All problems of this…

Rust provides memory safety without VM to begin with. Although I do not like the comparison because it's not factually correct, Rust is like the "safe subset of C++". To write actual safe, modern C++ is very close to writing valid Rust. After learning Rust, I became a better C++ programmer.

As I understand it (and keep in mind I have never used Rust, so I might be completely wrong), Rust does have ways to perform unsafe pointer operations and the standard library includes code that does this, no? So, replace VM with libstd. Even if this is not the case, the compiler could produce code that is not memory safe due to bugs in the compiler itself. Turtles all the way down and all that.

Either way, I am all for reducing the number of places where random pointer juggling happens inside a program, be it by using a VM or forbidding certain language features outside of small system libraries (e.g. by banning "unsafe fn" from your own Rust code or by using a static checker to force you to use only the "safe subset of C++"). That way we just need to get a couple thousand lines of code right to solve this particular class of nastiness forever, instead of the hundreds of millions of LOCs that live above the system abstractions.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#195
post #37

Is Ubuntu 12.04 vulnerable to this? >> this vulnerability affects many systems from Linux glibc-2.2 version published on 10 November 2000. >> a fixed was pushed to glibc-2.17 et glibc-2.18 Ran dpkg -l libc6 on 12.04.5 shows it's 2.15. So anything before 2.17? /lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Ubuntu EGLIBC 2.15-0ubuntu10.7) stable release version 2.15, by Roland McGrath et al.

Blog post coming soon, but 12.04 is vulnerable, but has a patch available.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#196

RedHat has a fix for 6 and 7 now: https://rhn.redhat.com/errata/RHSA-2015-0092.html

Does anyone have any insight into when we'll see CentOS packages start hitting the mirrors?

Packages are ready, but if your mirror don't have them, use manual way: http://systemz.pl/post/fast-ghost-fix-for-cve-2015-0235/ It's for CentOS 6

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#197
post #165

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.

I was responding to the later posts who were confused as to why someone would laugh at seeing that. You're right that you said to check and I wasn't trying to bash that post at all.

That aside, I actually did type it into my disposable VM. The theory being that if there was something subtle, it would force me either to type it wrong and not be exploited due to cognitive blindness or I'd catch the problem and avoid it.

I've read too many IOCC entries and I probably am a bit paranoid.

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#198

Here is the test program, from http://www.openwall.com/lists/oss-security/2015/01/27/9 https://gist.github.com/koelling/ef9b2b9d0be6d6dbab63 To test your system, simply run this (but obviously only after making sure gistfile1.c is clean ;)) wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c gcc gistfile1.c -o CVE-2015-0235 ./CVE-2015-0235

Anyone know how reliable that test is? I've got a system reporting not vulnerable but I'm not sure what glibc it has.

glibc 2.18 and greater were already patched, but it wasn't recognized as an RCE vulnerability at the time. See the first bullet under the "Mitigating factors" section in the link.

You can check your libc version with:

  ldd --version

Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

#200

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…

> It's time to start phasing out C/C++

Well, unless you get rid of C/C++ interfaces in all syscalls or Win32 APIs, hell Microsoft tried that with managed code, and utterly failed to deliver.

Post reply on HN