Glibc getaddrinfo stack-based buffer overflow • Hacker News Board

Re: Glibc getaddrinfo stack-based buffer overflow

#431

Post by pjmlp » Wed, Feb 17, 2016, 9:39 AM UTC

bsder wrote: post #418

pjmlp wrote: post #414

Earlier quoted context omitted.

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

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

No, it wasn't nothing more than lack of willingness and money to do it, instead they complained about the state of art and went home.

Re: Glibc getaddrinfo stack-based buffer overflow

#432

Post by pjmlp » Wed, Feb 17, 2016, 9:40 AM UTC

bsder wrote: post #424

pjmlp wrote: post #414

Earlier quoted context omitted.

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.

> C compiler performance in the 80's for home micros was so bad, that functions were basically naked entry points to full inline Assembly. For good reason: memory and disk were ferociously expensive until about 1996-1997. Things like unchecked bounds make sense when you can barely get your computer to do what you want. Designing a VLSI chip through about most of the 1990's was HARD . Everything was an exercise in how…

> For good reason: memory and disk were ferociously expensive until about 1996-1997.

Yet Burroughs was able to use Extended Algol in 1961 in an architecture much more constrained than a PDP-11.

> we didn't really have good replacement options for C until starting about 2005.

Ada, Turbo Pascal, Extended Pascal, Modula-2, Modula-2+, Modula-3, Delphi, Oberon, Oberon-2, Component Pascal, Active Oberon, Cedar, Mesa, Algol 68, Extended Algol, CPL,...

Re: Glibc getaddrinfo stack-based buffer overflow

#433

Post by gpderetta » Wed, Feb 17, 2016, 10:09 AM UTC

_0w8t wrote: post #118

lmm wrote: post #31

Earlier quoted context omitted.

It would be a wasted effort. Anything that's using glibc (directly) is written in C and therefore inherently unsafe. There are only two kinds of programs written in C: those that need to do unsafe things and those whose developers don't care about safety. Better to look to building systems that don't need to run any C code (see the recent fuss around unikernels).

The problem is not C as one can compile C into NaCl or asm.js and get memory safe code. One can also use a number of static checkers. The real problem is that even this is not done in cases when using C is a must due to project nature.

Compiling to NaCl or asm.js doesn't make an arbitrary C program memory safe. It "merely" prevents any memory safety failure to affect anything outside the container.

This is different from, for example, java bytecode which is verified and guaranteed to be memory safe.

This is not a mere technicality: an heartbleed vulnerable version of openssl compiled on top of asm.js or NaCl would still leak secret information.

edit: typo

Re: Glibc getaddrinfo stack-based buffer overflow

#434

Post by nyan4 » Wed, Feb 17, 2016, 10:30 AM UTC

qznc wrote: post #57

jimktrains2 wrote: post #7

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 also has nearly no runtime and no garbage collector. Lack of GC makes it possible to integrate a Rust library into scripting languages etc. This is an easier upgrade path from C, which D, Go, Nim, etc cannot provide. (For my projects I prefer D, but Rust has a point here)

Nim GC is optional; It can be disabled to write system libraries.

Re: Glibc getaddrinfo stack-based buffer overflow

#435

Post by pferde » Wed, Feb 17, 2016, 11:17 AM UTC

korethr wrote: post #263

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…

Gentoo https://bugs.gentoo.org/show_bug.cgi?id=CVE-2015-7547

Do I understand it correctly that Gentoo does not plan to push out a fix for this sooner than in 30 days?

Re: Glibc getaddrinfo stack-based buffer overflow

#436

Post by agumonkey » Wed, Feb 17, 2016, 11:48 AM UTC

ploxiln wrote: post #180

chc4 wrote: post #140

Earlier quoted context omitted.

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

Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragma…

Good point, we shouldn't be dogmatic but pragmatic. But there's a fallacy conveyed by seeing C idioms as the only low level ones.

Re: Glibc getaddrinfo stack-based buffer overflow

#437

Post by JdeBP » Wed, Feb 17, 2016, 12:02 PM UTC

Erwin wrote: post #191

It seems tcp_wrappers-libs is using getaddrinfo, so if you have some rules setup there that may be an attack vector. I'm not sure if sshd will want to do a getaddrinfo if you don't have some tcp wrappers rule set up in /etc/hosts.{deny,allow}.

See https://news.ycombinator.com/item?id=8957680 for earlier discussion of that latter point.

Re: Glibc getaddrinfo stack-based buffer overflow

#438

Post by JdeBP » Wed, Feb 17, 2016, 12:42 PM UTC

tomjakubowski wrote: post #165

ajross wrote: post #161

Earlier quoted context omitted.

Why would that matter? This was a bug in a POSIX function that all C libraries would be required to implement.

And the C libraries all implement those functions (mostly) differently. The "lighter weight" standard libraries tend to have simpler implementations of these functions, which may be easier to audit for these kinds of bugs. For example: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/pos... compare with http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...

Your musl libc list is too short. GNU libc puts much of getaddrinfo() into one source file. musl libc splits it across several, including:

* http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...

* http://git.musl-libc.org/cgit/musl/tree/src/network/lookup_s...

* http://git.musl-libc.org/cgit/musl/tree/src/network/lookup_n...

* http://git.musl-libc.org/cgit/musl/tree/src/network/lookup_i...

* http://git.musl-libc.org/cgit/musl/tree/src/network/resolvco...

See also the BSD libc implementation of getaddrinfo():

* https://svnweb.freebsd.org/base/stable/10/lib/libc/net/getad...

* http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/net/getaddr...

Re: Glibc getaddrinfo stack-based buffer overflow

#439

Post by JdeBP » Wed, Feb 17, 2016, 12:46 PM UTC

amelius wrote: post #203

Is there something that can be done about this on the network level? I mean, it seems almost impossible to assure that every instance of getaddrinfo is patched. I'm thinking about a background tool (iptables plugin?) that simply truncates long DNS replies, so that they can never cause a buffer overflow.

See https://news.ycombinator.com/item?id=11112923 on this page.

Re: Glibc getaddrinfo stack-based buffer overflow

#440

Post by JdeBP » Wed, Feb 17, 2016, 1:04 PM UTC

cft wrote: post #325

If I point the local DNS resolver to Google's DNS server as a temp fix (8.8.8.8) in /etc/resolv.conf , will that mitigate the threat before the patch?

The problem is DNS/UDP and DNS/TCP responses that are larger than 2048 bytes hitting your BIND DNS client library. Do you have any reason to believe that Google Public DNS (in your part of the world) always limits its responses to smaller than 2048 bytes?