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

131–140 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#131

Post by nitrogen »

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

If you have dynamically linked libc (which you should), you only need to upgrade libc and restart all network processes. [Does anyone know if systemd in pid1 calls getaddrinfo? If so, this is another good reason for a minimal pid1, as you will need to reboot]

Re: Glibc getaddrinfo stack-based buffer overflow

#132

Post by asveikau »

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

Unless you are linking statically (and I don't really understand why you would) you update glibc and that's it.

This question had me feeling kind of old. Does nobody learn what shared libraries are anymore?

Re: Glibc getaddrinfo stack-based buffer overflow

#133

Post by ptrincr »

shaggy wrote: post #112
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…

Thanks for these. Has anyone seen a link from/for CentOS yes?

Not sure about Centos, can't find anything. Looks like someone has submitted a patch for Fedora - https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f9e9a34...

I'm guessing Ubuntu will add something here once they get a fixed released - http://www.ubuntu.com/usn/

Should be able to see centos updates here, once they are released, for files glibc-2.12* with a 2016 timestamp -

http://mirror.centos.org/centos/6/updates/x86_64/Packages/

http://mirror.centos.org/centos/7/updates/x86_64/Packages/

Re: Glibc getaddrinfo stack-based buffer overflow

#134

Post by thrownaway2424 »

JabavuAdams wrote: post #115
gue5t wrote: 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.

I have seen my share of benefit-free engineering decisions.

Re: Glibc getaddrinfo stack-based buffer overflow

#135

Post by msbarnett »

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

You patch glibc. Everything else is dynamically linking it.

Re: Glibc getaddrinfo stack-based buffer overflow

#136

Post by thrownaway2424 »

weinzierl wrote: post #121

Can this be used to exploit DNS servers via other rogue DNS servers? What if I setup a rogue DNS and wait for it to be queried by 8.8.8.8. When I own 8.8.8.8 I can exploit every client that queries it. Browsers use getaddrinfo(), don't they?

You think Google's DNS service is based on third-party resolver code?

Re: Glibc getaddrinfo stack-based buffer overflow

#137

Post by ploxiln »

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…

You already have the freedom to run your webservers as mirageos unikernels (with a networking stack written in ocaml). You already have the freedom to write and run everything you want in such an environment.

But what you really want, is to force other people to write code for you, but in a language you prefer (and for it to be easy and convenient for you). Good luck with that.

Re: Glibc getaddrinfo stack-based buffer overflow

#138

Post by tomjen3 »

BoppreH wrote: post #106
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 . I…

I have segfaulted the Java vm plenty of times. Technically that is not pure Java code, because the vm is written in C++, but it was triggered by pure Java code. I don't use much complex code written in C++ that I can see crash, but I do remember Rails being very happy to execute whatever code you feed it as yaml.

Ultimately every language will have bugs when people neglect to validate all possible user input. There is one class of bugs that typically doesn't happen outside C (segfaults) but I can't imagine a C version of Rails executing YAML as code - and at least the segfault is more difficult to exploit.

Re: Glibc getaddrinfo stack-based buffer overflow

#140

Post by chc4 »

tkinom wrote: post #89
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…

Does rust use getaddrinfo()? grep -irn getaddrinfo . ./src/libstd/sys/common/net.rs:123: try!(cvt_gai(c::getaddrinfo(c_host.as_ptr(), ptr::null(), ptr::null(), ./src/libstd/sys/windows/c.rs:1235: pub fn getaddrinfo(node: const c_char, service: const c_char, ./src/libstd/sys/windows/net.rs:69:/// Provides the functionality of `cvt` for the return values of `getaddrinfo` How many places doesn't rust source code use C s…

You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!"

Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust.

Also, extern "C" is for C FFI exports not calling C APIs. The world unanimously decided C FFI is the least common denominator, so its not like Rust can provide a different API with better safety hints.

Post reply on HN