Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

openwall.com

Post reply on HN
Print view View original

211–220 of 254 posts

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

#211

Post by cft »

beagle3 wrote: post #210

As far as I can tell, sshd has always used getaddrinfo() which is not vulnerable (rather than gethostbyname() which is). Can anyone confirm? According to this comment: https://news.ycombinator.com/item?id=8954458 , getaddrinfo() uses gethostbyname() internally. So, is a default 'UseDNS yes' ssh setup vulnerable or not?

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.

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

#212

Post by kibwen »

AnthonyMouse wrote: post #191
MichaelGG wrote: post #182

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…

  > 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.
Then you'll love Rust, where the compiler is essentially one ultra-comprehensive static analyzer. :)

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

#213

Post by pcwalton »

tragomaskhalos wrote: post #167
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…

I wish people would stop tarring C++ with the same brush - this vulnerability is caused by exactly the sort of manual dicking around with memory and buffer sizes that are trivial to avoid and completely unidiomatic in C++ but de rigeur in C. Is it possible to create these sorts of bugs in C++? Of course it is, but that's a far cry from an environment that actively leads you down a dangerous path because it lacks the…

C++ lacks the necessary higher-level abstractions to write memory-safe code. It is vulnerable to iterator invalidation, use-after-free, dangling references, and so forth. RAII does not provide the necessary guarantees.

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

#214

Post by kyllo »

bch wrote: post #174
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…

> What we do know now is that the open source process does not converge to a no-bugs state. 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 w…

Nobody to be taken serious has ever thought or said this

Linus Torvalds is nobody to be taken seriously?

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

#215

Post by caf »

mrb wrote: post #7

This is the original report: https://sourceware.org/bugzilla/show_bug.cgi?id=15014 Upstream patch: https://sourceware.org/git/?p=glibc.git;a=commit;h=d5dd6189d... Full diff: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5dd6... Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 Debian bug: https://bugs.debian.org/776391 Great write-up from the discoverer (Qualys): http://www.openwall.com…

The scope of this vulnerability is huge! A lot of server applications attempt to resolve or reverse-resolve network clients's hostnames or IP addresses when a connection is established, so they would all be potentially vulnerable: the malicious client controlling his DNS records simply needs to return specially crafted hostname or address data that is too big to fit in the buffer.

This overstates things a bit - hostnames that can be returned by the reverse DNS resolver can't trigger the vulnerability (maximum label length of 63). It needs to be a hostname supplied by a non-DNS method (eg. the POC uses the HELO SMTP command).

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

#216

Post by caf »

danielweber wrote: post #80
verelo wrote: post #51

Dumb question perhaps, but is there a command line command I can run to test before and after that this patch has been applied successfully?

The Qualys link (elsewhere on this page) contains sample code to test if you are vulnerable. Also, you can check your glibc version with this tiny code: #include #include int main (void) { puts (gnu_get_libc_version ()); return 0; } (taken from a forum that I've since closed the page on, sorry for lack of attribution) = 2.18 is safe. ldd --version might also do the trick.

Checking the libc version doesn't really tell you if you've fixed the problem, since most vulnerable distributions will be fixing it by patching their older version of libc, so the version number will remain the same.

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

#217

Post by [deleted] »

danielweber wrote: post #80
verelo wrote: post #51

Dumb question perhaps, but is there a command line command I can run to test before and after that this patch has been applied successfully?

The Qualys link (elsewhere on this page) contains sample code to test if you are vulnerable. Also, you can check your glibc version with this tiny code: #include #include int main (void) { puts (gnu_get_libc_version ()); return 0; } (taken from a forum that I've since closed the page on, sorry for lack of attribution) = 2.18 is safe. ldd --version might also do the trick.

[deleted]

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

#218

Post by stormbrew »

kyllo wrote: post #214
bch wrote: post #174

Earlier quoted context omitted.

> What we do know now is that the open source process does not converge to a no-bugs state. 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 w…

Nobody to be taken serious has ever thought or said this Linus Torvalds is nobody to be taken seriously?

I don't think Linus ever said it. I'm not sure he even agrees with it. Eric S. Raymond named it after him because of Linux.

That said, Eric S. Raymond didn't say the quoted either. He said that "given enough eyeballs, all bugs are shallow", which is a much less bold claim (imo, at least) than that open source converges towards zero bugs over time.

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

#219

Post by NickNameNick »

jerematasno wrote: post #202
peterwwillis wrote: post #27

Earlier quoted context omitted.

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…

It doesn't have to be internet accessible, AFAIK. If an attacker can get something to do arbitrary DNS lookups, I think it can be attacked. For instance, monitoring/log correlation software might be vulnerable.

If you have backend systems parsing XML, then an XXE[1] attack could trigger a DNS lookup, for example.

[1]https://www.owasp.org/index.php/XML_External_Entity_%28XXE%2...

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

#220

Post by beagle3 »

cft wrote: post #211
beagle3 wrote: post #210

As far as I can tell, sshd has always used getaddrinfo() which is not vulnerable (rather than gethostbyname() which is). Can anyone confirm? According to this comment: https://news.ycombinator.com/item?id=8954458 , getaddrinfo() uses gethostbyname() internally. So, is a default 'UseDNS yes' ssh setup vulnerable or not?

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 might provide a GHOST-compliant name in that PTR record; Then, connect to the ssh daemon, wait for it to read the PTR record - and if it gethostbyname() on it, it's game over.

Quite a few log processors would do that. The reason I'm worried specifically about sshd is that it is usually the only port ever listening to the world-and-not-firewalled on my servers (and a non-standard, at that - and only allowing public key authentication) - but despite this generally-regarded-as-secure setting, GHOST may prove it vulnerable.

Post reply on HN