Glibc getaddrinfo stack-based buffer overflow
googleonlinesecurity.blogspot.com
Glibc getaddrinfo stack-based buffer overflow
1–10 of 480 posts
Re: Glibc getaddrinfo stack-based buffer overflow
#2Can 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.
Re: Glibc getaddrinfo stack-based buffer overflow
#3How is this related to CVE-2015-0235 (the GHOST vulnerability last year)?
Re: Glibc getaddrinfo stack-based buffer overflow
#4Can 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.
So are you personally volunteering to rewrite all of Linux and glibc in Rust? Are you or your employer volunteering to fund such efforts? There is a reason it hasn't happened yet - because doing so would be exceptionally time consuming and expensive.
Re: Glibc getaddrinfo stack-based buffer overflow
#5Can 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.
"It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack.
Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.
Re: Glibc getaddrinfo stack-based buffer overflow
#6Can 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 happy to have more contributors! ;) https://robigalia.org/
Re: Glibc getaddrinfo stack-based buffer overflow
#7Can 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.
"It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack. Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.
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.
Re: Glibc getaddrinfo stack-based buffer overflow
#8An extra gold star for the valuable comments added by the patch! https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
Re: Glibc getaddrinfo stack-based buffer overflow
#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 exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further."
> "Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR."
It is time for the bimonthly Internet security meltdown. Again. When they say that "exploitation vectors are diverse and widespread", they really mean it. Patch ASAP. This is a race; it is only a matter of time before criminals start automatically and systematically scanning every server on the internet for this, and you really really want to be patched before that happens.
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.
Re: Glibc getaddrinfo stack-based buffer overflow
#10Earlier quoted context omitted.
"It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack. Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.
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.
[deleted]