Live data from Hacker News

Glibc getaddrinfo stack-based buffer overflow

googleonlinesecurity.blogspot.com

121–130 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#123

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

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

Re: Glibc getaddrinfo stack-based buffer overflow

#124
post #66

[flagged]

There absolutely are some silver bullets. ALL of these buffer overflows in C happen because the C stack grows backward, and old space is after new space. If anyone have enough of a crap just to standardize a calling convention that went the other way, stack buffer overwrites would ALWAYS go into unused memory. Then security-minded people would switch to this calling convention for secure programs, and many problems w…

Hey jblow. I have a tremendous amount of respect for your work, and advocacy. Thanks.

Something that I've been wondering -- isn't inventing a new language for game developers fighting yesterday's battle?

I've been blown away looking at what Google is doing with C++ indexing, LLVM integration, etc.

I'm experimenting with model-based programming. I.e. toying with the idea that I'm not allowed to write any C++ code, only declarative models that generate C++ code.

This is part of a larger project to essentially automate myself away / transcend, which may or may not be quackery.

Re: Glibc getaddrinfo stack-based buffer overflow

#125

Earlier quoted context omitted.

Rust is actually a decent contender in this space. Memory safe and with the performance of C. > I assume he would argue this is a matter of shitty developers, not a shitty language. All developers are shitty.

Rust is not a decent contender. It is far too immature. The only reasonable contender is C++.

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

Re: Glibc getaddrinfo stack-based buffer overflow

#126
post #101

Earlier quoted context omitted.

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

Do you think there are fewer currently unknown bugs in software we have yet to re-write, in languages that are currently untested? Don't make me quote Rumsfeld.

There're obviously fewer segfaults/memory access vulnerability in software yet-to-be-written in any sane language.

Re: Glibc getaddrinfo stack-based buffer overflow

#127

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

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

Literally the next sentence:

> We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.

Re: Glibc getaddrinfo stack-based buffer overflow

#129
post #82

Earlier quoted context omitted.

Remote code execution occurs in one of exactly two ways. - eval/exec() of untrusted turing-complete code - memory unsafety There are strange machines and logic vulnerabilities, which as you're aware are pitfalls present in all languages, and can be very subtle. But these are not the same as executing arbitrary operations with all the privileges of the process. This is something we can end today, and Rust would suffic…

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.

Re: Glibc getaddrinfo stack-based buffer overflow

#130
post #116

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

Unless you statically link glibc, updating glibc is enough.
Post reply on HN