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

31–40 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#31

Post by lmm »

rtpg wrote: post #18

Are there any big efforts to rewrite glibc in something like rust? ... Is that a thing that is even possible? An in-place replacement library for dynamic or static linking. I'm really worried that I still hear about buffer overflows in this day and age. Of all the libraries in the world, glibc should probably be written in some subset of Idris that compiles into 100% safe C. We have the technology to move to this now

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

Re: Glibc getaddrinfo stack-based buffer overflow

#32

Post by masterleep »

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…

An intermediate step is to run everything under AddressSanitizer, since it's fast enough for many cases. See, for example:

https://blog.hboeck.de/archives/879-Safer-use-of-C-code-runn...

Re: Glibc getaddrinfo stack-based buffer overflow

#33

Post by pjmlp »

sargun wrote: post #22
Munksgaard wrote: post #2

Can we agree that it's urgently necessary to rewrite most of the core Linux/OSS stack in memory safe languages? Exploits like this come up all the time, and we know how to completely eliminate them. I don't care if it's Rust or D or Go or Haskell or OCaml or anything else, as long as it's not C. The sooner we do this, the better.

I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. In my mind, these use cases are quite limited though - integration into 3rd party libraries, legacy codebases, and working in embedded environments. I also agree that performance can be a reason, but see Knuth's opinion on premature optim…

Sometimes there isn't any other choice.

For example, in the mobile OS space if you want to write native apps, without rewriting 100% of the application code per platform and avoid toolchain debugging headaches, C and C++ are the only languages available in iOS, Android and WP SDKs.

In WP case, there are APIs like DirectX that aren't fully exposed via WinRT, so you need to write a C++ wrapper for those type of APIs.

There are other options, but they are either commercial (e.g. Xamarin), or require lots of DYI hacking with the SDKs toolchains.

So if you want to remain productive and not pay for the commercial solutions, there aren't any other alternatives.

Which means, even I with my safety rants, end up using them for my mobile OS hobby coding.

However if I would be doing this commercially, Xamarin would be my first option.

Re: Glibc getaddrinfo stack-based buffer overflow

#34

Post by 0x0 »

spyrosk wrote: post #23

So can someone ELI5 how bad this is? From what I'm reading this should only affect systems that use a compromised DNS server or in a MitM attack scenario. Which is serious but not so easily exploitable (I think).

It's worse than that. According to https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html any system that performs a DNS lookup may be hit. And it's not hard to cause DNS lookups to happen (think reverse DNS lookups when logging login attempts, hovering a link in an email or webpage, etc):

  - A back of the envelope analysis
  shows that it should be possible 
  to write correctly formed DNS 
  responses with attacker controlled
  payloads that will penetrate a 
  DNS cache hierarchy and therefore
  allow attackers to exploit machines 
  behind such caches.
So even if you trust your local ISP and DNS servers, any random domain on the internet may be resolving to an exploit.

Also, this vulnerability has apparently been around since 2008, and sitting in public view on the bugtracker for many months. Who knows who else has been sitting quietly on this for however long? :-/

Re: Glibc getaddrinfo stack-based buffer overflow

#35

Post by thrownaway2424 »

peterwwillis wrote: post #30
spyrosk wrote: post #23

So can someone ELI5 how bad this is? From what I'm reading this should only affect systems that use a compromised DNS server or in a MitM attack scenario. Which is serious but not so easily exploitable (I think).

If you request a network connection to an attacker-controlled host, your network software may try to resolve the attacker's host name. The DNS NS record of their domain may then specify your resolver directly look up the record using the attacker's own name server, meaning you are directly doing DNS queries against the attacker's NS. So in theory, all you need to be exploited is to connect to a compromised host and r…

It could be even worse than that. If the attacker tries to connect to you, your server may try to reverse their IP for logging, and the attacker can control the PTR record. Or the attacker could send you an email that's guaranteed to bounce, and they control the return path that your mailer has to resolve.

Re: Glibc getaddrinfo stack-based buffer overflow

#37

Post by peterwwillis »

lmm wrote: post #27
peterwwillis wrote: post #25

Earlier quoted context omitted.

It's not urgently necessary since all modern systems have some form of simple address space randomization at prelink or exec. Considering the time and effort it would take to safely and completely replace glibc with a new implementation, and the limited scope of its effect on Internet-wide security, it would be more productive to require the kernel itself to support patches like PaX, Exec Shield, or grsec in general,…

None of those things is reliable. They make it harder to exploit this kind of vulnerability, but not impossible; usually they just add one extra required step to the exploitation.

Yes. It's called a mitigation, and it's what we do to make systems more secure. But they certainly can be reliable.

The Internet has been using DNS resolvers known to be vulnerable to cache poisoning birthday attacks for at least 14 years. We add basic defenses that prevent the majority of attacks, and trudge on, rather than fix the protocol itself, which is a big complicated mess. The smaller, less effective fixes reach a broader number of use cases with less effort, and so we get along okay.

Likewise, we know that no matter what language we use, there will be at some point a problem with regard to accessing memory, and so we put protections in place to limit the scope of those attacks in a broad sense. It's a more effective mitigation for a greater number of use cases. It is not a panacea.

Re: Glibc getaddrinfo stack-based buffer overflow

#38

Post by tasqa »

Looking for a quick mitigation technique before patches start rolling out... Would it be wise to limit responses to 512 bytes so the payload cannot be loaded?

Configuring BIND to use a specific buffer size (only for BIND 9.3.2 and newer):

Add the following line to the "options" section of your named.conf file:

edns-udp-size: n

Configuring Unbound to use a specific buffer size:

Add the following line to the "server" section of your unbound.conf file:

edns-buffer-size: n

source: https://labs.ripe.net/Members/anandb/content-testing-your-re...

Re: Glibc getaddrinfo stack-based buffer overflow

#39

Post by lmm »

peterwwillis wrote: post #37
lmm wrote: post #27

Earlier quoted context omitted.

None of those things is reliable. They make it harder to exploit this kind of vulnerability, but not impossible; usually they just add one extra required step to the exploitation.

Yes. It's called a mitigation, and it's what we do to make systems more secure. But they certainly can be reliable. The Internet has been using DNS resolvers known to be vulnerable to cache poisoning birthday attacks for at least 14 years. We add basic defenses that prevent the majority of attacks, and trudge on, rather than fix the protocol itself, which is a big complicated mess. The smaller, less effective fixes r…

I find that a lot of security vulnerabilities result from confusion about what side of a security boundary something is on. Treating a parameter as sorta-untrusted can be actively harmful if it leads someone to believe that parameter was supposed to be untrusted. I think it's much more effective to concentrate on strict, designed security boundaries that stop 100% of attacks than to create a bunch of ad-hoc 80% barriers.
Post reply on HN