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

311–320 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#311

Post by cft »

yyin wrote: post #160
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.

Relatedly, if I point dnscache in djbdns to Google's DNS server as a temp fix (8.8.8.8) in /etc/resolv.conf , will that mitigate the threat?

Re: Glibc getaddrinfo stack-based buffer overflow

#312

Post by EdSharkey »

steveklabnik wrote: post #279
EdSharkey wrote: post #274

Earlier quoted context omitted.

Well you kindof sound like a performance zealot. Burn some cycles, stop running unmanaged code, just take the hit. It should be justifiable if a Rust implementation of a library is 5-10% slower than its C equivalent. How can choosing to build and deploy unsafe code in today's legal/political/financial environment be defensible? Is it going to take public shaming and frogmarching developers to jail for our industry to…

Depending on what you're doing, it might even be faster, not 5-10% slower. We're currently sometimes faster, sometimes slower, but we should never be slower by a huuuuuge magnitude, though of course, bugs do exist. I've been excitedly watching this over time; I think in a few years Rust could just be straight-up faster than C the majority of the time, depending.

I think you're right with all the new opportunities for optimization in Rust.

I wanted to encourage developers to be open to compiled Rust being nowhere-near an order of magnitude slower than equivalent compiled C and still have it be an acceptable architecture choice for systems-programming.

Re: Glibc getaddrinfo stack-based buffer overflow

#313

Post by twic »

autoreleasepool wrote: post #292
nothrabannosir wrote: post #282

Earlier quoted context omitted.

> ...it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. A bit higher up: It was clear when Hoare stated on his speech in 1980: "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they al…

A sample size of one makes for a worse rule of thumb then a trend based on hard reality. Speed is all that matters, I actually learned that from Graydon's blog: http://graydon2.dreamwidth.org/233585.html#cutid1 Rust sacrificed the majority of its runtime and adopted C's memory model late in development so people wouldn't have to pay a performance cost or depend on confusing heap allocation semantics. That's why it ha…

The enterprise software world didn't leap off C++ and onto Java because it was faster. They did it because it didn't segfault all the time. They then leapt to Perl and Python and Ruby because they didn't segfault all the time and seemed a lot faster to develop in.

To the vast majority of people and organisations writing software, performance of the software, to within an order of magnitude, just isn't a big deal.

Re: Glibc getaddrinfo stack-based buffer overflow

#314

Post by pjmlp »

marshray wrote: post #291
pjmlp wrote: post #219

Earlier quoted context omitted.

I was there. The only reason to get a C compiler for CP/M, MS-DOS or Amiga was to be able to bring work home from those expensive workstations at work or university.

I was there too. C was a common language for developing from-scratch DOS applications in the 1980's. Sometimes portability was a consideration, often not. Mark Williams and Microsoft C were two popular compilers.

Microsoft C before Visual C++ being popular?!

Not on my country, it was all about Borland compilers, even in the Windows 3.x days.

Microsoft was even the last vendor to add support for C++ on the last MS-DOS version of Microsoft C, version 7 if I remember correctly.

Re: Glibc getaddrinfo stack-based buffer overflow

#315

Post by steveklabnik »

EdSharkey wrote: post #312
steveklabnik wrote: post #279

Earlier quoted context omitted.

Depending on what you're doing, it might even be faster, not 5-10% slower. We're currently sometimes faster, sometimes slower, but we should never be slower by a huuuuuge magnitude, though of course, bugs do exist. I've been excitedly watching this over time; I think in a few years Rust could just be straight-up faster than C the majority of the time, depending.

I think you're right with all the new opportunities for optimization in Rust. I wanted to encourage developers to be open to compiled Rust being nowhere-near an order of magnitude slower than equivalent compiled C and still have it be an acceptable architecture choice for systems-programming.

Absolutely. I think trading a bit of speed for a bit of safety is the right choice 99.99% of the time. I've just been excited to watch the benchmarks improve :)

Re: Glibc getaddrinfo stack-based buffer overflow

#316

Post by lukeasrodgers »

LinuxBender wrote: post #50

Has anyone actually tried the PoC on their systems? I will test on CentOS 6 and 7 after I have had my coffee. Anyone willing to volunteer to test on Ubuntu and Debian? Here is CentOS 7 [ 389.064412] do_general_protection: 159 callbacks suppressed [ 389.064416] traps: CVE-2015-7547-c[1161] general rotection ip:7fa6b0d8fd67 sp:7ffdaf034a30 error:0 in libresolv-2.17.so[7fa6b0d87000+16000]

