CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow • Hacker News Board

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

#151

Post by tedunangst » Tue, Jan 27, 2015, 9:05 PM UTC

windsurfer wrote: post #138

DangerousPie wrote: post #77

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

I always laugh when people give you a URL to C code to test for remote code execution...

As opposed to code in some other language?

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

#152

Post by YuriNiyazov » Tue, Jan 27, 2015, 9:06 PM UTC

Animats wrote: post #150

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…

Do we really know that the open source process doesn't converge? No specification for the length of time toward convergence exists, and you could argue that this case is an example of inching ever closer to no-bugs state

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

#153

Post by fragmede » Tue, Jan 27, 2015, 9:07 PM UTC

windsurfer wrote: post #138

DangerousPie wrote: post #77

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

I always laugh when people give you a URL to C code to test for remote code execution...

Why?

Reproducers are standard fare and it's not like the code in this case is obfuscated. Are magic code goblins going to come and invoke Ken Thompson's untrustable computing and make your computer install windows and join a botnet or something?

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

#154

Post by dsacco » Tue, Jan 27, 2015, 9:07 PM UTC

Karunamon wrote: post #106

jacques_chester wrote: post #104

Earlier quoted context omitted.

His point is that severity is orthogonal to the coolness of vulnerability names. And that this will cause whacky priorities in future. Plus, 99% of the time, end users are not directly responsible for patching these issues. So why the focus on mass-media friendly marketing?

If the mass media is getting real life sysadmins to get bugged about security holes, how is that anything but a net positive?

That's not the point. The mass media knows nothing about security.

Here is what is happening when vulnerabilities get their own brand names, with logos and marketing:

1. Vulnerabilities are implicitly severe if they attract media attention (and only if they attract media attention). I've been featured in the press twice for vulnerabilities. Neither of them were as serious as the least serious, unpublicized vulnerability on this page: https://hackerone.com/internet.

2. It implicitly encourages rating a vulnerability's severity by how much media attention it receives, not by an objective scale.

It's causing a race to the bottom where coordinated disclosure now requires a PR firm, a presskit, a logo, and a brand name. For Heartbleed and Shellshock, sure, they're serious enough for all those hoops. For everything else, the race to the bottom will commoditize these things, making vulnerabilities without them ignored, and confusing vulnerabilities with them as severe.

The final result is that it's just extra, meaningless noise tacked on to vulnerability disclosure that makes it more difficult to achieve, involves more parties and doesn't improve anything.

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

#155

Post by correxion » Tue, Jan 27, 2015, 9:10 PM UTC

WestCoastJustin wrote: post #14

When the patches are available, you need to update, and likely reboot. Mattias Geniar talks about using the following command to find processes depending on libc, any of which could be running the vulnerable code, these are core processes that you probably cannot just cycle without a reboot [1]. For me the listing looks something like this: agetty, auditd, dbus-daem, dhclient, init, master, mysqld, rsyslogd, sshd, ud…

lsof | awk '/libc/{print $1 | "sort -u" }' you're welcome

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

#156

Post by AnthonyMouse » Tue, Jan 27, 2015, 9:15 PM UTC

derf_ wrote: post #117

jap wrote: post #60

Looks like that function is marked as obsolete, anyone know how long that's been the case? https://www.mankier.com/3/gethostbyname "The gethostbyname (), gethostbyaddr (), herror(), and hstrerror() functions are obsolete. Applications should use getaddrinfo(3), getnameinfo(3), and gai_strerror(3) instead."

Well, Ulrich Drepper has been trying to get people to stop using it since 2007: https://udrepper.livejournal.com/16116.html And not just because of IPv6.

That seems like a weak argument. It's still going to do the wrong thing when the local machine has a 10.x.x.x address and the local server has a 172.16.x.x address. The right solution is for the local admin to have the local DNS server return only the local address for local clients.

getaddrinfo() is also a much more complicated function than gethostbyname(). If you need the extra features, fine. If you're writing new code, fine. But going back and trying to update existing code is just going to introduce new bugs.

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

#157

Post by MichaelGG » Tue, Jan 27, 2015, 9:17 PM UTC

indymike wrote: post #141

MichaelGG wrote: post #128

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. FFS in this case they even found the bug and fixed it, but didn't notice how it could be a vulnerability. So even with eyes directly on issues, we (human programmers excluding djb) can't seem to get it right.

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.)

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

#158

Post by correxion » Tue, Jan 27, 2015, 9:17 PM UTC

peterwwillis wrote: post #27

WestCoastJustin wrote: post #14

When the patches are available, you need to update, and likely reboot. Mattias Geniar talks about using the following command to find processes depending on libc, any of which could be running the vulnerable code, these are core processes that you probably cannot just cycle without a reboot [1]. For me the listing looks something like this: agetty, auditd, dbus-daem, dhclient, init, master, mysqld, rsyslogd, sshd, ud…

They're only attacking host-lookup, so you just have to worry about people who can connect to your service and are able to control name server response. This means your network services that are internet-accessible. Everything else can wait for a maintenance window for the reboot. ~# netstat -lnp | grep -e "$tcp.*LISTEN\|udp$" | cut -d / -f 2- | sort -u cupsd dnsmasq httpd nmbd ntpd qemu-kvm rpc.portmap rpc.statd s…

sudo netstat -lnp | awk -F/ '/LISTEN /{print $2}'

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

#159

Post by fragmede » Tue, Jan 27, 2015, 9:20 PM UTC

Animats wrote: post #150

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…

Turns out, open source code is written by humans, same as at Microsoft. I remember, back in the day, it was absolutely pathetic that Microsoft Outlook had a buffer overflow in the subject line that could be tripped simply by receiving an email. Well, oops.

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

#160

Post by MichaelGG » Tue, Jan 27, 2015, 9:23 PM UTC

AnthonyMouse wrote: post #148

MichaelGG wrote: post #128

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. FFS in this case they even found the bug and fixed it, but didn't notice how it could be a vulnerability. So even with eyes directly on issues, we (human programmers excluding djb) can't seem to get it right.

> 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 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. Even despite all the crazy codegen and memory janking b modern compilers and OSes do, even with some hardware support, it's still happening.