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

301–310 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#301

Post by steveklabnik »

DSMan195276 wrote: post #289
efuquen wrote: post #189

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 dog…

I thought about this before, since it seemed like a good idea to me too. It's not that simple though, there's tons of problems you'd hit and the result wouldn't be what you want. The bottom line is that Rust is simply not a drop-in replacement for C: You can't just pass a Vec to some C code and expect it to work. The reality is that you're going to end-up writing a lot of C-like Rust - Which either acts on C types di…

While this is true in some sense, there are also advantages. A ruby gem written in Rust via C FFI was one of the earliest production uses of Rust; the Skylight people still thought (and think) that it was very, very worth it.

https://www.youtube.com/watch?v=2BdJeSC4FFI is a further exploration of this idea and how it works. Yes, you do need that small layer, but future libraries will make it even easier. There's the Neon work, for example: http://calculist.org/blog/2015/12/23/neon-node-rust/

Re: Glibc getaddrinfo stack-based buffer overflow

#302

Post by autoreleasepool »

nightpool wrote: post #288
autoreleasepool wrote: post #258

Earlier quoted context omitted.

A little defensive, maybe? I never claimed Rust was slower than C or that it had a performance penalty (because you should use unsafe). Actually, I pretty much said the opposite. I said they were the same. I was trying to highlight the fact that unsafe Rust and C are not that different when you're doing bitwise operations on bare metal. I was wanted to drive the point that additional abstractions are undesirable at t…

pcwalton is talking about safe rust. Unsafe rust is not really any faster in a lot of cases, and even when it is the goal is to compartmentalize the unsafe code into very small, distinct, easily testable segments.

Again, I'm not talking about performance. I'm talking about low level safety and the difficulties in achieving that in any meaningful way. I wasn't talking about just Rust when I said abstractions cost you speed. It was a (perhaps unclear) general statement about programming. As an aside, unsafe rust is faster than safe rust for a lot of cases.

I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticized Rust.

So far IME, the rust community is extremely defensive and antagonistic to anyone they perceive to have made the slightest criticism. It's immature and irritating. It's the only thing that really turns me off from fully embracing it.

I can't participate in a community that's fundamentally hostile to skepticism.

Re: Glibc getaddrinfo stack-based buffer overflow

#303

Post by yxhuvud »

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?

Does libc even support static linking?

Re: Glibc getaddrinfo stack-based buffer overflow

#304

Post by autoreleasepool »

kbenson wrote: post #294
autoreleasepool wrote: post #258

Earlier quoted context omitted.

A little defensive, maybe? I never claimed Rust was slower than C or that it had a performance penalty (because you should use unsafe). Actually, I pretty much said the opposite. I said they were the same. I was trying to highlight the fact that unsafe Rust and C are not that different when you're doing bitwise operations on bare metal. I was wanted to drive the point that additional abstractions are undesirable at t…

It's not defensive to ask for evidence of a claim. If your statements are too general to be backed up without narrowing the scope or clarifying your intent, it's hardly the other person's fault for requesting clarification or evidence.

Just Asking Questions is a technique that's often used to derail or humiliate a verbal opponent. Forgive me for being cautious.

Also, my statement was not that general or vague. Maybe it could have been clearer, but it appears to have also been misinterpreted by pcwalton.

Re: Glibc getaddrinfo stack-based buffer overflow

#306

Post by strictfp »

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?

Nope, the pendulum is at it's other extreme. Go is going all in on static builds, docker containers freeze ALL THE THINGS \@/ and "immutable" package managers like Nix which in effect is like static linking without the speed benefits.

Re: Glibc getaddrinfo stack-based buffer overflow

#307

Post by strictfp »

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?

Nope, the pendulum is at it's other extreme. Go is going all in on static builds, docker containers freeze ALL THE THINGS \@/ and "immutable" package managers like Nix which in effect is like static linking without the speed benefits.

Re: Glibc getaddrinfo stack-based buffer overflow

#308

Post by steveklabnik »

yxhuvud wrote: post #303
asveikau wrote: post #132

Earlier quoted context omitted.

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?

Does libc even support static linking?

glibc is generally not statically linked. MUSL libc generaly is.

You _can_ statically link glibc, but then you lose some stuff. https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...

Re: Glibc getaddrinfo stack-based buffer overflow

#309

Post by GregBuchholz »

mikeash wrote: post #172
denim_chicken wrote: post #151

Earlier quoted context omitted.

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 canari…

Have you looked at CCured?

http://www.cs.berkeley.edu/~necula/Papers/ccured_pldi03.pdf

"CCured is a program transformation system that adds memory safety guarantees to C programs by verifying statically that memory errors cannot occur and by inserting run-time checks where static verification is insufficient."

Re: Glibc getaddrinfo stack-based buffer overflow

#310

Post by scotchmi_st »

djsumdog wrote: post #230
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…

All this "Let's replace everything with Rust" is extremely childish. Be wary of making programming languages a religion. The Java zealots did it, and you can see the results where full Java projects are used in places where a 20 line Python script would have been easier. If you're serious, one of your pet projects should be trying to implement BSD sockets with Rust. Then try compiling some C apps against your impleme…

I think you're misreading what he says. "...replacing it with Rust /or pretty much anything else/" (emphasis own). The point is we should be replacing C with /pretty much anything else/. Rust looks like the most obvious (but not necessary correct) candidate.

Also performance is not such a big deal as dictate security considerations. One's fancy medical web app is worthless if it leaves the potential for theft of medical data.

Post reply on HN