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

201–210 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#201

Post by pcwalton »

tomjen3 wrote: post #138
BoppreH wrote: post #106

Earlier quoted context omitted.

> Repeat after me: there is no silver bullet! There is no single silver bullet, but there exists silver bullets for a variety of problems. When was the last time you saw a pure Python or pure Java code segfaulting from invalid memory accesses? When was the last time you saw a C/C++ code doing the same? It is simply negligent to use a language or system that exposes you to that many more classes of vulnerabilities . I…

I have segfaulted the Java vm plenty of times. Technically that is not pure Java code, because the vm is written in C++, but it was triggered by pure Java code. I don't use much complex code written in C++ that I can see crash, but I do remember Rails being very happy to execute whatever code you feed it as yaml. Ultimately every language will have bugs when people neglect to validate all possible user input. There i…

Nobody is saying (or, at least, nobody should be saying) that memory-safe languages don't have memory safety errors. The point, and this is empirically backed up by tons of data, is that remote code execution due to memory safety problems happens way way less in memory-safe languages.

Re: Glibc getaddrinfo stack-based buffer overflow

#202

Post by arielb1 »

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.

You need unsafe to implement the C API part of a DNS resolver, but the API can be given a safe wrapper without much effort. Then parsing and buffer management bugs would occur only in safe code and only affect it.

Re: Glibc getaddrinfo stack-based buffer overflow

#203

Post by amelius »

Is there something that can be done about this on the network level? I mean, it seems almost impossible to assure that every instance of getaddrinfo is patched.

I'm thinking about a background tool (iptables plugin?) that simply truncates long DNS replies, so that they can never cause a buffer overflow.

Re: Glibc getaddrinfo stack-based buffer overflow

#204

Post by ptrincr »

bits wrote: post #156
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…

Ubuntu - http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...

Cheers!

Re: Glibc getaddrinfo stack-based buffer overflow

#205

Post by TeMPOraL »

voidlogic wrote: post #192
pjmlp wrote: post #72

Earlier quoted context omitted.

Yes, UNIX was adopted by the corporations and brought C with it. Some people don't get it that before it happened we were happily using other systems programming languages way safer than C.

>Some people don't get it that before it happened we were happily using other systems programming languages way safer than C. Maybe some people, but most systems programming was done is Assembly before C.

No, you're not getting it :). There was a whole world besides Assembly and C, now mostly lost to us. E.g. Lisp machines, which even had hardware support for Lisp-specific things like tagged pointers.

Re: Glibc getaddrinfo stack-based buffer overflow

#206

Post by dbaupp »

SCHiM wrote: post #149
cmrx64 wrote: post #90

Earlier quoted context omitted.

> Written properly, C++ is not unsafe. This is abusing what "unsafe" means. As a language, C++ is inherently unsafe. However, some C++ programs ("written properly") are correct. If written properly C++ is not unsafe, then written properly C is not unsafe.

No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others. Eg. Don't use C++ as C with vectors, use C++ with the more modern language features: It's the difference between: // where f is of type fstream of a file containging "this is a string\r\n"No I think he meant that if you adhere to certain language constructs the language is just as memory safe as R…

> No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others.

It's not; as soon as code uses (for instance) references, you're running the memory-unsafety gantlet. E.g. even something super-modern like

  for (auto& thing: vector)
is risky: what if the loop body happens to somehow call `vector.push_back(x)`?

Re: Glibc getaddrinfo stack-based buffer overflow

#207

Post by rnovak »

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…

If it was "embarassingly basic", wouldn't it have been found way sooner? not YEARS down the line, even DECADES?

Since you mention ruby: https://exchange.xforce.ibmcloud.com/vulnerabilities/89191

What was that about not having buffer overflows in "modern" languages?

Re: Glibc getaddrinfo stack-based buffer overflow

#208

Post by collinmanderson »

bits wrote: post #156
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…

Ubuntu - http://people.canonical.com/~ubuntu-security/cve/2015/CVE-20...

Ubuntu Trusty 14.04 user here. Am I correct that there's no patch out yet?

Re: Glibc getaddrinfo stack-based buffer overflow

#209

Post by steveklabnik »

ploxiln wrote: post #180
chc4 wrote: post #140

Earlier quoted context omitted.

You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!" Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust. Also, extern "C" is for C FF…

Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragma…

We also provide builds of a MUSL-enabled rustc, if that's your thing.

Re: Glibc getaddrinfo stack-based buffer overflow

#210

Post by andrewjl »

autoreleasepool wrote: post #186
chc4 wrote: post #140

Earlier quoted context omitted.

You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!" Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust. Also, extern "C" is for C FF…

Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. You're talking about the forrest - while we're talking about how making trees from scratch is difficult and messed up no matter how you go about it. At some point, you have t…

I'd really like to see a good write up on a project that's trying to tackle this problem on the levels below C. (Assembly or even hardware level.)
Post reply on HN