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

271–280 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#271

Post by steveklabnik »

acconsta wrote: post #261
steveklabnik wrote: post #221

Earlier quoted context omitted.

> it can't be safe at that low level without a performance penalty. Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. Yes, sometimes you still need unsafe, but even then, it's a superset, not a subset: a lot of safety checks still happen inside an unsafe block. That said, I do think that building a libc in Rust would take a significant investment and I'm not sur…

>Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. But not bounds checks, which are unfortunately what you need with respect to buffer overflows.

Yes, absolutely.

Re: Glibc getaddrinfo stack-based buffer overflow

#272

Post by dang »

JabavuAdams wrote: post #143
anon1385 wrote: post #129

Earlier quoted context omitted.

>Every engineering decision has costs as well as benefits. This is only true if you are superstitious or religious and believe that good things that happens to you (or humanity in general) must be balanced out by something bad happening.

Are fucking serious? Have you built anything significant? This is a very empirical view, not a superstition. If you want to learn more about this, and aren't just trolling look at the development of the A4 Skyhawk, the lunar lander, the space shuttle ... hell, any well documented large system. I wish I could reach through the internet and smack you in the head for such a stupid comment.

> Are fucking serious? Have you built anything significant? [...] I wish I could reach through the internet and smack you in the head for such a stupid comment.

I gave you a general reply upthread, but this comment deserves a specific one. You simply can't attack people like this here. I don't think you intended it in a mean way, but it's still the kind of thing we ban accounts for.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

Re: Glibc getaddrinfo stack-based buffer overflow

#273

Post by anon1385 »

autoreleasepool wrote: post #169
anon1385 wrote: post #129

Earlier quoted context omitted.

>Every engineering decision has costs as well as benefits. This is only true if you are superstitious or religious and believe that good things that happens to you (or humanity in general) must be balanced out by something bad happening.

That's such an irrational assertion, ironically enough. Every decision has a trade off, even non-engineering decisions. It's called opportunity cost.

Opportunity cost doesn't make all decisions zero-sum. There is a quirk of human psychology that makes us believe that most things must be zero sum (i.e. that anything I do that improves something I care about must have a 'payback' at a later date and that to achieve a good outcome I must always make an equivalent sacrifice).

JabavuAdams is falling for that. Although his inability to control his own violent emotional outbursts is probably going to be the more significant problem in his life.

Re: Glibc getaddrinfo stack-based buffer overflow

#274

Post by EdSharkey »

djsumdog wrote: post #230
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…

All this "Let's replace everything with Rust" is extremely childish. Be wary of making programming languages a religion. The Java zealots did it, and you can see the results where full Java projects are used in places where a 20 line Python script would have been easier. If you're serious, one of your pet projects should be trying to implement BSD sockets with Rust. Then try compiling some C apps against your impleme…

Well you kindof sound like a performance zealot. Burn some cycles, stop running unmanaged code, just take the hit. It should be justifiable if a Rust implementation of a library is 5-10% slower than its C equivalent. How can choosing to build and deploy unsafe code in today's legal/political/financial environment be defensible? Is it going to take public shaming and frogmarching developers to jail for our industry to make a change?

We need to discredit performance zealots and gently herd them to a profitable careers in videogame development where they can't do much harm.

And, there's plenty to dog on Java about, but that language and VM very intentionally makes it an ordeal to load a 3rd party binary blob. Modern development systems/VM's seem to have waved off concerns about unmanaged code and security; Node.JS compiles and loads binary blobs from dependencies all willy-nilly. Java took and takes security seriously.

Re: Glibc getaddrinfo stack-based buffer overflow

#275

Post by RaleyField »

pcwalton wrote: post #188
JabavuAdams wrote: post #115

Earlier quoted context omitted.

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.

> Every engineering decision has costs as well as benefits. Can you elaborate, in detail, what the costs of memory safety are?

Memory safety costs 10% in execution speed and takes 50% more effort to develop, a fair trade-off anyone can take on behalf of their customers. Shortcomings of C are offset by many eyeballs law and the security life-cycle processes so much so that we can afford to safely abandon most organized auditing as well as any defensive coding.

Re: Glibc getaddrinfo stack-based buffer overflow

#276

Post by J_Darnley »

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…

> Can people tell me why they start projects in ... C still?

Okay. Based on my current project (Porting AVS out of shit-tier Microsoft C++). I want a region of memory in which I can treat as a bitmap and set pixels at given location to given colours. I know of no other language that gives me this block of memory to draw into. That's probably because I don't know enough. Most languages seem to tout how immutable things are. That's a big word for many people and it just means "does not change".

If other languages want my attention then maybe they need more than a "Hello, World!" and some string processing. Show me your malloc equivalent and see if I can go from there.

Re: Glibc getaddrinfo stack-based buffer overflow

#278

Post by the_why_of_y »

arielb1 wrote: post #36

That's what you get when you have thousands of lines of code with variable names like `thisanssizp`. glibc should die in a fire.

The DNS code in resolv/ is not formatted according to GNU coding style - you can tell by the sane placement of braces.

It's a fork of an ancient version of BIND.

  Starting with version 2.2, the resolver in the GNU C Library comes
  from BIND 8.
https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/READ...

Re: Glibc getaddrinfo stack-based buffer overflow

#279

Post by steveklabnik »

EdSharkey wrote: post #274
djsumdog wrote: post #230

Earlier quoted context omitted.

All this "Let's replace everything with Rust" is extremely childish. Be wary of making programming languages a religion. The Java zealots did it, and you can see the results where full Java projects are used in places where a 20 line Python script would have been easier. If you're serious, one of your pet projects should be trying to implement BSD sockets with Rust. Then try compiling some C apps against your impleme…

Well you kindof sound like a performance zealot. Burn some cycles, stop running unmanaged code, just take the hit. It should be justifiable if a Rust implementation of a library is 5-10% slower than its C equivalent. How can choosing to build and deploy unsafe code in today's legal/political/financial environment be defensible? Is it going to take public shaming and frogmarching developers to jail for our industry to…

Depending on what you're doing, it might even be faster, not 5-10% slower. We're currently sometimes faster, sometimes slower, but we should never be slower by a huuuuuge magnitude, though of course, bugs do exist.

I've been excitedly watching this over time; I think in a few years Rust could just be straight-up faster than C the majority of the time, depending.

Re: Glibc getaddrinfo stack-based buffer overflow

#280

Post by ptrincr »

tomputer wrote: post #252
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…

On Debian there is also the tool checkrestart available, it is part of the debian-goodies package. This might be useful if a reboot is (currently) not possible. apt-get install debian-goodies Then you can run: checkrestart And it will list services which require a restart. For example: service sudo restart service ssh restart service cron restart service ... On Debian 8 (Jessie) i had to restart the systemd services…

Thanks for this. Good to know.
Post reply on HN