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

11–20 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#11

Post by efuquen »

hendzen wrote: post #4
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.

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.

I think OP isn't naively assuming it would be easy, or any one person would do it. More the point is there probably isn't enough of an effort or emphasis on the Linux/OSS communities part to even attempt it.

Re: Glibc getaddrinfo stack-based buffer overflow

#12

Post by efuquen »

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.

https://github.com/redox-os/redox

https://github.com/uutils/coreutils

Re: Glibc getaddrinfo stack-based buffer overflow

#13

Post by laumars »

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.

"memory safe" languages aren't a silver bullet and urgently rewriting core libraries in a new language can be more dangerous than our current process of analyzing and fixing the existing vulnerabilities in our current libraries.

However I'm all for experimental research projects developing alternative solutions.

Re: Glibc getaddrinfo stack-based buffer overflow

#14

Post by jimrandomh »

pilif wrote: post #3

How is this related to CVE-2015-0235 (the GHOST vulnerability last year)?

They are separate vulnerabilities in the same codebase, both affecting DNS clients. This one is new, so having previously patched to protect from CVE-2015-0235 does not make you safe from CVE-2015-7547.

Re: Glibc getaddrinfo stack-based buffer overflow

#15

Post by [deleted] »

hendzen wrote: post #4
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.

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.

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#16

Post by golergka »

hendzen wrote: post #4
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.

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.

Right now, companies that run linux on their servers don't have to pay huge fines when security meltdowns happen.

I imagine if they would, they would put more money into the problem: either fund linux development or created more of a market for commercial server operating systems (which can still be open source, at least in some interpretations of the term), for example.

Re: Glibc getaddrinfo stack-based buffer overflow

#18

Post by rtpg »

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

Re: Glibc getaddrinfo stack-based buffer overflow

#19

Post by dalore »

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…

But this is hard for them to 'scan' for. As they need to get vulnerable systems to query their dns server.

But it's not hard to get a system to do a dns query. Sometimes even connecting to it will cause your ip to appear in the logs which are then sometimes reversed ip. But one could easily just create a webpage with img.src pointing to the host.

DNS being distributed could halt the attack upstream by patching their servers to stop the queries so any vulnerable clients won't get compromised even if they make the query.

Re: Glibc getaddrinfo stack-based buffer overflow

#20

Post by thrownaway2424 »

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.

Your comment was inevitable, but can you also include the options of rewriting in any reasonable form? I'd settle for c++ or even readable c. The problem with this code isn't necessarily the language, it's that it is an unreadable, unreviewable mess.
Post reply on HN