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

291–300 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#291

Post by marshray »

pjmlp wrote: post #219
mikeash wrote: post #164

Earlier quoted context omitted.

I wouldn't say that UNIX workstations became truly popular until after Mac OS X took off sometime in the 2000s. C and C++ were enormously popular in the 90s, if not earlier. They were really common for Mac and Windows programming, and I don't think that had anything to do with the UNIX connection.

I was there. The only reason to get a C compiler for CP/M, MS-DOS or Amiga was to be able to bring work home from those expensive workstations at work or university.

I was there too. C was a common language for developing from-scratch DOS applications in the 1980's. Sometimes portability was a consideration, often not. Mark Williams and Microsoft C were two popular compilers.

Re: Glibc getaddrinfo stack-based buffer overflow

#292

Post by autoreleasepool »

nothrabannosir wrote: post #282
autoreleasepool wrote: post #186

Earlier quoted context omitted.

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…

> ...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. A bit higher up: It was clear when Hoare stated on his speech in 1980: "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they al…

A sample size of one makes for a worse rule of thumb then a trend based on hard reality.

Speed is all that matters, I actually learned that from Graydon's blog:

http://graydon2.dreamwidth.org/233585.html#cutid1

Rust sacrificed the majority of its runtime and adopted C's memory model late in development so people wouldn't have to pay a performance cost or depend on confusing heap allocation semantics. That's why it has a really good chance at disrupting the embedded space.

Re: Glibc getaddrinfo stack-based buffer overflow

#293

Post by pcwalton »

PuercoPop wrote: post #284
JabavuAdams wrote: post #41

[flagged]

I agree with the general sentiment: "There are no silver bullets, only tradeoffs." However I disagree that that is the issue at hand. At the very least the trade off is on the wrong side of the equation, it is computers that should do stuff like bound checking not humans. P.D. It irks me that Rust slogan is 'zero cost' abstraction. There is definitely a cost. The memory model is more complex than C. One shouldn't try…

Well, the term "zero cost" is just borrowed from C++, where it means exactly the same thing: more expressiveness, more features, and a higher learning curve with no runtime performance cost. But I do agree with you that there is a learning curve, and some things that are more easily expressible in C are not as easily expressible in Rust (and vice versa). It's undeniable that writing a doubly linked list from scratch in Rust is more involved than doing the same in C (which is a tradeoff I'm glad we made, but like all tradeoffs it has a downside).

Re: Glibc getaddrinfo stack-based buffer overflow

#294

Post by kbenson »

autoreleasepool wrote: post #258
pcwalton wrote: post #246

Earlier quoted context omitted.

> 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. I do a lot of low-level Rust programming and a lot of low-level C programming. I don't know what the performance penalty you're claiming exists comes from. Can you elaborat…

A little defensive, maybe? I never claimed Rust was slower than C or that it had a performance penalty (because you should use unsafe). Actually, I pretty much said the opposite. I said they were the same. I was trying to highlight the fact that unsafe Rust and C are not that different when you're doing bitwise operations on bare metal. I was wanted to drive the point that additional abstractions are undesirable at t…

It's not defensive to ask for evidence of a claim. If your statements are too general to be backed up without narrowing the scope or clarifying your intent, it's hardly the other person's fault for requesting clarification or evidence.

Re: Glibc getaddrinfo stack-based buffer overflow

#295

Post by ptrincr »

korethr wrote: post #263
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…

Gentoo https://bugs.gentoo.org/show_bug.cgi?id=CVE-2015-7547

Thanks! Can't edit the original post now, else I would throw it in there and credit you.

Re: Glibc getaddrinfo stack-based buffer overflow

#297

Post by jblow »

colanderman wrote: post #218
jblow wrote: post #66

Earlier quoted context omitted.

There absolutely are some silver bullets. ALL of these buffer overflows in C happen because the C stack grows backward, and old space is after new space. If anyone have enough of a crap just to standardize a calling convention that went the other way, stack buffer overwrites would ALWAYS go into unused memory. Then security-minded people would switch to this calling convention for secure programs, and many problems w…

Um, what? char too_small_buffer[256]; function_that_expects_a_big_buffer(too_small_buffer); There's even a paragraph on Wikipedia debunking this idea: https://en.wikipedia.org/wiki/Stack_buffer_overflow#Stacks_t...

Wikipedia is wrong. It is not naive.

Yes, this does not solve every possible stack overwrite. But look at the number that have actually happened in the field and whether this would have dramatically reduced vulnerability in those actual real-world cases. Most times it would.

Most notably, for overwrites happening within the local stack frame, you completely remove the possibility of overwriting the return address. This is a fundamental difference in the level of vulnerability of that kind of code.

It's called "reducing the attack surface". Well-known idea.

Maybe my post was a bit hyperbolic, but I chalk that up to being so annoyed at this.

Re: Glibc getaddrinfo stack-based buffer overflow

#298

Post by muraiki »

vdfs wrote: post #257
weinzierl wrote: post #123

Earlier quoted context omitted.

> The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. Why are browsers missing in the list? Don't they use getaddrinfo() as well?

I tried the exploit server, Firefox crashed right after changing the DNS name server.

That is not awesome :(

Re: Glibc getaddrinfo stack-based buffer overflow

#299

Post by jvehent »

iptables -t filter -A INPUT -p udp --sport 53 -m connbytes --connbytes 512 --connbytes-dir reply --connbytes-mode bytes -j DROP

iptables -t filter -A INPUT -p tcp --sport 53 -m connbytes --connbytes 512 --connbytes-dir reply --connbytes-mode bytes -j DROP

Re: Glibc getaddrinfo stack-based buffer overflow

#300

Post by jblow »

JabavuAdams wrote: post #124
jblow wrote: post #66

Earlier quoted context omitted.

There absolutely are some silver bullets. ALL of these buffer overflows in C happen because the C stack grows backward, and old space is after new space. If anyone have enough of a crap just to standardize a calling convention that went the other way, stack buffer overwrites would ALWAYS go into unused memory. Then security-minded people would switch to this calling convention for secure programs, and many problems w…

Hey jblow. I have a tremendous amount of respect for your work, and advocacy. Thanks. Something that I've been wondering -- isn't inventing a new language for game developers fighting yesterday's battle? I've been blown away looking at what Google is doing with C++ indexing, LLVM integration, etc. I'm experimenting with model-based programming. I.e. toying with the idea that I'm not allowed to write any C++ code, onl…

If it were "yesterday's battle", I would have a good programming language to use in my domain, without having to make one. But I don't.

Experimenting with model-based programming or whatever other future programming paradigm is healthy. I think we should do a lot of that, because the way we program hundreds of years from now hopefully doesn't look that much like today. BUT, you have to also be aware that there's a reason why these are future paradigms and not current paradigms, and that people building real programs today need to do something that works today. There is no way we could have built The Witness in any model-based system known today.

Post reply on HN