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

411–420 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#411

Post by saturn_vk »

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

But go dynamically links against libc by default

Re: Glibc getaddrinfo stack-based buffer overflow

#412

Post by yazaddaruvala »

denim_chicken wrote: post #152
pyre wrote: post #125

Earlier quoted context omitted.

At what point will people consider Rust mature enough though? If we're going on number of years in existence, then C will always be older than Rust and the "well it's more 'battle-tested'" argument will never be false (for any language that is currently younger than C).

Maybe in a decade.

Do you not use git, because it hasn't been a decade? Will you only start using it after April 7th?

I've heard someone in real life say "git just isn't there yet", so I couldn't resist humoring myself with this comment, sorry.

Re: Glibc getaddrinfo stack-based buffer overflow

#413

Post by draw_down »

pjmlp wrote: post #24
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…

> Thinking a bit more long term, it's pretty clear at this point that we need to expunge all C language networking code from the world, replacing it with Rust or pretty much anything else. That's not sufficient by itself, but it is necessary, or else the periodic Internet security meltdowns won't ever stop. It was already clear in 1961 when Burroughs used Algol and C wasn't even born. It was clear when Hoare stated o…

Hoare shames us with that quote. Really, what else is there to say.

Re: Glibc getaddrinfo stack-based buffer overflow

#414

Post by pjmlp »

bsder wrote: post #384
TeMPOraL wrote: post #205

Earlier quoted context omitted.

No, you're not getting it :). There was a whole world besides Assembly and C, now mostly lost to us. E.g. Lisp machines, which even had hardware support for Lisp-specific things like tagged pointers.

Whose performance was so bad that porting the Lisp Machine software to a general purpose Alpha added multiple factors of performance increase.

C compiler performance in the 80's for home micros was so bad, that functions were basically naked entry points to full inline Assembly.

And here we are now discussing how good modern C compilers are.

If there isn't the willingness to spend the money to optimize performance, of course it won't improve.

Re: Glibc getaddrinfo stack-based buffer overflow

#415

Post by draw_down »

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…

But why is it religion to look at all the problems caused by C code and say, let's try something that doesn't have these problems? Why isn't it religion to look at that history and say no, it's okay, let's keep using C?

Re: Glibc getaddrinfo stack-based buffer overflow

#416

Post by pjmlp »

minimax wrote: post #375
pjmlp wrote: post #24

Earlier quoted context omitted.

> Thinking a bit more long term, it's pretty clear at this point that we need to expunge all C language networking code from the world, replacing it with Rust or pretty much anything else. That's not sufficient by itself, but it is necessary, or else the periodic Internet security meltdowns won't ever stop. It was already clear in 1961 when Burroughs used Algol and C wasn't even born. It was clear when Hoare stated o…

I think the other thing that changed is that branch predictors are roughly infinitely times better than they were in 1980. The is-this-subscript-ok check should be easily predictable and I wonder if these checks even cost anything in a hot loop on a modern CPU.

After Z80 and Sinclair Basic, my next languages were GW-Basic, Turbo Basic and Turbo Pascal, followed by many others.

The Borland languages like many other that allowed for system programming in those days, allowed for disabling bounds checking, as Borland customers weren't like Hoare ones.

I never felt the need to disable them.

Yes they did had a few ms to the program execution, but nothing that would impact the user experience of the application.

This is one of the biggest problem in our industry, specially among C and its derived languages (C++, Objective-C), to micro-optimize each code line without any sort of measurement how it impacts the final application.

Of course there are cases where it really matters, like HPC, games and such, but those are a tiny portion of the software that gets written every day.

Re: Glibc getaddrinfo stack-based buffer overflow

#417

Post by kccqzy »

tomjakubowski wrote: post #255
dbaupp wrote: post #206

Earlier quoted context omitted.

> No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others. It's not; as soon as code uses (for instance) references, you're running the memory-unsafety gantlet. E.g. even something super-modern like for (auto& thing: vector) is risky: what if the loop body happens to somehow call `vector.push_back(x)`?

> is risky: what if the loop body happens to somehow call `vector.push_back(x)`? Some people like to say that these bugs are trivial to avoid ("who would write code like that?!"), but they miss the insidious (and common) case: when code several layers down the call stack (in some arbitrary callback assigned at runtime, say) grows the vector/map from under you.

It's still easy to avoid though. Just take a const reference to the vector and use that in the loop and pass that to the callback. It just requires discipline, and in fact less discipline than writing C.

Re: Glibc getaddrinfo stack-based buffer overflow

#418

Post by bsder »

pjmlp wrote: post #414
bsder wrote: post #384

Earlier quoted context omitted.

Whose performance was so bad that porting the Lisp Machine software to a general purpose Alpha added multiple factors of performance increase.

C compiler performance in the 80's for home micros was so bad, that functions were basically naked entry points to full inline Assembly. And here we are now discussing how good modern C compilers are. If there isn't the willingness to spend the money to optimize performance, of course it won't improve.

The initial port of Genera to an Alpha matched the performance of Symbolics fastest workstations:

http://pt.withy.org/publications/VLM.html "Version 1.0 of the emulator exceeded our initial performance goals, achieving nearly the performance of our high-end custom workstation."

An initial port to a foreign architecture (in-order execution, 64-bit memory space which is going to overload caches, inefficient 8-bit transactions) matched 15+ years of hardware development on the native architecture.

That wasn't lack of money or development. That was a stunning rebuke that Lisp Machines had an inferior architecture.

Re: Glibc getaddrinfo stack-based buffer overflow

#419

Post by alkonaut »

spc476 wrote: post #405
alkonaut wrote: post #345

Earlier quoted context omitted.

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

As long as the function is doing one thing conceptually, I don't see the benefit of breaking it up into multiple routines just because it's too long (for some arbitrary length). Not only do you have the cognitive overhead of trying to come up with a name [1], but passing in all the required parameters to the function. And for this function, I personally don't see any good "breaking points". At work, I have to deal wi…

It's true that a function in an expressive language can be 10 lines, which in C is 70 lines just because of verbosity (repeated assigns instead of constructors and so on). So while the threshold is certainly higher in C, this is still too large. It does 3-4 things conceptually but 2 (lookups) are already broken out. I can see at least one opportunity more for extracting a function. It's important not least because of testing.
Post reply on HN