All those home routers. All those home routers running Linux. All those home routers that are difficult to upgrade. All those home routers that will soon be part of some botnet or other?
[deleted]
CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
101–110 of 254 posts
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#102Earlier quoted context omitted.
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.
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. From http://www.openwall.com/lists/oss-security/2015/01/27/9 : --[ 3 - Mitigating factors ]-------------------------------------------------- The impact of this bug is reduced significantly…
>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() :-)
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#103Earlier quoted context omitted.
I wasn't being sarcastic. 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 marketo…
"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?
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#104Earlier quoted context omitted.
I wasn't being sarcastic. 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 marketo…
"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…
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?
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#105All those home routers. All those home routers running Linux. All those home routers that are difficult to upgrade. All those home routers that will soon be part of some botnet or other?
Those (Linux-based) home routers usually use uclibc, which is not glibc. Similarly, they usually use busybox ash as a shell and thus weren't vulnerable to shellshock. Some do use openssl, so might still be affected by heartbleed.
But it is still C code, so...
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#106Earlier 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…
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?
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#107RedHat has a fix for 6 and 7 now: https://rhn.redhat.com/errata/RHSA-2015-0092.html
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#108Earlier quoted context omitted.
You can check to see if any running process are using any stale libraries pretty easily: sudo lsof | grep lib | grep DEL You can then either reload those processes manually, or just bounce the box if that's easier.
There's also a rare chance that a program is statically linked, in which case upgrading glibc won't help, the program would need to be recompiled.
It is nearly impossible to statically link glibc.
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#109Dumb 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.
You can check your libc version by running libc - e.g. `/lib/x86_64-linux-gnu/libc.so.6`
Re: CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow
#110Qualys Security Advisory: http://www.openwall.com/lists/oss-security/2015/01/27/9 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
That's a great writeup. It will be really interesting to see how they achieve remote code execution under those limitations. Also surprising to note that we've been vulnerable since November 2000.
They give it away (which I find moderately not nice of them) by saying they used Exim (the mail server) in their POC.