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

221–230 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#221

Post by steveklabnik »

autoreleasepool wrote: post #186
chc4 wrote: post #140

Earlier quoted context omitted.

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

  >  it can't be safe at that low level without a performance penalty.
Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty.

Yes, sometimes you still need unsafe, but even then, it's a superset, not a subset: a lot of safety checks still happen inside an unsafe block.

That said, I do think that building a libc in Rust would take a significant investment and I'm not sure who's going to even attempt it, if anyone.

Re: Glibc getaddrinfo stack-based buffer overflow

#222

Post by TeMPOraL »

anon1385 wrote: post #129
JabavuAdams wrote: post #115

Earlier quoted context omitted.

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. This is only true if you are superstitious or religious and believe that good things that happens to you (or humanity in general) must be balanced out by something bad happening.

Costs and benefits don't usually add up to 0. If they did, everything you do in your life would be absolutely irrelevant. The trick is to chose things with best cost+benefit value, and if it's not easy to express all costs and benefits in a single unit (because it may be hard to estimate them), then you chose so that you get costs and benefits you like the most.

Re: Glibc getaddrinfo stack-based buffer overflow

#223

Post by pjmlp »

mikeash wrote: post #168
pjmlp wrote: post #83

Earlier quoted context omitted.

I only bothered to use C when forced into UNIX world via Xenix. Yes Apple runs on top of BSD, because they weren't able to write a new OS and had to buy one, which happened to be built on top of BSD. Once upon a time they had their OS written in Object Pascal, but then they decided to rewrite it in C to welcome those UNIX devs. Nothing prevents them to rewrite parts of the OS in Swift after the language gets more mat…

What Apple OS was written in Object Pascal? It looks like they had an app framework written in that language, but the OS never was. I believe the Mac OS at the time was predominantly written in assembly, possibly with some (non-object) Pascal parts.

Mac OS, the initial versions.

It was a mix of Object Pascal and Assembly. The Pascal extensions that Borland later adopted in TP 5.5.

Re: Glibc getaddrinfo stack-based buffer overflow

#224

Post by TeMPOraL »

ploxiln wrote: post #128
VMG wrote: post #98

Earlier quoted context omitted.

> Repeat after me: there is no silver bullet! You don't wear a seat belt either I assume?

I don't wear a seat belt on a bus - nobody does, they don't even have them except in elementary school buses.

I wonder why it is though, especially on long-distance buses (e.g. intercity), as opposed to public transport inside a city. It feels that a high-speed accident involving a bus would lead to a lot of fatalities and permanent injuries because of lack of seatbelts.

Re: Glibc getaddrinfo stack-based buffer overflow

#225

Post by collinmanderson »

jimrandomh wrote: post #155
weinzierl wrote: post #123

Earlier quoted context omitted.

> The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. Why are browsers missing in the list? Don't they use getaddrinfo() as well?

I'm not sure, but I suspect that major browsers may have their own DNS client implementations, or be calling getaddrinfo from within sandboxed contexts.

Chrome uses a custom DNS client implementation.

https://plus.google.com/+WilliamChanPanda/posts/FKot8mghkok

"The problem is that Chromium is issuing too many DNS queries in a short period of time, which may overload upstream devices (typically cheap NAT routers) ... which will then ignore DNS queries for a period of time."

Re: Glibc getaddrinfo stack-based buffer overflow

#227

Post by steveklabnik »

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…

This is sort of what Cyclone tried, in a way.

Re: Glibc getaddrinfo stack-based buffer overflow

#228

Post by mikeash »

pjmlp wrote: post #223
mikeash wrote: post #168

Earlier quoted context omitted.

What Apple OS was written in Object Pascal? It looks like they had an app framework written in that language, but the OS never was. I believe the Mac OS at the time was predominantly written in assembly, possibly with some (non-object) Pascal parts.

Mac OS, the initial versions. It was a mix of Object Pascal and Assembly. The Pascal extensions that Borland later adopted in TP 5.5.

The initial versions were pure assembly. There was no room for any high-level code. As time went on and more storage was available, that became a possibility, but much of the OS remained assembly. This was a big part of why so much of the OS ran under emulation when the PowerPC Macs were introduced.

Re: Glibc getaddrinfo stack-based buffer overflow

#229

Post by autoreleasepool »

steveklabnik wrote: post #215
autoreleasepool wrote: post #100

Earlier quoted context omitted.

> Can people tell me why they start projects in broad C++, and C still? I may be completely missing some piece of the puzzle. Sure. --- Compelling features: - Unrivaled portability (yes, contrary to folklore C - and to a lesser extent C++ - is more portable than Java) - Excellent libraries - Excellent documentation and learning resources - Unrivaled tooling - perfect mapping to how the computer works - Unrivaled perf…

> a kernel in Rust/Nim/whatever would be under a big unsafe block anyways? Only portions of it do. The whole point of unsafe is that you can encapsulate it, and then go from there.

Definitely. The ability to encapsulate code that is less strictly checked by the compiler is what makes Rust such a compelling alternative to C. I definitely think Rust is the ideal choice for a hobby kernel from scratch in 2016.

My point is that unsafety is unavoidable. You can encapsulate unsafe Rust or wrap plain old C, it's, for all practical purposes, the same. At that level language features matter a lot less. I agree we should minimize and encapsulate loosely checked code as best we can.

Re: Glibc getaddrinfo stack-based buffer overflow

#230

Post by djsumdog »

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 implementation. Then do some performance tests showing memory and time benchmarks of your Rust vs libc implementation. Do a blog post on it. Then we'll take you seriously.

Post reply on HN