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

171–180 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#171

Post by BoppreH »

tomjen3 wrote: post #138
BoppreH wrote: post #106

Earlier quoted context omitted.

> Repeat after me: there is no silver bullet! There is no single silver bullet, but there exists silver bullets for a variety of problems. When was the last time you saw a pure Python or pure Java code segfaulting from invalid memory accesses? When was the last time you saw a C/C++ code doing the same? It is simply negligent to use a language or system that exposes you to that many more classes of vulnerabilities . I…

I have segfaulted the Java vm plenty of times. Technically that is not pure Java code, because the vm is written in C++, but it was triggered by pure Java code. I don't use much complex code written in C++ that I can see crash, but I do remember Rails being very happy to execute whatever code you feed it as yaml. Ultimately every language will have bugs when people neglect to validate all possible user input. There i…

> I can't imagine a C version of Rails executing YAML as code

This is the crux of the matter, so please take a moment to reflect on why you believe that. Ruby code is used in much more dynamic environments; environments that would exist in some other language if Ruby didn't exist, and probably would show the same error.

By choosing C you are not allowing some vulnerabilities to gain resistance against others. The gains are in other places: performance, code inertia. And that's the problem. You are deliberately sacrificing safety. Truth or not, that's why everyone is so pissed at this class of bugs.

Re: Glibc getaddrinfo stack-based buffer overflow

#172

Post by mikeash »

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…

Has there been any work on a safe C? Not a C-ish language that is safe, but an actual implementation of the C language itself.

The C standard doesn't require the compiler to check the validity of array indexing and pointer dereferences and such, but it also doesn't require the compiler not to. Can they be added without destroying performance and compatibility?

Some of this already exists, with stuff like stack canaries and address sanitizer. But can it go beyond these ad hoc solutions that catch common mishaps, and become something truly reliable?

It should be possible to just flip a switch on the compiler and have it so that, for example, if you alloca() X bytes and then use the resulting pointer to access byte X+1, that is reliably caught at runtime. And not just as some single patch that specifically looks out for alloca() abuse, but as part of a wider system that understands and catches all out of bounds access.

Re: Glibc getaddrinfo stack-based buffer overflow

#173

Post by ivl »

golergka wrote: post #166
nitrogen wrote: post #157

Earlier quoted context omitted.

No. Strict liability for third party software failure is not a good idea. Software gains much much more from the freedom to innovate than it loses from exploits. Strict liability would be a terrible blow against basically everything HN represents.

Well, there are areas where freedom to innovate is more important, and then there are areas where liability is more important. May be US (as de-facto main government-level actor in IT and internet) could create voluntary certification that opened up companies to such liabilities? Small startup operating from a garage — no certification necessary, but users are aware that no one is guaranteeing anything. IBM? Level A…

If it was voluntary, I doubt many of those companies would see it as worth the risk. The problem is that these errors happen because so many people are working on interdependent parts. Many times, it's not even your error that can make your software vulnerable. I dislike making anything so risky, because we'll see much, much less good software at the end of the day.

Re: Glibc getaddrinfo stack-based buffer overflow

#174

Post by [deleted] »

berdario wrote: post #126
JabavuAdams wrote: post #111

Earlier quoted context omitted.

Do you think there are fewer currently unknown bugs in software we have yet to re-write, in languages that are currently untested? Don't make me quote Rumsfeld.

There're obviously fewer segfaults/memory access vulnerability in software yet-to-be-written in any sane language.

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#177

Post by kyrra »

cft wrote: post #116
jimrandomh wrote: post #9

> "The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack." > "The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the ex…

>Patch ASAP What exactly do you patch? Say you have a TCP server, written in Python or in Go. Do you have to update Python and Go ASAP then and recompile the Go server? Custom compiled Apache, Nginx? Recompile those? That's a lot of work..

For Go, depending on your compile settings, you don't need to recompile. Go 1.5+ uses a pure Go DNS resolver [1], you have to force Go to use glibc. And even if you use glibc, it is not statically linked.

[0] https://golang.org/pkg/net/ (see "netdns" setting)

[1] https://go-review.googlesource.com/#/c/11584/

Re: Glibc getaddrinfo stack-based buffer overflow

#178

Post by scott_s »

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.

Re: Glibc getaddrinfo stack-based buffer overflow

#179

Post by mentat »

asveikau wrote: post #132
cft wrote: post #116

Earlier quoted context omitted.

>Patch ASAP What exactly do you patch? Say you have a TCP server, written in Python or in Go. Do you have to update Python and Go ASAP then and recompile the Go server? Custom compiled Apache, Nginx? Recompile those? That's a lot of work..

Unless you are linking statically (and I don't really understand why you would) you update glibc and that's it. This question had me feeling kind of old. Does nobody learn what shared libraries are anymore?

That isn't it, see siblings here. You have to restart all processes that load glibc and interact with the affected services.

Re: Glibc getaddrinfo stack-based buffer overflow

#180

Post by ploxiln »

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…

Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragmatism) unrelated to the fact that some people still like C.

Just as an ironic aside - C enthusiasts may even have switched to musl-libc already, and are not affected by bugs in glibc, while rust-loving people are vulnerable!

Also interesting, Go has for a long time supported using its own dns resolver instead of libc, but only recently in go 1.5 uses the go dns resolver by default on unix systems.

Post reply on HN