"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."
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.
I'm not fully though my morning bootup process and so not really ready to grok this but, can anyone give a quick summary of why gethostbyname() needs to hit the heap at all, let alone with a realloc call? There's a maximum hostname length, and it's not huge. Also: isn't this function just saying "yes" or "no" to a candidate hostname? Can't it just say "no" if the hostname is super long?
> 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.
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 allocation is also an opportunity for bugs, like this one.
Again, this is especially silly if (as it appears to first glance) the bug is in a hostname validation function, and so flexible allocation could only ever be useful in the case of a hostname that must fail validation anyways.
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.
Right, but they only need to do that computation because they're dynamically allocating storage. But the maximum size of a hostname is so small that hitting the allocator is costing them more than static allocation would.
gethostbyname() and friends fill in struct hostent:
struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses */
}
The pointers in the structure point into the buffer. There could be any number of host aliases or IP addresses.
That's true and a good point, but not (it seems) applicable to this particular function, which validates whether or not the name is one of two fixed-sized formats, right?
It looks like what's going on is that gethostbyname() calls __nss_hostname_digits_dots() which checks to see if the string you passed it was an IPv4 or IPv6 address rather than a name, and in that case it functions like inet_aton/inet_pton and converts the IP address string to a binary IP address as though the "name" 1.2.3.4 resolved to IP address 1.2.3.4.
In that specific case there are no aliases and exactly one IP address, but the buffer could still be too small (e.g. if caller-supplied with gethostbyname_r()).
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.
Adding a tagline, media friendly name or keywords is unprofessional. Simply, severity is then ranked by how popular the press or security bloggers can market the word, not by the respective severity of the CVE. Its a popularity contest, nothing more.
As someone who deals with every damn sensationalist story at a financial company, having every fucking client phone up about every damn marketoid creation even if it doesn't affect our platform detracts from doing real work.
"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 or so!
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.
Having a shorthand makes it a lot easier for people to freak out and panic unnecessarily, too. "Heartbleed" was big enough to warrant a world-wide freakout, but this is a remote buffer overflow with many requirements for success.
--[ 3 - Mitigating factors ]--------------------------------------------------
The impact of this bug is reduced significantly by the following reasons:
- A patch already exists (since May 21, 2013), and has been applied and
tested since glibc-2.18, released on August 12, 2013:
- The gethostbyname*() functions are obsolete; with the advent of IPv6,
recent applications use getaddrinfo() instead.
- Many programs, especially SUID binaries reachable locally, use
gethostbyname() if, and only if, a preliminary call to inet_aton()
fails. However, a subsequent call must also succeed (the "inet-aton"
requirement) in order to reach the overflow: this is impossible, and
such programs are therefore safe.
- Most of the other programs, especially servers reachable remotely, use
gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also
known as full-circle reverse DNS) checks. These programs are generally
safe, because the hostname passed to gethostbyname() has normally been
pre-validated by DNS software:
. "a string of labels each containing up to 63 8-bit octets, separated
by dots, and with a maximum total of 255 octets." This makes it
impossible to satisfy the "1-KB" requirement.
. Actually, glibc's DNS resolver can produce hostnames of up to
(almost) 1025 characters (in case of bit-string labels, and special
or non-printable characters). But this introduces backslashes ('\\')
and makes it impossible to satisfy the "digits-and-dots"
requirement.
You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit.
>You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit
would you? If you want to exploit something that does unauthenticated gethostbyaddr(), then yes, for that you need to control a DNS server (which, btw, isn't harder than controlling a web server to serve malware with).
On the other hand, if you can make your target call gethostbyname() on an arbitrary string, you don't need to control a DNS server.
There are many sites out there that go and fetch user supplied URLs - for example to fetch picture previews.
First you exploit one of these, install a DNS server on them and then you can also exploit the ones which only do gethostbyaddr() :-)
Web servers serving malware are exploited in drive-by scanning; find a vuln in a webapp, drop your malware. It doesn't even take exploiting the system itself, and generally does not affect the web server at all. Taking over a DNS server would take much more work to pwn first, and then require reconfiguring the DNS server. Much more difficult.
Fetching a user-supplied URL is not enough to exploit remotely. You have to exploit the target's DNS resolver, because you have to feed it invalid or impossible records. All existing DNS resolvers will reject these because they break RFC.
It would be much easier to exploit a web app and drop your payload and exploit it locally, which is what everyone currently does to pwn servers with rootkits.
I think it's okay to assign a media name to vulnerabilities, but only if the vulnerability is truly severe enough (easy to exploit and serious magnitude) to warrant it. Otherwise it's just an attempt at marketing and PR.
In this case, it looks the name is probably not warranted.
I'm curious on this one too. How exactly can this be exploited remotely? SSH trickery? If a PHP script is doing geolookups or resolving of user's IP's to hosts?
I'm guessing vulnerable cases will be where string-encoded IP addresses are accepted from the network and passed directly to these functions, such as by web apps or things that take string-serialized encodings. This would allow an attacker to pass any string in as an IP address.
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.
A note about Go. Go has its own DNS resolver, but unfortunately, if you compile natively, it's not enabled by default. It's only enabled if you cross-compile, or if you disable cgo, or if you rebuild the standard library with -tags netgo.
/edit: a second note about Go; even without the native resolver, Go uses getaddrinfo, not gethostbyname*, and it's not vulnerable.
So.... an application acts differently if it is cross-compiled? And if there's a vuln in the go resolver, binaries are "maybe" vulnerable, depending on whether they were cross-compiled or not?
I'm not sure why you were downvoted. In an ideal world, the behavior of the native Go resolver and the host resolver should be the same, but in the real world they might behave differently and might have different bugs. The nice thing about the native Go resolver is that it's written in a memory safe language which prohibits bugs like these.
For my Debian 7 servers it reports "Version: 2.13-38+deb7u7" after upgrading. Everything below that (eg. "*u6") is vulnerable. I don't know about the specific version numbers in Ubuntu though.
Edit: the fixed Ubuntu version is "2.15-0ubuntu10.10"
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).
Is this serious? Does this mean if I have an app, Java, PHP or whatever, which eventually calls glibc's gethostbyname gethostbyaddr, my machine is owned? That somebody could just craft a special hostname or ip address to lookup? So all those websites where you enter hostname o IP address to lookup something like whois info or ping other machines, could be owned?
If it affects gethostbyaddr that'd be really bad - there are a lot of applications that automatically look up reverse DNS on a connection.
Mail servers in particular generally make it pretty easy to trigger both forward and reverse lookups.
The test case seems to have it looking up an ip address as if it were a name, but it's using the reentrant version of the function - maybe only those are affected?
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, udevd, xinetd. Many of these deal with hostnames, so I would want to be sure everything is clean, and the best option is likely a reboot.
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.
Thank you, it's not always clear when a reboot is needed after an update. I do it with kernel updates but wouldn't have in this case until I read your comment and ran the command to check.
If would be nice if package managers would let us know when this is necessary, I expect that might be a hard thing to get right though.
You're testing what happens when you delete a file for which an open file descriptor exists. On Linux, a shared library will normally be memory-mapped but will not have a corresponding file descriptor. So lsof will show DEL, not (deleted).
I wouldn't normally nitpick about something like this, but if people follow your advice they might incorrectly think they don't need to reboot.
Yeah, that's a good point, and definitely worth mentioning, but obviously rebooting isn't going to help in that case either. The parent was asking about how they would know if they need to reboot or not.
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.
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.
Just remember that by default lsof prints only first 9 characters of process name, so processes with long names will be cut. You can change how much initial characters lsof prints with +c command, but often kernel does not supply full names for lsof, example limit in my box is 15 characters
That limit is set somewhere in the kernel but it's not clear if lsof is just setting that as a maximum internally or probing somewhere - I used strace -etrace='!close' lsof +c 64 but I couldn't see anything related to the limit.
Yes, it was fixed upstream in glibc, but that doesn't mean the distros actually get the patch into their distribution. In fact, the report states: "Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example."
Lots of info about their discovery. Apparently they developed a PoC exploit. They've also included a pretty short test program to determine if a system is vulnerable or not.
- At most sizeof(char *) bytes can be overwritten (ie, 4 bytes on 32-bit
machines, and 8 bytes on 64-bit machines). Bytes can be overwritten
only with digits ('0'...'9'), dots ('.'), and a terminating null
character ('\0').
- Despite these limitations, arbitrary code execution can be achieved.
As a proof of concept, we developed a full-fledged remote exploit
against the Exim mail server, bypassing all existing protections
(ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will
publish our exploit as a Metasploit module in the near future.
Wow, that's actually amazing! I never would have thought it possible. As tonyhb says, it will be really interesting 'in the near future' to see how they managed to do it.
From this, the vulnerability was fixed in May 2013 so any systems from there or later (e.g. Ubuntu 14.04) are fine. Older systems obviously now need to wait for the patches to come through.
It's a shame they put that "..." there, because this looked like another potential vulnerability to me, or at least something I would take very critically reading this code. (realloc fails, the caller's variable at buffer_size still gets assigned a larger value, next call thinks it has a larger buffer than it does). Line 110 assigns *buffer_size back to 0 so there is no such problem.
Unless I've misread the patch, the problem isn't that they counted the sizeof the wrong thing, it's that they forgot one of the things entirely. sizeof() the same thing twice would have been explained by similar names.
It is nice if they can count. However instead of sending them back to kindergarten, it might make sense to find a compiler/language/framework that would make inability to count not result in easy remote exploits.
So remove the ability to use pointers to directly access memory. Then you're only left with all of the other security vulnerabilities found in every such language.
The fun part is that when you find a language/framework that (e.g.) deserializes data by running eval(), it's so much easier to write portable exploits. 32 bit, 64 bit, x86, arm, mips, aslr? None of that matters. Literally eval(system("/bin/sh")) and done.
XSS is a totally different level. When's the last time a bunch of networked devices needed patches because of XSS?
And even if these problems were as widespread, eliminating a huge class of errors is a big step up. Nearly every serious vulnerability in Microsoft's code for the past years is from memory unsafeness.
Hell, why bother with malaria or smallpox vaccines, since people just die from something else anyways.
The answer to your question is "all the time", because most new appliances are using more high level languages and xss-prone interfaces. This also ignores all the ones that don't get found/fixed.
Of course we should work to eliminate problems, but you have to consider the bigger picture and whether abandoning the language is worth it. So far the pros outweigh the few unique cons.
Without trolling, it is true that string manipulation has been a fertile source of major bugs. I don't really see the benefit of having to manipulate arrays of characters manually instead of a string datatype. An unmanaged language doesn't really gain anything from this, apart from this sort of embarrassment.
I have no idea if it would apply here, but many instances where a field is forgotten in a size calculation happen because the field wasn't originally there, and not all of the relevant code got updated when it was added. Beware any code that requires knowledge of all elements of some set, and still compiles if a new element is added and the code isn't updated for it.
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.
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.)
> 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 code execution. Ghost is very hard to exploit, which is why people didn't notice how it could be. It's like trying to exploit an off by one error.
Bugs in production code are not "safe" regardless of what language you use. What we need are better ways to find bugs before the code is put into production.
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.
> 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 from compiling.
If you get a large buffer and then "allocate" it by returning pointers to pieces of it (or offsets if you don't have pointers), now the compiler/runtime only knows where the end of the buffer is, not where the end of the allocation is supposed to be. You can write dumb code in any language.
> 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.
The problem with this reasoning is that it's solving the problem in the wrong place. Yes, if you screw up very badly then it's better for the language to blow up the program than let the attacker control it. But you still have to solve the other problem, which is that the attacker can blow up the program or possibly do other things even with "safe" languages because the program is parsing unvalidated input etc. And solving that problem, which needs to happen regardless, causes the first problem to go away.
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 other languages. Yet in C, this keeps happening.
> 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.
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.
> 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. :)
From what I can gather, it wasn't originally thought to be a security vulnerability so it was thought to be acceptable to leave it be on older systems. Now somebody has figured out how to exploit it.
Sweeping-under-rug is a common approach. It seems that in this instance, they have followed Linus Torvalds mantra, who once said: "I don't have any reason what-so-ever to think it's a good idea to track security bugs and announce them as something special. I don't think some spectacular security hole should be glorified or cared about as being any more special than a random spectacular crash due to bad locking."
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.
"The gethostbyname(), gethostbyaddr(), herror(), and hstrerror() functions are obsolete. Applications should use getaddrinfo(3), getnameinfo(3), and gai_strerror(3) instead."
For a long time: getaddrinfo() and others are specified in susv3[1] (since 2003 I think). However, gethostbyname() and gethostbyaddr() are still very commonly used, and won't be gone soon.
The main reason gethostbyname is deprecated is that it doesn't support IPv6. The implementation of getaddrinfo uses gethostbyname, so you're using it either way.
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.
I agree, it is funny, but we run code we can't even see all day long. This is only 38 LOC. Anyone who is going to run it, however, should make sure they understand it.
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?
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.
The average Linux IT guy will not read the C code. Many of them wouldn't be able to really understand what it does either. And this is best case code is simple and easy to grok.
If you're not reading the code you can just as well curl-and-pipe it. However, we run so much code on our computers that is trusted-by-association (oh, that's from apache.org, that's probably safe!) that it probably does not matter anyways.
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.
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.
So what I figured out so far: This is a quite nasty bug that may or may not affect everything that links against glibc (or eglibc). However the bug was fixed in glibc 2.18 and the advisory [1] includes a test program at the start of section 4. From this Ubuntu 10.04 LTS and 12.04 LTS are affected, but not 14.04 LTS. ( Can someone confirm this?)
253 comments
[ 0.18 ms ] story [ 394 ms ] thread"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."
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.
> 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.
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 allocation is also an opportunity for bugs, like this one.
Again, this is especially silly if (as it appears to first glance) the bug is in a hostname validation function, and so flexible allocation could only ever be useful in the case of a hostname that must fail validation anyways.
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.
(edit) You may be totally right here, by the way.
In that specific case there are no aliases and exactly one IP address, but the buffer could still be too small (e.g. if caller-supplied with gethostbyname_r()).
Edit: Its back again. Booooo.
Having a shorthand to refer to the bug makes it more easy (and therefore more likely) that it will get referenced and discussed.
Between Heartbleed and Shellshock, and now this, a PR firm marketing vulnerabilities like this seems... crass.
Adding a tagline, media friendly name or keywords is unprofessional. Simply, severity is then ranked by how popular the press or security bloggers can market the word, not by the respective severity of the CVE. Its a popularity contest, nothing more.
As someone who deals with every damn sensationalist story at a financial company, having every fucking client phone up about every damn marketoid creation even if it doesn't affect our platform detracts from doing real work.
Let's play their trick:
Its the X Factor of security.
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 or so!
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?
Plus, 99% of the time, end users are not directly responsible for patching these issues. So why the focus on mass-media friendly marketing?
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.
From http://www.openwall.com/lists/oss-security/2015/01/27/9 :
You would effectively have to control the DNS server, or spoof its responses, to get the software to accept a suitable exploit.would you? If you want to exploit something that does unauthenticated gethostbyaddr(), then yes, for that you need to control a DNS server (which, btw, isn't harder than controlling a web server to serve malware with).
On the other hand, if you can make your target call gethostbyname() on an arbitrary string, you don't need to control a DNS server.
There are many sites out there that go and fetch user supplied URLs - for example to fetch picture previews.
First you exploit one of these, install a DNS server on them and then you can also exploit the ones which only do gethostbyaddr() :-)
Fetching a user-supplied URL is not enough to exploit remotely. You have to exploit the target's DNS resolver, because you have to feed it invalid or impossible records. All existing DNS resolvers will reject these because they break RFC.
It would be much easier to exploit a web app and drop your payload and exploit it locally, which is what everyone currently does to pwn servers with rootkits.
In this case, it looks the name is probably not warranted.
How do I make my hosts secure?
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!
/edit: a second note about Go; even without the native resolver, Go uses getaddrinfo, not gethostbyname*, and it's not vulnerable.
dpkg -s libc6
For my Debian 7 servers it reports "Version: 2.13-38+deb7u7" after upgrading. Everything below that (eg. "*u6") is vulnerable. I don't know about the specific version numbers in Ubuntu though.
Edit: the fixed Ubuntu version is "2.15-0ubuntu10.10"
Assuming the runtime links to glibc, which unfortunately most do.
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).
Mail servers in particular generally make it pretty easy to trigger both forward and reverse lookups.
The test case seems to have it looking up an ip address as if it were a name, but it's using the reentrant version of the function - maybe only those are affected?
The release at http://www.frsag.org/pipermail/frsag/2015-January/005722.htm... says that it affects both gethostbyname() and gethostbyaddr().
"UseDNS no" in your sshd_config is a good idea in general.
If would be nice if package managers would let us know when this is necessary, I expect that might be a hard thing to get right though.
sudo lsof | grep lib | grep DEL
You can then either reload those processes manually, or just bounce the box if that's easier.
I wouldn't normally nitpick about something like this, but if people follow your advice they might incorrectly think they don't need to reboot.
Maybe you have a cut-and-paste error? The before and after look the same to me, no "(deleted)" to be seen.
[1]https://www.owasp.org/index.php/XML_External_Entity_%28XXE%2...
>lsof +c 64
lsof: +c 64 > what system provides (15)
So
lsof +c 15 is maximum
https://rhn.redhat.com/errata/RHSA-2015-0090.html
http://www.openwall.com/lists/oss-security/2015/01/27/9
https://rhn.redhat.com/errata/RHSA-2015-0092.html
http://www.frsag.org/pipermail/frsag/2015-January/005727.htm...
http://www.frsag.org/pipermail/frsag/2015-January/005726.htm...
"I will keep you posted in next hours. I send the notice to early. Big fail of my own. Stay tuned."
http://www.frsag.org/pipermail/frsag/2015-January/005722.htm... From: Mar 27 Jan 15:28:45 CET 2015
Half an hour after Redhat lifted embargo from the ticket: https://bugzilla.redhat.com/show_activity.cgi?id=1183461 2015-01-27 10:03:14 EST Removed: EMBARGOED CVE-2015-0235
If this is true this lady gets an award for best security disclosure this year ;-)
Lots of info about their discovery. Apparently they developed a PoC exploit. They've also included a pretty short test program to determine if a system is vulnerable or not.
Here's a gist of the test (copied from their advisory): https://gist.github.com/amlweems/6e78d03810548b4867d6
Also surprising to note that we've been vulnerable since November 2000.
I checked the configs on two of my systems, one default, and one heavily customized, neither had the helo verification turned on.
http://www.openwall.com/lists/oss-security/2015/01/27/9
Also contains a writeup about a remote Exim exploit (which is the default mail server on at least Debian).
[1] I wouldn't.
[2] http://ftp.gnu.org/gnu/glibc/
>> 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.
I'm far more disappointed that so many programmers haven't adopted better systems, systems that avoid the possibility of this kind of error entirely.
And even if these problems were as widespread, eliminating a huge class of errors is a big step up. Nearly every serious vulnerability in Microsoft's code for the past years is from memory unsafeness.
Hell, why bother with malaria or smallpox vaccines, since people just die from something else anyways.
Of course we should work to eliminate problems, but you have to consider the bigger picture and whether abandoning the language is worth it. So far the pros outweigh the few unique cons.
Yet there seems to exist this belief in the C world, that they can.
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.
If you make it idiot-proof, someone will make a better idiot.
That's 12 just in one of the more popular Java web frameworks.
RCE is possible in any 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 code execution. Ghost is very hard to exploit, which is why people didn't notice how it could be. It's like trying to exploit an off by one error.
Bugs in production code are not "safe" regardless of what language you use. What we need are better ways to find bugs before the code is put into production.
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.
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 from compiling.
If you get a large buffer and then "allocate" it by returning pointers to pieces of it (or offsets if you don't have pointers), now the compiler/runtime only knows where the end of the buffer is, not where the end of the allocation is supposed to be. You can write dumb code in any language.
> 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.
The problem with this reasoning is that it's solving the problem in the wrong place. Yes, if you screw up very badly then it's better for the language to blow up the program than let the attacker control it. But you still have to solve the other problem, which is that the attacker can blow up the program or possibly do other things even with "safe" languages because the program is parsing unvalidated input etc. And solving that problem, which needs to happen regardless, causes the first problem to go away.
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.
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.
Also, you can check your glibc version with this tiny code:
(taken from a forum that I've since closed the page on, sorry for lack of attribution)<= 2.17 is unsafe, >= 2.18 is safe.
ldd --version might also do the trick.
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."
1/ http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB...
And not just because of IPv6.
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.
> In particular, we discovered that it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18)
Gentoo is listing glibc version 2.19-r1 as the latest stable version [2] and is using that per default.
[1] http://www.openwall.com/lists/oss-security/2015/01/27/9
[2] http://packages.gentoo.org/package/sys-libs/glibc
It's version 2.13-38+deb7u7
A standard update command should get it, but if not you can find it here:
http://security.debian.org/pool/updates/main/e/eglibc/
https://gist.github.com/koelling/ef9b2b9d0be6d6dbab63
To test your system, simply run this (but obviously only after making sure gistfile1.c is clean ;))
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?
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.
You can check your libc version with:
[1] http://www.openwall.com/lists/oss-security/2015/01/27/9