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

1–10 of 254 posts

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

#2

Post by martius »

From https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235

"A heap-based buffer overflow was found in __nss_hostname_digits_dots(), which is used by the gethostbyname() and gethostbyname2() glibc function call. A remote attacker could use this flaw to execute arbitary code with the permissions of the user running the application."

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

#6

Post by Karunamon »

csmeu wrote: post #4

I'm glad the moderator removed GHOST from the subject line. CVEs don't need a media friendly handle. Edit: Its back again. Booooo.

We disagree on that, especially when they're widespread (and you don't get much more widespread than glibc) and "drop everything and patch"-level severity.

Having a shorthand to refer to the bug makes it more easy (and therefore more likely) that it will get referenced and discussed.

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

#7

Post by mrb »

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/lists/oss-security/2015/01/27/9 - thanks amlweems! (https://news.ycombinator.com/item?id=8954069)

It looks like when an application calls a function of the gethostbyname()/gethostbyname_r() family but passes a buffer and a buffer length that is too short to store the result, then the function sometimes fails to detect there is not enough space due to a miscalculation of how much space it needs, leading to a heap overflow. This means potentially arbitrary code execution! Edit: Both the reentrant version (gethostbyname_r) and non-reentrant one (gethostbyname) are affected (the non-reentrant one uses a fixed buffer length). 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. And this affects everything, no matter what language the server application is written in: C, Python, PHP, Java...

Edit #2: it looks like the bug was patched 2 years ago, but the fact it was exploitable was not understood until today, hence why a CVE was only assigned now.

Edit #3: Apps written in Golang are not vulnerable: https://news.ycombinator.com/item?id=8954011 - thanks 4ad!

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

#8

Post by unwind »

martius wrote: post #2

From https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0235 "A heap-based buffer overflow was found in __nss_hostname_digits_dots(), which is used by the gethostbyname() and gethostbyname2() glibc function call. A remote attacker could use this flaw to execute arbitary code with the permissions of the user running the application."

Obligatory git link for the curious: https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/digits_....

Note that this is a HEAD link, so if there are changes after I post this they should appear. I don't claim to have spotted the suspicious code (it's not ... super-accessible), just wanted to provide a link to the file in question.

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

#9

Post by yxhuvud »

Karunamon wrote: post #5

Details on this one appear to be quite sparse - under what use cases would a remote user be able to craft invalid IP addresses?

It seems it was made public by accident, so it is not totally surprising that information is sparse :(
Post reply on HN