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

331–340 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#331

Post by weinzierl »

inopinatus wrote: post #234
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?

No. Recursive resolvers do not use getaddrinfo(3) to resolve DNS queries.

That was what I was thinking but it was stupid idea.

My point is that if you could use this bug to use one rogue DNS to own other DNSes this could be leveraged to bring large parts of the Internet down.

I don't know how hard or easy this could be. A quick glance into PDNS reveals four calls to getaddrinfo()[1]. So it might be possible...

[1] https://github.com/PowerDNS/pdns/search?utf8=%E2%9C%93&q=get...

Re: Glibc getaddrinfo stack-based buffer overflow

#332

Post by thrownaway2424 »

weinzierl wrote: post #328
thrownaway2424 wrote: post #136

Earlier quoted context omitted.

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

I'm out of my element here but is it really so far fetched? A quick search in the PowerDNS codebase [1] reveals four sites where getaddrinfo() is called. This isn't obviously the code for recursive lookups but that doesn't matter. If an attacker can trick it to query their rogue DNS they have won. I don't want to suggest that Google uses PowerDNS, I just used is as an example. [1] https://github.com/PowerDNS/pdns/sea…

It just seems out of character. Google is huge with the not-invented-here.

Re: Glibc getaddrinfo stack-based buffer overflow

#333

Post by _0w8t »

If alloca could be used to get arbitrary-sized buffer the bug would not exist. Another Y story https://fosdem.org/2016/schedule/event/ada_memory/ points out that Ada does not have this limitation. There it is a job of the compiler to allocate bug chunks outside of the stack not to cause stack overflows. C really needs such API.

Re: Glibc getaddrinfo stack-based buffer overflow

#334

Post by kbenson »

[deleted] wrote: post #329
kbenson wrote: post #327

Earlier quoted context omitted.

> Again, I'm not talking about performance. But previously you said "because it can't be safe at such a low level without a performance penalty" which clearly implies performance is part of your argument. This is what I was talking about in my other reply, which mentioned "without narrowing the scope or clarifying your intent". > I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticize…

[deleted]

Well, I'm by no means part of the rust community, so don't let anything I say reflect upon them.

That said, how else do you correct someone in the case their statements are provably false?

Edit: Whoops, "probably" was supposed to be "provably" :/

Re: Glibc getaddrinfo stack-based buffer overflow

#335

Post by [deleted] »

kbenson wrote: post #327
autoreleasepool wrote: post #302

Earlier quoted context omitted.

Again, I'm not talking about performance. I'm talking about low level safety and the difficulties in achieving that in any meaningful way. I wasn't talking about just Rust when I said abstractions cost you speed. It was a (perhaps unclear) general statement about programming. As an aside, unsafe rust is faster than safe rust for a lot of cases. I re-read what I wrote and I fail to see where I attacked or even (God fo…

> Again, I'm not talking about performance. But previously you said "because it can't be safe at such a low level without a performance penalty" which clearly implies performance is part of your argument. This is what I was talking about in my other reply, which mentioned "without narrowing the scope or clarifying your intent". > I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticize…

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#336

Post by [deleted] »

kbenson wrote: post #334
[deleted] wrote: post #329

Earlier quoted context omitted.

[deleted]

Well, I'm by no means part of the rust community, so don't let anything I say reflect upon them. That said, how else do you correct someone in the case their statements are provably false? Edit: Whoops, "probably" was supposed to be "provably" :/

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#337

Post by RaleyField »

pcwalton wrote: post #285
RaleyField wrote: post #275

Earlier quoted context omitted.

Memory safety costs 10% in execution speed and takes 50% more effort to develop, a fair trade-off anyone can take on behalf of their customers. Shortcomings of C are offset by many eyeballs law and the security life-cycle processes so much so that we can afford to safely abandon most organized auditing as well as any defensive coding.

> Memory safety costs 10% in execution speed and takes 50% more effort to develop, a fair trade-off anyone can take on behalf of their customers. That doesn't match my experience. Source? > Shortcomings of C are offset by many eyeballs law and the security life-cycle processes so much so that we can afford to safely abandon most organized auditing as well as any defensive coding. In effect, you're saying we shouldn't…

> That doesn't match my experience. Source?

No source. There's always a price to pay. Rust is zero-cost, but only on a subset of algorithms that are valid in idiomatic Rust. If you translate Rust to C you won't gain on speed, but if you translate C to Rust you might have to reorganize it and that will cost you. If your subset involved mostly increments and decrements of data and address registers then language called brainfuck would be zero-cost. Correct me if I'm wrong, but I'm led to believe at least some problems that would be most naturally expressed with graph structures will require reference counting when rewritten in safe Rust. Then again there are trade-offs in Rust that I might not be aware of, Singularity exceeded raw C in some instances by replacing overhead and functionality of MMU with static checking in compiler.

> In effect, you're saying we shouldn't care about security vulnerabilities

Cue a rant from spengler/deraadt. I was being sarcastic. We should rewrite most of our software in Rust 20 years ago. ;)

Re: Glibc getaddrinfo stack-based buffer overflow

#338

Post by collinmanderson »

collinmanderson wrote: post #208
bits wrote: post #156

Earlier quoted context omitted.

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

Ubuntu Trusty 14.04 user here. Am I correct that there's no patch out yet?

Update: It looks like the patch is finally out.

Re: Glibc getaddrinfo stack-based buffer overflow

#339

Post by arbruijn »

Gratsby wrote: post #237

Has anyone put together a POC that doesn't require re-pointing the system nameserver and crashing other applications?

You can create a small chroot with a custom resolv.conf.

Example (tested on Ubuntu 14.04 64-bit):

  mkdir -p root/lib/x86_64-linux-gnu root/lib64 root/etc
  cp -a --parents /lib/x86_64-linux-gnu/lib{c,nss,resolv}* root
  cp /lib64/ld-linux-x86-64.so.2 root/lib64
  cp CVE-2015-7547-client root
  echo 'nameserver 127.0.0.1' > root/etc/resolv.conf
  sudo chroot root ./CVE-2015-7547-client
If it prints nothing it crashed. Try running with strace to be sure.

Re: Glibc getaddrinfo stack-based buffer overflow

#340

Post by School-Cotton »

autoreleasepool wrote: post #120
arielb1 wrote: post #65

Earlier quoted context omitted.

Rust can have the same ABI as C - rewriting NSS in Rust should not pose ABI problems.

It's still completely pointless. How would mmap be any different if it was implemented in Rust rather than in C? You need unsafe to implement it! The safety mechanisms are practically useless at such a low level. Wrap existing C with safe Rust, not the other way around! We don't rewrite unsafe C code in Unsafe Rust so that it can be called from all the unsafe C code in UNIX. Such a translation is so pointless and err…

To add to what others have said: mmap is a system call; it's not something provided by libc.
Post reply on HN