CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow • Hacker News Board

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

#161

Post by mackal » Tue, Jan 27, 2015, 9:27 PM UTC

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 hate these "just use another language! All problems solved" kind of posts. Mainly because it's shit logic.

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

#162

Post by rkangel » Tue, Jan 27, 2015, 9:28 PM UTC

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…

This bug was actually fixed 2 years ago, so I'm not sure this is the best example to make your point.

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

#163

Post by Natsu » Tue, Jan 27, 2015, 9:28 PM UTC

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…

> We now know that the line "with many eyes, all bugs are shallow" is just wrong.

How many eyes have actually looked at this code?

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

#164

Post by ndesaulniers » Tue, Jan 27, 2015, 9:29 PM UTC

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.

And with closed source, who knows?!

>C and C++ should not be used for new work.

It's funny how articles on C/C++ seem to shoot to the front page here...

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

#165

Post by Natsu » Tue, Jan 27, 2015, 9:31 PM UTC

fragmede wrote: post #153

windsurfer wrote: post #138

Earlier quoted context omitted.

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

Why? 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?

You're piping random executables from the internet without even looking at them to see what they do if you run that command.

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

#166

Post by MichaelGG » Tue, Jan 27, 2015, 9:31 PM UTC

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

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.

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

#167

Post by tragomaskhalos » Tue, Jan 27, 2015, 9:36 PM UTC

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 necessary higher level abstractions.

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

#168

Post by sandstrom » Tue, Jan 27, 2015, 9:37 PM UTC

atom_enger wrote: post #139

Here's a quick writeup I made with all of the information I found in this thread. Feedback welcome: http://product.reverb.com/2015/01/28/patching-cve-2015-0235-...

Good writeup, I liked the gists you picked out.

I've got some feedback though:

The bug has been fixed (May 21, 2013, between the releases of glibc-2.17 and glibc-2.18).

So your statement "This bug effects all versions of libc6 greater than 2.2+ (which was released Nov, 10, 2000) so you’ll be really lucky if you’re not vulnerable." is wrong.

For example, Ubuntu 14.04 uses glibc-2.19-1 which isn't affected.

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

#169

Post by Xylakant » Tue, Jan 27, 2015, 9:38 PM UTC

Natsu wrote: post #165

fragmede wrote: post #153

Earlier quoted context omitted.

Why? 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?

You're piping random executables from the internet without even looking at them to see what they do if you run that command.

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.

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

#170

Post by lazaroclapp » Tue, Jan 27, 2015, 9:39 PM UTC

mackal wrote: post #161

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 hate these "just use another language! All problems solved" kind of posts. Mainly because it's shit logic.

Except, "just use another language! All problems of this huge category solved!" is true in this case. You can't have buffer overflows on a memory-safe language. Sure, this is only true assuming the VM and all the stuff it depends on is formally verified not to have buffer overflows either, which is unlikely to happen. But even so, you get the slightly weaker guarantee: "just use another language! All problems of this huge category won't be your fault!" ;)

Now, it is not always practical to use safe languages for everything (specially low level libraries such as say, libc...), and that 'huge category' of problems is not even remotely close to being all the security problems. But using tools that prioritize not shooting yourself in the foot by default is not bad consideration to make, all other things being similar.