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

151–160 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#151

Post by denim_chicken »

ufo wrote: post #88
denim_chicken wrote: post #60

Earlier quoted context omitted.

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

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

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 development and especially fuzz testing. I bet there are only 1-2 developers who work on glibc full-time.

Re: Glibc getaddrinfo stack-based buffer overflow

#152

Post by denim_chicken »

pyre wrote: post #125
denim_chicken wrote: post #60

Earlier quoted context omitted.

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

Maybe in a decade.

Re: Glibc getaddrinfo stack-based buffer overflow

#153

Post by w8rbt »

tosseraccount wrote: post #78
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…

Because you can't release a single file statically compiled native binary that relies only on established system calls. People typically can't install packages anymore. They can grab an exe.

This is the reason I ported several Python and Java apps to C++. One exe and it just works.

Re: Glibc getaddrinfo stack-based buffer overflow

#154

Post by ComputerGuru »

Everyone's going crazy advising everyone else to update, but the glibc homepage is happily, statically sitting on version 2.22 from 2015-08-14.

Maybe we should start by releasing an update there asap, and go from there?

(I just switched our last Linux server over to FreeBSD, despite some software we use not being available; so I'm happy to sit this one out.)

Re: Glibc getaddrinfo stack-based buffer overflow

#155

Post by jimrandomh »

weinzierl wrote: post #123
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…

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

Re: Glibc getaddrinfo stack-based buffer overflow

#156

Post by bits »

ptrincr wrote: post #96

Redhat (RHEL5 unaffected) - https://access.redhat.com/security/cve/cve-2015-7547 - https://access.redhat.com/articles/2161461 RHEL6 - https://rhn.redhat.com/errata/RHSA-2016-0175.html - update to glibc-2.12-1.166.el6_7.7.x86_64.rpm RHEL7 - https://rhn.redhat.com/errata/RHSA-2016-0176.html - update to glibc-2.17-106.el7_2.4.x86_64.rpm Debian - https://security-tracker.debian.org/tracker/CVE-2015-7547 Use "aptitude sho…

Ubuntu - http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...

Re: Glibc getaddrinfo stack-based buffer overflow

#157

Post by nitrogen »

golergka wrote: post #16
hendzen wrote: post #4

Earlier quoted context omitted.

So are you personally volunteering to rewrite all of Linux and glibc in Rust? Are you or your employer volunteering to fund such efforts? There is a reason it hasn't happened yet - because doing so would be exceptionally time consuming and expensive.

Right now, companies that run linux on their servers don't have to pay huge fines when security meltdowns happen. I imagine if they would, they would put more money into the problem: either fund linux development or created more of a market for commercial server operating systems (which can still be open source, at least in some interpretations of the term), for example.

No. Strict liability for third party software failure is not a good idea. Software gains much much more from the freedom to innovate than it loses from exploits. Strict liability would be a terrible blow against basically everything HN represents.

Re: Glibc getaddrinfo stack-based buffer overflow

#158

Post by gpderetta »

cmrx64 wrote: post #90
d0lph wrote: post #55

Earlier quoted context omitted.

Written properly, C++ is not unsafe. Certain language own certain domains, for better or worse, this means that most developers interested in low level programming will know C/C++, and that the will be a substantial amount of tooling already in place.

> Written properly, C++ is not unsafe. This is abusing what "unsafe" means. As a language, C++ is inherently unsafe. However, some C++ programs ("written properly") are correct. If written properly C++ is not unsafe, then written properly C is not unsafe.

I don't subscribe to the "properly written Modern C++ is safe" meme, but still it must be recognized that there are degrees of unsafety [1] between languages.

[1] not talking about memory safety, but as a general "probability of having a defect".

Re: Glibc getaddrinfo stack-based buffer overflow

#160

Post by yyin »

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…

Is djbdns vulnerable? It does not use these routines.

I've never needed ENDS0, but maybe the need will arise someday. Meanwhile...

Short term, I'd prefer to expunge all "C networking code" originating from BIND authors, e.g., libresolv.

Post reply on HN