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

111–120 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#111

Post by JabavuAdams »

lmm wrote: post #101
JabavuAdams wrote: post #41

[flagged]

> Repeat after me: there is no silver bullet! Nonsense. How many buffer overflows - a vulnerability that simply doesn't happen in any modern language - would it take to convince you that the language is the problem? > Languages like Ruby have had their host of ridiculous security errors. Ruby isn't great, but it's not had anything like the same defect rate as C. > One advantage of legacy code is that it is battle-tes…

Do you think there are fewer currently unknown bugs in software we have yet to re-write, in languages that are currently untested?

Don't make me quote Rumsfeld.

Re: Glibc getaddrinfo stack-based buffer overflow

#112

Post by shaggy »

ptrincr wrote: post #96

Redhat (RHEL5 unaffected) - https://access.redhat.com/security/cve/cve-2015-7547 - https://access.redhat.com/articles/2161461 RHEL6 - https://rhn.redhat.com/errata/RHSA-2016-0175.html - update to glibc-2.12-1.166.el6_7.7.x86_64.rpm RHEL7 - https://rhn.redhat.com/errata/RHSA-2016-0176.html - update to glibc-2.17-106.el7_2.4.x86_64.rpm Debian - https://security-tracker.debian.org/tracker/CVE-2015-7547 Use "aptitude sho…

Thanks for these. Has anyone seen a link from/for CentOS yes?

Re: Glibc getaddrinfo stack-based buffer overflow

#113

Post by autoreleasepool »

School-Cotton wrote: post #74
autoreleasepool wrote: post #56

Earlier quoted context omitted.

I'm not trying to be rude, but I'm sorry... Are you seriously suggesting that rewriting an implementation of the C standard library in a language that isn't C is something that makes any bit of sense? I think you have a fundemental understanding of the roll the C-standard library plays in the C language. Not to mention UNIX in general. Maybe you're suggesting we need an OS based in Rust instead of C (which is more re…

Your post is just a bunch of pathos and doesn't explain why you actually think it's a bad idea. There's no technical reason why the C standard library can't be written in a language other than C. Lots of language libraries are written in languages other than the one they're primarily used with and work fine.

I mean, what problem is this solving?

There's no technical reason why it can't be done, true. It's still a hilariously bad idea that would never succeed. That's aside from the fact that's a completely pointless wheel-reinventing endeavor. Rewrites in general are pretty difficult to justify.

Sorry, I guess my aggressively pragmatic side is showing today. The idea is really dumb.

To be honest, "Let's rewrite the C standard library in Rust" is one of the worst pieces of bikeshedding drivel I've ever read. And I like Rust 100 times more than I like C.

Re: Glibc getaddrinfo stack-based buffer overflow

#114

Post by pdonis »

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.

> Can we agree that it's urgently necessary to rewrite most of the core Linux/OSS stack in memory safe languages?

Why do "we" have to agree? If somebody really believes this is necessary, why don't they just do it?

Re: Glibc getaddrinfo stack-based buffer overflow

#115

Post by JabavuAdams »

gue5t wrote: post #82
JabavuAdams wrote: post #41

[flagged]

Remote code execution occurs in one of exactly two ways. - eval/exec() of untrusted turing-complete code - memory unsafety There are strange machines and logic vulnerabilities, which as you're aware are pitfalls present in all languages, and can be very subtle. But these are not the same as executing arbitrary operations with all the privileges of the process. This is something we can end today, and Rust would suffic…

Every engineering decision has costs as well as benefits.

It's the same reason soldiers only wear heavy armour in the centre of their chests and backs. Why don't we armour the rest? Because the cost outweighs the benefits ... and the tooling (i.e. medevac and modern medicine) makes up for the deficits.

Re: Glibc getaddrinfo stack-based buffer overflow

#116

Post by cft »

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

Re: Glibc getaddrinfo stack-based buffer overflow

#117

Post by lmm »

qb45 wrote: post #85
lmm wrote: post #31

Earlier quoted context omitted.

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

> Anything that's using glibc (directly) is written in C ... and together with stuff using glibc (indirectly) constitutes 99.99% of your software. How much software/languages implement their own DNS resolver instead of just calling libc? How about syscall wrappers?

The JVM looks to have its own implementation. I imagine .net would be the same. There's ocaml-dns for unikernel-deployed OCaml.

A managed language generally doesn't give you direct access to syscalls at all. In rust you can perform them without having to go via C.

Re: Glibc getaddrinfo stack-based buffer overflow

#118

Post by _0w8t »

lmm wrote: post #31
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).

The problem is not C as one can compile C into NaCl or asm.js and get memory safe code. One can also use a number of static checkers. The real problem is that even this is not done in cases when using C is a must due to project nature.

Re: Glibc getaddrinfo stack-based buffer overflow

#119

Post by JabavuAdams »

VMG wrote: post #98
JabavuAdams wrote: post #41

[flagged]

> Repeat after me: there is no silver bullet! You don't wear a seat belt either I assume?

C'mon, that's a really low quality argument. Please assume that I'm not stupid, just because you disagree with me.

Wearing a seat-belt doesn't prevent me from doing anything I want to do, doesn't add any cost to my car that I care about, etc. etc.

There are certainly times where I choose not to wear a helmet, for greater situational awareness, while others would.

Re: Glibc getaddrinfo stack-based buffer overflow

#120

Post by autoreleasepool »

arielb1 wrote: post #65
autoreleasepool wrote: post #56

Earlier quoted context omitted.

I'm not trying to be rude, but I'm sorry... Are you seriously suggesting that rewriting an implementation of the C standard library in a language that isn't C is something that makes any bit of sense? I think you have a fundemental understanding of the roll the C-standard library plays in the C language. Not to mention UNIX in general. Maybe you're suggesting we need an OS based in Rust instead of C (which is more re…

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

I can't even believe I'm the one being called backwards here.

Post reply on HN