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

371–380 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#371

Post by peterwwillis »

asveikau wrote: post #132
cft wrote: post #116

Earlier quoted context omitted.

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

The past four years of modern development practices have run screaming from the concept. Learning why the systems used to work they way they did was, like, super hard, so they reinvented the wheel and are running into the same problems that caused us to make shared libraries/COW/etc in the first place.

Re: Glibc getaddrinfo stack-based buffer overflow

#372

Post by peterwwillis »

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

Here's how to find packages on your system with statically linked applications (that probably use glibc):

  [root@server ~]# find /bin/ /sbin/ /usr/bin/ /usr/sbin/ /usr/lib* /usr/local/bin/ /usr/local/sbin/ /usr/local/lib* -type f -perm /u+x -exec file {} \; | grep statically | cut -d : -f 1 | xargs rpm -qf | sort -u
  busybox-1.2.0-7.el5.x86_64
  cryptsetup-luks-1.0.3-5.el5.i386
  cryptsetup-luks-1.0.3-5.el5.x86_64
  device-mapper-1.02.39-1.el5.i386
  device-mapper-1.02.39-1.el5.x86_64
  device-mapper-multipath-0.4.7-34.el5_5.1.x86_64
  dmraid-1.0.0.rc13-63.el5.x86_64
  dump-0.4b41-4.el5.x86_64
  e2fsprogs-1.39-23.el5.x86_64
  glibc-2.5-123.el5_11.1.i686
  glibc-2.5-123.el5_11.1.x86_64
  glibc-common-2.5-123.el5_11.1.x86_64
  grub-0.97-13.5.x86_64
... etc. And yes, it can be a lot of work. It's easier to only use your distro's official packages and update the patched ones they release. Luckily most software devs are smart and compile dynamically.

Re: Glibc getaddrinfo stack-based buffer overflow

#373

Post by drummer32 »

w8rbt wrote: post #270
mentat wrote: post #179

Earlier quoted context omitted.

That isn't it, see siblings here. You have to restart all processes that load glibc and interact with the affected services.

Debian does this automatically and alerts the user what services are being restarted.

It doesnt't. There's the needsrestart package that does this though.

Re: Glibc getaddrinfo stack-based buffer overflow

#375

Post by minimax »

pjmlp wrote: post #24
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…

> Thinking a bit more long term, it's pretty clear at this point that we need to expunge all C language networking code from the world, replacing it with Rust or pretty much anything else. That's not sufficient by itself, but it is necessary, or else the periodic Internet security meltdowns won't ever stop. It was already clear in 1961 when Burroughs used Algol and C wasn't even born. It was clear when Hoare stated o…

I think the other thing that changed is that branch predictors are roughly infinitely times better than they were in 1980. The is-this-subscript-ok check should be easily predictable and I wonder if these checks even cost anything in a hot loop on a modern CPU.

Re: Glibc getaddrinfo stack-based buffer overflow

#376

Post by drummer32 »

IgorPartola wrote: post #48

This is why I enabled automatic security updates on all the machines I control. I'd rather get a monitoring alert that something is broken, than to find out much later that someone rooted my server.

Unless you automatically restart every service that is linked with a library when you update it, you are still vulnerable.

Re: Glibc getaddrinfo stack-based buffer overflow

#377

Post by mschuster91 »

tremon wrote: post #63
mschuster91 wrote: post #28

Earlier quoted context omitted.

> Which is serious but not so easily exploitable (I think). Oh it is. All you need is an open wifi with a router only dealing IPv4 addresses... start up radvd and serve your machine as authoritative IPv6 DNS server, and profit.

That requires local area access. So maybe easily exploitable, not easy to do mass infections. Besides, how many distro's are actually configured for dhcpv6 stateful configuration out of the box?

Windows and OS X AFAIK, as well as the Debian installer... not sure about mainstream distros though.

Re: Glibc getaddrinfo stack-based buffer overflow

#378

Post by nly »

cmrx64 wrote: post #86
cnvogel wrote: post #52

As far as I see the bug primarily lies within this function here... resolv/res_send.c https://github.com/bminor/glibc/blob/master/resolv/res_send.... Lines 952 ... 1389 [=~450 lines of code], with more than a dozen of variables holding random state. Think about the complexity you have with all the conditionals and loops, often copying and pasting similar conditions with (xx1 && xx2) variants. While discusions about t…

You sure can prove that any correct code does something correct, but you can never prove something about a program outside of a machine-checked formal proof.

The problem is that it's far more difficult to prove what code doesn't do than what it does. I can write a function to do X, Y and Z, and I can show, through observation and aggressive testing, that it does indeed do X,Y and Z....but its a lot harder to prove that it only does X,Y and Z and nothing else. Memory safety is just one expression of this problem.

Re: Glibc getaddrinfo stack-based buffer overflow

#379

Post by acln »

AsyncAwait wrote: post #277
takeda wrote: post #248

Fun fact: If you have programs written in Go, after patching this you probably will need to recompile all of them.

Go 1.5 uses its own pure-Go DNS resolver.

Under certain conditions, it does not.

https://golang.org/pkg/net/#hdr-Name_Resolution

Re: Glibc getaddrinfo stack-based buffer overflow

#380

Post by ossreality »

djsumdog wrote: post #230
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…

All this "Let's replace everything with Rust" is extremely childish. Be wary of making programming languages a religion. The Java zealots did it, and you can see the results where full Java projects are used in places where a 20 line Python script would have been easier. If you're serious, one of your pet projects should be trying to implement BSD sockets with Rust. Then try compiling some C apps against your impleme…

People already doing these exact things with Rust. Sheesh. Put down the pitchfork and take a look around for what you're yelling for first.
Post reply on HN