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

341–350 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#341

Post by AndyKelley »

alkonaut wrote: post #232

Criticism of C aside, when you use a language that isn't very expressive and where it's easy to shoot yourself in the foot, you need to keep it very neat. I mean just look at this https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/pos... That size of methods, huge macros, the low ratio of comments to (non-obvious) statements etc. I know it's easy to criticize very old and tested code, but there is no (and never…

Compare to the musl implementation: http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...

Re: Glibc getaddrinfo stack-based buffer overflow

#342

Post by atom_enger »

collinmanderson wrote: post #338
collinmanderson wrote: post #208

Earlier quoted context omitted.

Ubuntu Trusty 14.04 user here. Am I correct that there's no patch out yet?

Update: It looks like the patch is finally out.

What are you doing to pull this patch? I've apt-get updated and still am seeing Version: 2.19-0ubuntu6.6

Re: Glibc getaddrinfo stack-based buffer overflow

#343

Post by [deleted] »

anon1385 wrote: post #273
autoreleasepool wrote: post #169

Earlier quoted context omitted.

That's such an irrational assertion, ironically enough. Every decision has a trade off, even non-engineering decisions. It's called opportunity cost.

Opportunity cost doesn't make all decisions zero-sum. There is a quirk of human psychology that makes us believe that most things must be zero sum (i.e. that anything I do that improves something I care about must have a 'payback' at a later date and that to achieve a good outcome I must always make an equivalent sacrifice). JabavuAdams is falling for that. Although his inability to control his own violent emotional…

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#344

Post by greiskul »

autoreleasepool wrote: post #100
sargun wrote: post #22

Earlier quoted context omitted.

I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. In my mind, these use cases are quite limited though - integration into 3rd party libraries, legacy codebases, and working in embedded environments. I also agree that performance can be a reason, but see Knuth's opinion on premature optim…

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

Just like a kernel written in C is a big block of assembly code, right? You can isolate any unsafe blocks into small functions, with the smallest scope needed. Same as you would do for asm blocks in C. This is good because it calls attention to what you are doing, when reviewing any code with an unsafe block, you remind yourself to check for these kinds of bugs very carefully, unlike when you are reviewing generic C code where almost every line can have a memory bug.

Re: Glibc getaddrinfo stack-based buffer overflow

#345

Post by alkonaut »

AndyKelley wrote: post #341
alkonaut wrote: post #232

Criticism of C aside, when you use a language that isn't very expressive and where it's easy to shoot yourself in the foot, you need to keep it very neat. I mean just look at this https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/pos... That size of methods, huge macros, the low ratio of comments to (non-obvious) statements etc. I know it's easy to criticize very old and tested code, but there is no (and never…

Compare to the musl implementation: http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...

It's better. The musl version is slightly smaller and tidier but also doesn't handle all the same proticols so it's not a fair comparison. At least it doesn't have a lot of conditional compilation and macros.

But the musl code too has bloody ZERO comments for a nearly 100 line long method of dense/opaque C code! Why? Is commenting and splitting code into functions frowned upon in "traditional" systems programming?

Who is it that writes code like this? Why isn't code like this rejected by a maintainer with "split this into at least smaller 5 functions and comment anything non-obvious"?

Edit: looking again it's actually not that bad, it does have two lookups already broken out and a lot of the verbosity is just field assignment. Would be happy with a dozen lines of comments and a split into 2-3 functions.

Re: Glibc getaddrinfo stack-based buffer overflow

#346

Post by sangnoir »

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…

> it's pretty clear at this point that we need to expunge all C language networking code from the world

Will you bell the cat? I'd pay a lot of money to see Linus' reaction to your massive network-stack replacement kernel patch written in Rust.

More seriously though, who is prepared to fund this? Is the risk worth that much effort? Because I see a lot of people being vocal about it on HN, but no real attempt is made to come up with a safe Rust-based alternatives

Re: Glibc getaddrinfo stack-based buffer overflow

#347

Post by latenightcoding »

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…

How did I know this would turn into a C vs Rust debate

Re: Glibc getaddrinfo stack-based buffer overflow

#348

Post by tptacek »

jblow wrote: post #297
colanderman wrote: post #218

Earlier quoted context omitted.

Um, what? char too_small_buffer[256]; function_that_expects_a_big_buffer(too_small_buffer); There's even a paragraph on Wikipedia debunking this idea: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Stacks_t...

Wikipedia is wrong. It is not naive. Yes, this does not solve every possible stack overwrite. But look at the number that have actually happened in the field and whether this would have dramatically reduced vulnerability in those actual real-world cases. Most times it would. Most notably, for overwrites happening within the local stack frame, you completely remove the possibility of overwriting the return address. Th…

Isn't the test case he just gave you a slightly obscured version of the canonical stack overflow?

    void 
    dumb_func(char *user_input) { 
       char buf[64];
       sprintf(buf, "reformatted: %s", user_input);
    }
Overflows in functions whose activation records precede the buffer are --- obviously, because they necessarily involve hand-rolled copy loops --- rarer than those that don't.

Additional fun fact: a few early generations of mid-90s stack overflow exploits didn't even target the activation records at all!

I think it's interesting and worthwhile to consider whether stacks growing upwards would have made exploit development meaningfully harder, but I also think the answer to that question is straightforward: no, not really.

Re: Glibc getaddrinfo stack-based buffer overflow

#349

Post by pjmlp »

aikah wrote: post #256
ufo wrote: post #88

Earlier quoted context omitted.

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

> C++ is not reasonable if your goal is to avoid memory safety bugs. I'll get crucified for saying this but it's easier to write safe code in C++ than C. C requires a perfect discipline very few people can maintain. Cyclone-lang had good ideas about how to fix C, almost 10 years ago. I wish it has been more successful. i was less "alien" looking than Rust.

True, and hence why my rants about C tend to kind of ignore C++, as the community is more safe aware and strives to avoid the C compatibility subset.

However, it is very hard to avoid C++ developers that don't follow the modern C++ mantra to use it as if it was C, specially in the enterprise space.

You end up with "C compiled with C++" code style, which usually isn't subjected to any kind of code reviews or static analysis.

Post reply on HN