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

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

#221

Post by cft » Wed, Jan 28, 2015, 4:17 AM UTC

beagle3 wrote: post #220

cft wrote: post #211

Earlier quoted context omitted.

Even if it used gethostbyname() , I fail to understand how one would supply an invalid IP address to an sshd program? It calls an IP resolver after the TCP connection has been established, reading off the IP from there. From what I understood from their exim HELO example, one has to feed in a crazy IP "address" to gethostbyname() to trigger the bug.

Well, it obviously does getaddrinfo() on the incoming TCP connection to get the hostname (which is reported in the log, unless you have a 'UseDNS no' directive) -- and at least in my setup (which is mostly vanilla Debian), it seems to resolve that name again to an IP address, compare that to the IP address of the connection, and warn if it does not match. Thus, an attacker controlling the PTR record for a given IP mi…

But why would this malicious PTR record be fed into gethostbyname() again? At that point of getting a reverse lookup result, sshd is done checking.

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

#222

Post by jerematasno » Wed, Jan 28, 2015, 4:30 AM UTC

We wrote a quick blog post on this. The main meaningful feature is a table of distros, versions, and whether they're not vulnerable, vulnerable but with a patch, or vulnerable with no patch yet. I am accepting requests for other distros, and of course if you have any corrections I'd love to hear them!

http://chargen.matasano.com/chargen/2015/1/27/vulnerability-...

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

#223

Post by cbsmith » Wed, Jan 28, 2015, 4:40 AM UTC

userbinator wrote: post #76

tedunangst wrote: post #32

Earlier quoted context omitted.

From the GNU coding standards: > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically.

http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_... the entire hostname (including the delimiting dots but not a trailing dot) has a maximum of 253 ASCII characters In general that is a good guideline, but when the standard (RFC1035) says there is an absolute limit, there is little value in going above that as it is likely that other systems won't be able to handle it. The added complexity of dynamic allo…

In this case the bug isn't caused by dynamic allocation though, is it? The problem is the validation logic for detecting if the caller didn't allocate a big enough buffer when making the call.

In fact, it looks like if you get to the dynamic allocation section, it will fix the problem. One could argue that the whole problem stems from having a bug in a complex computation of buffer size to handle lots of different bits of data, rather than dynamically allocating the individual bits as needed.

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

#224

Post by __david__ » Wed, Jan 28, 2015, 4:42 AM UTC

csmeu wrote: post #103

Karunamon wrote: post #100

Earlier quoted context omitted.

"Professionalism" is overrated. And this appears to be a "drop everything and fix it" bug, so the "damn sensationalism" is warranted. If clients calling you about a vulnerability bothers you, get out of this line of work, please. People actually giving a shit about security holes is something we've been wanting for a long time. It beats the hell out of the alternative, something we've been dealing with since the 90s…

Professionalism is thinking and understanding before you start firing a gun at your infrastructure, testing stuff and not shooting client SLAs. We do that bit between the CVE being announced and patching ahit, not when the press goes ape shit. So, that's overrated is it?

Yes. When there's an exploit available now, you really don't have that luxury.

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

#225

Post by beagle3 » Wed, Jan 28, 2015, 4:50 AM UTC

cft wrote: post #221

beagle3 wrote: post #220

Earlier quoted context omitted.

Well, it obviously does getaddrinfo() on the incoming TCP connection to get the hostname (which is reported in the log, unless you have a 'UseDNS no' directive) -- and at least in my setup (which is mostly vanilla Debian), it seems to resolve that name again to an IP address, compare that to the IP address of the connection, and warn if it does not match. Thus, an attacker controlling the PTR record for a given IP mi…

But why would this malicious PTR record be fed into gethostbyname() again? At that point of getting a reverse lookup result, sshd is done checking.

To see that it resolves back to the IP address from which the connection is made. It's a standard check that many servers do, and ssh does too (and gives off a warning if they don't match). I'm not sure if it does it in a way that's vulnerable or not, though - but it surely does so by default.

From man sshd_config:

     UseDNS  Specifies whether sshd(8) should look up the
     remote host name and check that the resolved host name
     for the remote IP address maps back to the very same 
     IP address.  The default is “yes”.

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

#226

Post by beagle3 » Wed, Jan 28, 2015, 4:51 AM UTC

beagle3 wrote: post #209

contingencies wrote: post #18

Earlier quoted context omitted.

For immediate actions, maybe also set 'UseDNS no' in /etc/ssh/sshd_config and restart any public-facing ssh servers.

This is a good idea in general. However, every version of ssh that I could test (going back to Ubuntu 8.04) uses getaddrinfo() rather than gethostbyname() and is therefore safe.

... or not necessarily safe, as people here claim that getaddrinfo() uses gethostbyname() under the covers.

"UseDNS no" in your sshd_config is a good idea in general.

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

#227

Post by Animats » Wed, Jan 28, 2015, 5:02 AM UTC

est wrote: post #200

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…

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

Then they did .NET and converted everybody to C#.

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

#228

Post by peteretep » Wed, Jan 28, 2015, 6:06 AM UTC

Natsu wrote: post #165

fragmede wrote: post #153

Earlier quoted context omitted.

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?

You're piping random executables from the internet without even looking at them to see what they do if you run that command.

    > You're piping random executables from the internet
    > without even looking at them to see what they do if you
    > run that command

... and then in your profile:

    > Just another Perl hacker.

You audit every CPAN module you install, line by line, right?

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

#229

Post by Karellen » Wed, Jan 28, 2015, 6:36 AM UTC

lazaroclapp wrote: post #170

mackal wrote: post #161

Earlier quoted context omitted.

I hate these "just use another language! All problems solved" kind of posts. Mainly because it's shit logic.

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…

The things is, it's not necessarily true in this case.

While C was intended to run as close to bare metal as possible, and 99% of current implementations do, that doesn't have to be the case. The C specification describes an abstract machine, and uses abstract concepts, with explicit "as-if" rules saying that implementations may, in many cases, do whatever they want, providing that conforming code runs as if it would on a naive implementation.

So there's no reason at all that, for example, pointers have to be implemented as actual bare addresses in a virtual address space which cannot be bounds checked. It should be perfectly possible to create a new implementation, with a new ABI, which defines pointers as a checked type such that all accesses through a pointer are accurately bounds checked, with a guaranteed "virtual" segfault happening whenever an invalid read or write would have occurred.

Sure, it's not ABI-compatible (by defualt) with current bare-metal C ABIs, and would require shims to work with bare-metal C libraries - but that's no different than Rust and similar other new languages. Sure, it's not quite as fast as bare-metal C implementations due to enforced bounds checking, but it's not going to be slower than Rust and similar which do the same job.

And the advantage would be, we wouldn't need to rewrite all our code. We could just recompile all the existing C code we already have to this new safe ABI, rather than having to rewrite everything from scratch in some new language!

Sure, C isn't the nicest language to use. But we already have plenty of existing code that uses it. Why don't we just write a new compiler back-end and take advantage of all that code in a safe manner?

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

#230

Post by cm2187 » Wed, Jan 28, 2015, 7:40 AM 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…

Garbage collection has a performance hit which may not be desirable. You don't really want your network stack to stall from time to time. And OS wouldn't be usable in any mission critical environment.

Array boundaries checking also has a performance hit but I am coming to think it is a necessary evil.

Dealing with strings as char arrays is just absurd. There isn't a significant performance hit to use some string datatype that reduce the opportunity for bugs.