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

141–150 of 254 posts

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

#141

Post by indymike »

MichaelGG wrote: post #128
userbinator wrote: post #45

Glancing over the patch, this appears to be the crucial part: size_needed = (sizeof (*host_addr) - + sizeof (*h_addr_ptrs) + strlen (name) + 1); + + sizeof (*h_addr_ptrs) + + sizeof (*h_alias_ptr) + strlen (name) + 1); Doesn't it seem disappointing that some programmers, for whatever reason, just can't seem to count correctly?

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.

Reason why people defend unsafe languages:

If you make it idiot-proof, someone will make a better idiot.

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

#143

Post by Ded7xSEoPKYNsDd »

AgentME wrote: post #134
peterwwillis wrote: post #72

Earlier quoted context omitted.

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.

Uh, how often do code execution vulnerabilities show up in non-C programs compared to how often they show up in C programs?

All the time: SQLi, XSS, arbitrary file upload, ...

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

#144

Post by fletchowns »

windsurfer wrote: post #138
DangerousPie wrote: post #77

Here is the test program, from http://www.openwall.com/lists/oss-security/2015/01/27/9 https://gist.github.com/koelling/ef9b2b9d0be6d6dbab63 To test your system, simply run this (but obviously only after making sure gistfile1.c is clean ;)) wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c gcc gistfile1.c -o CVE-2015-0235 ./CVE-2015-0235

I always laugh when people give you a URL to C code to test for remote code execution...

Might as well throw a --no-check-certificate in there

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

#145

Post by toddsiegel »

windsurfer wrote: post #138
DangerousPie wrote: post #77

Here is the test program, from http://www.openwall.com/lists/oss-security/2015/01/27/9 https://gist.github.com/koelling/ef9b2b9d0be6d6dbab63 To test your system, simply run this (but obviously only after making sure gistfile1.c is clean ;)) wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c gcc gistfile1.c -o CVE-2015-0235 ./CVE-2015-0235

I always laugh when people give you a URL to C code to test for remote code execution...

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.

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

#146

Post by hackersword »

[deleted] wrote: post #133
McGlockenshire wrote: post #126

Earlier quoted context omitted.

Does anyone have any insight into when we'll see CentOS packages start hitting the mirrors?

[deleted]

This is for https://rhn.redhat.com/errata/RHSA-2015-0016.html

This was related to iconv() and UTF8.

This is NOT the fix for this CVE.

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

#147

Post by Thaxll »

McGlockenshire wrote: post #126
gtrubetskoy wrote: post #107

RedHat has a fix for 6 and 7 now: https://rhn.redhat.com/errata/RHSA-2015-0092.html

Does anyone have any insight into when we'll see CentOS packages start hitting the mirrors?

It should be there once it's done: http://mirror.centos.org/centos/6.6/updates/x86_64/Packages/

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

#148

Post by AnthonyMouse »

MichaelGG wrote: post #128
userbinator wrote: post #45

Glancing over the patch, this appears to be the crucial part: size_needed = (sizeof (*host_addr) - + sizeof (*h_addr_ptrs) + strlen (name) + 1); + + sizeof (*h_addr_ptrs) + + sizeof (*h_alias_ptr) + strlen (name) + 1); Doesn't it seem disappointing that some programmers, for whatever reason, just can't seem to count correctly?

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.

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

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

#149

Post by tedunangst »

Ded7xSEoPKYNsDd wrote: post #143
AgentME wrote: post #134

Earlier quoted context omitted.

Uh, how often do code execution vulnerabilities show up in non-C programs compared to how often they show up in C programs?

All the time: SQLi, XSS, arbitrary file upload, ...

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.

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

#150

Post by Animats »

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 GC, Rust is almost there. (As I say occasionally, I really hope the Rust guys don't screw up.) C and C++ should not be used for new work.

It has been 1 days since the last buffer overflow vulnerability report.

Post reply on HN