Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Glibc getaddrinfo stack-based buffer overflow

googleonlinesecurity.blogspot.com

Post reply on HN
Print view View original

181–190 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#181

Post by openasocket »

denim_chicken wrote: post #151
ufo wrote: post #88

Earlier quoted context omitted.

C++ is not reasonable if your goal is to avoid memory safety bugs.

Neither is Rust, which comes with a huge RTS that itself likely full of such bugs. The library and the compiler too may have bugs that compromise the "guaranteed" memory safety of a libc written in Rust. There is no silver bullet here. If one takes into account all the sources of bugs, C may very well be the best choice given its maturity and its ecosystem. Our best bet is likely to put more resources towards glibc d…

FYI, Rust has no more of a runtime system than C/C++.

Re: Glibc getaddrinfo stack-based buffer overflow

#182

Post by JabavuAdams »

scott_s wrote: post #178
JabavuAdams wrote: post #41

[flagged]

Your overall point is good - reimplementing basic services will be costly and take a lot of time, and has the potential of introducing design-based errors, even if done in languages which avoid buffer-overflow errors. But you undermine it with your last sentence. Please don't do that.

> But you undermine it with your last sentence. Please don't do that.

I woke up in a mood to murder / burn, but I've dialed it down to being rude on the internet. Perhaps by tonight I'll have reclaimed civility.

Re: Glibc getaddrinfo stack-based buffer overflow

#183

Post by nisa »

bits wrote: post #156
ptrincr wrote: post #96

Redhat (RHEL5 unaffected) - https://access.redhat.com/security/cve/cve-2015-7547 - https://access.redhat.com/articles/2161461 RHEL6 - https://rhn.redhat.com/errata/RHSA-2016-0175.html - update to glibc-2.12-1.166.el6_7.7.x86_64.rpm RHEL7 - https://rhn.redhat.com/errata/RHSA-2016-0176.html - update to glibc-2.17-106.el7_2.4.x86_64.rpm Debian - https://security-tracker.debian.org/tracker/CVE-2015-7547 Use "aptitude sho…

Ubuntu - http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...

Just out of interest: How is this classified medium by Ubuntu? If someone manages to bypass ASLR this is a remote exploit on every SSH server running glibc out there? Or did I misunderstood something?

Out of the box SSH seems to use getaddrinfo:

    reverse mapping checking getaddrinfo for  [] failed - POSSIBLE BREAK-IN ATTEMPT!

Re: Glibc getaddrinfo stack-based buffer overflow

#184

Post by mwcampbell »

The Debian glibc package update that fixes this vulnerability is dated February 11. But the patch wasn't posted on the glibc mailing list until today. So did Debian get the patch even before it was made public upstream? If so, then why didn't Ubuntu get it early as well?

Re: Glibc getaddrinfo stack-based buffer overflow

#186

Post by autoreleasepool »

chc4 wrote: post #140
tkinom wrote: post #89

Earlier quoted context omitted.

Does rust use getaddrinfo()? grep -irn getaddrinfo . ./src/libstd/sys/common/net.rs:123: try!(cvt_gai(c::getaddrinfo(c_host.as_ptr(), ptr::null(), ptr::null(), ./src/libstd/sys/windows/c.rs:1235: pub fn getaddrinfo(node: const c_char, service: const c_char, ./src/libstd/sys/windows/net.rs:69:/// Provides the functionality of `cvt` for the return values of `getaddrinfo` How many places doesn't rust source code use C s…

You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!" Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust. Also, extern "C" is for C FF…

Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay.

You're talking about the forrest - while we're talking about how making trees from scratch is difficult and messed up no matter how you go about it.

At some point, you have to talk to the computer directly (aka "unsafely"). Things like bounds checking, garbage collection, and other runtime utilities sound like great ideas until they translate to significant monetary costs each month.

Not everything is as trivial as writing GUI glue code in a nice comfy language with a magical framework. Although, most of it is.

Re: Glibc getaddrinfo stack-based buffer overflow

#187

Post by pcwalton »

JabavuAdams wrote: post #41

[flagged]

> Languages like Ruby have had their host of ridiculous security errors.

> Fuck Rust and you naive and self-serving evangelists. Come back to me in 20 years with what you've learned.

This might be a cogent criticism (although a pointlessly mean one) if we hadn't started the Rust project with an analysis of precisely what the contents of our security bugs consist of, and designed the project to target those.

Re: Glibc getaddrinfo stack-based buffer overflow

#188

Post by pcwalton »

JabavuAdams wrote: post #115
gue5t wrote: post #82

Earlier quoted context omitted.

Remote code execution occurs in one of exactly two ways. - eval/exec() of untrusted turing-complete code - memory unsafety There are strange machines and logic vulnerabilities, which as you're aware are pitfalls present in all languages, and can be very subtle. But these are not the same as executing arbitrary operations with all the privileges of the process. This is something we can end today, and Rust would suffic…

Every engineering decision has costs as well as benefits. It's the same reason soldiers only wear heavy armour in the centre of their chests and backs. Why don't we armour the rest? Because the cost outweighs the benefits ... and the tooling (i.e. medevac and modern medicine) makes up for the deficits.

> Every engineering decision has costs as well as benefits.

Can you elaborate, in detail, what the costs of memory safety are?

Re: Glibc getaddrinfo stack-based buffer overflow

#189

Post by efuquen »

Can someone give me technical reasons why this world isn't possible:

Parts of the linux kernel or glibc or any other critical C code gets replaced by rust code little parts at a time, which is also calleable from C (https://doc.rust-lang.org/book/ffi.html)? That way these libraries could be made safer in a controlled and incremental manner.

And to reiterate I'm asking for technical limitations, not political or dogmatic.

Re: Glibc getaddrinfo stack-based buffer overflow

#190

Post by xorcist »

lmm wrote: post #101
JabavuAdams wrote: post #41

[flagged]

> Repeat after me: there is no silver bullet! Nonsense. How many buffer overflows - a vulnerability that simply doesn't happen in any modern language - would it take to convince you that the language is the problem? > Languages like Ruby have had their host of ridiculous security errors. Ruby isn't great, but it's not had anything like the same defect rate as C. > One advantage of legacy code is that it is battle-tes…

> the language is the problem

It was literally weeks after Heartbleed. The screams for modern languages with managed runtimes had barely subsided. Then Tomcat, in common use world wide in the poster boy managed language, had a bug with exactly the same impact.

Nobody abandoned Java after that. Just as nobody will abandon C because of this.

> Ruby isn't great, but it's not had anything like the same defect rate

I would argue it's had much worse, altough the comparison is difficult to make. Rails against Apache perhaps, where Rails has had several problems of this magnitude.

I like modern languages as much as the next guy, but I'm very tired of "the language is the problem". Shoving more layers of abstraction in there is not a silver bullet for security. We need to look more at system programming languages.

Post reply on HN