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

101–110 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#101

Post by lmm »

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-tested. It's not sexy, it's not clean, but neither is the real world.

Then why do we keep finding these embarrassingly basic flaws in that "battle-tested" code?

Re: Glibc getaddrinfo stack-based buffer overflow

#102

Post by [deleted] »

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…

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#103

Post by lmm »

IgorPartola wrote: post #42
pjmlp wrote: post #29

Earlier quoted context omitted.

Apparently until the UNIX culture that worships C exist, it won't happen. C only became a thing in computing after UNIX workstations became popular. Before it, there were quite a few safer systems programming languages to choose from, that got steam rolled by C adoption in OS SDKs. Due to its relation with UNIX, it will most likely happen with Apple (Swift), Microsoft (.NET Native, System C#, C++/GSL), Google (Java F…

> Java FTW on Android This made me smile. Need I point out that Android runs on top of Linux? Or that you can still use C/C++ on Android? http://developer.android.com/tools/sdk/ndk/index.html

Just because it's not perfect doesn't mean it's not better. Yes Android runs x000 lines of C and that's x000 lines too many, but it's still a substantial improvement over desktop systems.

Re: Glibc getaddrinfo stack-based buffer overflow

#104

Post by pjmlp »

IgorPartola wrote: post #79
pjmlp wrote: post #64

Earlier quoted context omitted.

Yes and I use it. I also feel the pains that Android teams imposes on the NDK users to use it as little as possible. If you bothered to read the contents of the link that you pushed. "Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because yo…

Nonetheless, it's something that is available to you as a developer. I am firmly in the "right tool for the job" camp, and I can see situations where C is the better tool. I don't see why mobile app development would benefit from it, but I almost never have the opportunity to work with Android. I have never attempted to put together a full libc in ANSI C, no. My experience there is limited to putting together parts o…

Excuse me if it felt personal it wasn't my intention, just the way I write.

Non native speaker here.

As I mentioned in the reply and in another thread, I do use the NDK, but I wouldn't if there were better alternatives.

30 years ago those microcontrollers would probably be programmable in Assembly and Forth, Pascal, Basic and C dialects. At least when I think about Z80 like ones.

Re: Glibc getaddrinfo stack-based buffer overflow

#105

Post by autoreleasepool »

pjmlp wrote: post #97
autoreleasepool wrote: post #56

Earlier quoted context omitted.

I'm not trying to be rude, but I'm sorry... Are you seriously suggesting that rewriting an implementation of the C standard library in a language that isn't C is something that makes any bit of sense? I think you have a fundemental understanding of the roll the C-standard library plays in the C language. Not to mention UNIX in general. Maybe you're suggesting we need an OS based in Rust instead of C (which is more re…

Are you are that Visual Studio C library is written in C++ with extern "C" and for Microsoft C is legacy, with .NET Native and C++ with compiler static analysis being the way forward?

IIRC, that's because it's a C++ library, not a real C library. Aside from a few exceptions, it only includes the parts of the C standard that are required by the C++ standard. Hence the dismal C99 support on that platform.

Re: Glibc getaddrinfo stack-based buffer overflow

#106

Post by BoppreH »

JabavuAdams wrote: post #41

[flagged]

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

Imagine a language where the compiler randomly accesses another variable if you mistype a name. No error, you just get a random value. Would you defend such a language? "All languages have faults! There is no silver bullet!" Except for this* particular problem, there is a silver bullet.

I agree wholeheartedly with your dismissal of rewriting battle tested code. But the need to migrate is clear, and we don't have to do it at once. It can be done slowly, one piece at a time. And it should be.

* For non-trivial code exposed to untrusted input.

Re: Glibc getaddrinfo stack-based buffer overflow

#107

Post by _0w8t »

School-Cotton wrote: post #77
zzzcpan wrote: post #21

Earlier quoted context omitted.

This is one of those things that usually cannot be linked statically at all. So, not many things to upgrade.

Why can't it be linked statically?

Glibs uses /etc/nsswitch.conf to decide at runtime which libraries has to be loaded dynamically to implement DNS resolver, user lookup etc. One in principle can compile those libraries statically, but it is rather complicated for no gains, so almost nobody is doing that.

Re: Glibc getaddrinfo stack-based buffer overflow

#109

Post by JabavuAdams »

[deleted] wrote: post #58
JabavuAdams wrote: post #45

Earlier quoted context omitted.

EDIT> Also, do you seriously think humans will be programming in 20-50 years? We'll be operating at a higher level and just boiling it down to C/asm anyway. If you want to make a difference, then work on machine programming. If you're inventing a new programming language, then you're fighting yesterday's battle.

[deleted]

Quantity has a quality all its own. If you look at what Google is doing with their code indexing, deep integration with LLVM, etc ... it's about tooling at a certain point, not so much the language.

Re: Glibc getaddrinfo stack-based buffer overflow

#110

Post by hannob »

masterleep wrote: post #32
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…

An intermediate step is to run everything under AddressSanitizer, since it's fast enough for many cases. See, for example: https://blog.hboeck.de/archives/879-Safer-use-of-C-code-runn...

It likely won't help. I excluded glibc from using ASAN to let this work.

It is theoretically possible to use ASAN on glibc as well, but it's complicated and certainly not ready for any kind of production use.

Also although this is my work, it's far from clear to me whether using ASAN in production really is a useful thing. Practically I'd rather suggest looking at the safestack and CFI features of clang for production use instead.

Post reply on HN