I tested my ubuntu 12.04 and it did not seem to be affected.

  server:
  vagrant@precise32:/tmp/CVE-2015-7547$ sudo python CVE-2015-7547-poc.py
  [UDP] Total Data len recv 36
  [UDP] Total Data len recv 36

  client:
  ./CVE-2015-7547-client
  CVE-2015-7547-client: getaddrinfo: Name or service not known

  vagrant@precise32:/tmp/CVE-2015-7547$ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:    Ubuntu 12.04 LTS
  Release:        12.04
  Codename:       precise

  vagrant@precise32:/tmp/CVE-2015-7547$ ldd --version
  ldd (Ubuntu EGLIBC 2.15-0ubuntu10) 2.15
  Copyright (C) 2012 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  Written by Roland McGrath and Ulrich Drepper.

Re: Glibc getaddrinfo stack-based buffer overflow

#317

Post by autoreleasepool »

twic wrote: post #313
autoreleasepool wrote: post #292

Earlier quoted context omitted.

A sample size of one makes for a worse rule of thumb then a trend based on hard reality. Speed is all that matters, I actually learned that from Graydon's blog: http://graydon2.dreamwidth.org/233585.html#cutid1 Rust sacrificed the majority of its runtime and adopted C's memory model late in development so people wouldn't have to pay a performance cost or depend on confusing heap allocation semantics. That's why it ha…

The enterprise software world didn't leap off C++ and onto Java because it was faster. They did it because it didn't segfault all the time. They then leapt to Perl and Python and Ruby because they didn't segfault all the time and seemed a lot faster to develop in. To the vast majority of people and organisations writing software, performance of the software, to within an order of magnitude, just isn't a big deal.

We aren't talking about enterprise software. It hasn't been mentioned once. You can't change the subject and then say I'm wrong. Obviously, higher level applications can and often should be implemented using garbage collected languages.

Re: Glibc getaddrinfo stack-based buffer overflow

#318

Post by pjmlp »

mikeash wrote: post #228
pjmlp wrote: post #223

Earlier quoted context omitted.

Mac OS, the initial versions. It was a mix of Object Pascal and Assembly. The Pascal extensions that Borland later adopted in TP 5.5.

The initial versions were pure assembly. There was no room for any high-level code. As time went on and more storage was available, that became a possibility, but much of the OS remained assembly. This was a big part of why so much of the OS ran under emulation when the PowerPC Macs were introduced.

Well here there is a bit of different story being told.

http://www.folklore.org/

Search for Pascal.

Cherry picked from the search results

http://www.folklore.org/StoryView.py?project=Macintosh&story...

The fact that many C programmers forget, is that it is impossible to implement the C runtime or an OS with pure ANSI C code.

Somehow it is ok for C to use Assembly and compiler specific extensions, but not for other systems programming languages to do the same.

Re: Glibc getaddrinfo stack-based buffer overflow

#319

Post by pjmlp »

autoreleasepool wrote: post #105
pjmlp wrote: post #97

Earlier quoted context omitted.

Are you are that Visual Studio C library is written in C++ with extern "C" and for Microsoft C is legacy, with .NET Native and C++ with compiler static analysis being the way forward?

IIRC, that's because it's a C++ library, not a real C library. Aside from a few exceptions, it only includes the parts of the C standard that are required by the C++ standard. Hence the dismal C99 support on that platform.

As I mentioned, C is legacy for Microsoft.

The way forward for C on Windows from Microsoft own SDK is to use the clang frontend + Visual C++ backend, or another C compiler from someone else.

Re: Glibc getaddrinfo stack-based buffer overflow

#320

Post by atom_enger »

lukeasrodgers wrote: post #316
LinuxBender wrote: post #50

Has anyone actually tried the PoC on their systems? I will test on CentOS 6 and 7 after I have had my coffee. Anyone willing to volunteer to test on Ubuntu and Debian? Here is CentOS 7 [ 389.064412] do_general_protection: 159 callbacks suppressed [ 389.064416] traps: CVE-2015-7547-c[1161] general rotection ip:7fa6b0d8fd67 sp:7ffdaf034a30 error:0 in libresolv-2.17.so[7fa6b0d87000+16000]

I tested my ubuntu 12.04 and it did not seem to be affected. server: vagrant@precise32:/tmp/CVE-2015-7547$ sudo python CVE-2015-7547-poc.py [UDP] Total Data len recv 36 [UDP] Total Data len recv 36 client: ./CVE-2015-7547-client CVE-2015-7547-client: getaddrinfo: Name or service not known vagrant@precise32:/tmp/CVE-2015-7547$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.0…

I'm seeing the same behavior here. Thanks for the update and confirmation. Can others confirm if this means 12.04 isn't impacted by this cve?
Post reply on HN