Live data from Hacker News

Glibc getaddrinfo stack-based buffer overflow

googleonlinesecurity.blogspot.com

351–360 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#351

Earlier quoted context omitted.

> 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. That doesn't match my experience. Source? > 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. In effect, you're saying we shouldn't…

> That doesn't match my experience. Source? No source. There's always a price to pay. Rust is zero-cost, but only on a subset of algorithms that are valid in idiomatic Rust. If you translate Rust to C you won't gain on speed, but if you translate C to Rust you might have to reorganize it and that will cost you. If your subset involved mostly increments and decrements of data and address registers then language called…

> If you translate Rust to C you won't gain on speed

Mostly this is the case, but we do give better aliasing info than C in many cases right now, and that can help optimizations. It depends a lot on your use case.

> Correct me if I'm wrong, but I'm led to believe at least some problems that would be most naturally expressed with graph structures will require reference counting when rewritten in safe Rust.

Most people use petgraph nowadays for graphs, which doesn't use RC; instead it uses indices, which are roughly the same cost as individual heap allocations. They have more computation for lookups, but the computation is usually folded into the addressing mode, and you get better cache behavior.

Re: Glibc getaddrinfo stack-based buffer overflow

#352
post #314

Earlier quoted context omitted.

Microsoft C before Visual C++ being popular?! Not on my country, it was all about Borland compilers, even in the Windows 3.x days. Microsoft was even the last vendor to add support for C++ on the last MS-DOS version of Microsoft C, version 7 if I remember correctly.

Yes, Borland "Turbo" C was another massively popular choice. But you can't simultaneously argue that C wasn't used for PC platform development in the 1980's and that Borland C was dominant.

> it was all about Borland compilers

I never said directly I was referring to Borland C, actually it was all about Turbo Basic and Turbo Pascal.

I and a few others did use Turbo C, but we jumped right into Turbo C++ the year thereafter, as we could not envision using plain C after having done systems programming in the other Borland languages.

C was left for programming classes, usually trying to convince the teacher to use C++ instead for projects, sadly it only worked occasionally.

Re: Glibc getaddrinfo stack-based buffer overflow

#353
post #335

Earlier quoted context omitted.

> Again, I'm not talking about performance. But previously you said "because it can't be safe at such a low level without a performance penalty" which clearly implies performance is part of your argument. This is what I was talking about in my other reply, which mentioned "without narrowing the scope or clarifying your intent". > I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticize…

[deleted]

> Notice how you're defending criticisms I never made.

I'm not defending anything, You didn't supply clarification of your point. You were asked for clarification, and provided someone else's experience (anecdotal) counteracting claims (which weren't even anecdotal, they were unsupported assertions), and you started out as classifying that response as defensive.

> notice how you assume I don't know the difference between static analysis and compile-time safety.

I said "I also see a lot of rust community members trying to explain where people's assumptions are wrong" immediately prior to that. I thought it was obvious I was talking in the general sense. I don't know what you do and don't know, but I'm not sure why you think it's valid to be upset because someone assumes this one way or the other (which to be clear, didn't happen here) when you've shown little or no evidence yet as to what you do or don't know about it. It may be the rust community stereotyping others, but without stats as to whether the people the stereotype has been applied to have it applied correctly it's hard to know whether it's useful or harmful, regardless of how it applies to you in particular.

> Notice how you assume that I must be generally uninformed or less intelligent because complete faith in Rust's importance is a self-evident truth.

Not knowing something doesn't make someone less intelligent. If you are conversing under the assumption that everyone will assume you know at least the same amount as them about every topic that is brought up, else you have right to be offended, I'm not sure how we can continue. That's not an environment I want to have a discussion in.

> Well, now that's it's happening to me personally vs just reading it. Fuck this community. It's collectively a socially inept nightmare. I'm done with caring about Rust. I was really enjoying it. After today and Reddit, I can't take anymore of this smug bullshit.

All that's happened here is you made statements and refused to back them up while at the same time you called someone else's motives into question for asking for clarification. I think it's obvious what is going on, but I'm not in your shoes. I don't think people aren't trying to be assholes you you (at least I'm not, or not trying to be one), and while you may be upset, I hope you don't leave for good. however you've interpreted my comments, please be aware that not a single one was written with the intent to upset you, or call into question your character or intelligence in any way. I can only point towards my own experience, here and elsewhere, where my state of mind greatly influenced how I read a statement and any replies to me with regard to that conversation, and think that possibly the same thing is happening here with you. That itself may come across as a smug asshole-ish thing to say depending on how you interpret it, or even my assumption that my observations apply to you. All I can do is state that my desire to be helpful after your prior statement is sincere.

Re: Glibc getaddrinfo stack-based buffer overflow

#354

Earlier quoted context omitted.

Update: It looks like the patch is finally out.

What are you doing to pull this patch? I've apt-get updated and still am seeing Version: 2.19-0ubuntu6.6

Does appear to be out - https://launchpad.net/ubuntu/+source/eglibc/2.19-0ubuntu6.7

apt-get update not seeing it at the moment though, guess its the mirror I'm using.

Edit - working now. I can see:

   Version: 2.19-0ubuntu6.7

Re: Glibc getaddrinfo stack-based buffer overflow

#355
post #318

Earlier quoted context omitted.

Well here there is a bit of different story being told. http://www.folklore.org/ Search for Pascal. Cherry picked from the search results http://www.folklore.org/StoryView.py?project=Macintosh&story... The fact that many C programmers forget, is that it is impossible to implement the C runtime or an OS with pure ANSI C code. Somehow it is ok for C to use Assembly and compiler specific extensions, but not for other sy…

Nothing in that link says that the OS was written in Pascal. Yes, Pascal was a popular language for Mac apps , but of course nothing says that the OS has to be written in the same language used for writing programs that run on it. I don't understand your last comment. I am not saying that the OS doesn't qualify as "written in Pascal" because it contains assembly. I am saying it doesn't qualify because it didn't conta…

Well, I was kind of right and you as well.

It was the Lisa that was written in Pascal.

http://www.folklore.org/StoryView.py?project=Macintosh&story...

Re: Glibc getaddrinfo stack-based buffer overflow

#356

Earlier quoted context omitted.

Thanks.

Latest version I can see from here - https://launchpad.net/ubuntu/trusty/+source/eglibc Is - https://launchpad.net/ubuntu/+source/eglibc/2.19-0ubuntu6.6 apt-get update apt-cache show libc6 *snip* Version: 2.19-0ubuntu6.6 This was released on 2015-02-25

Patch out - https://launchpad.net/ubuntu/+source/eglibc/2.19-0ubuntu6.7

Re: Glibc getaddrinfo stack-based buffer overflow

#357

Looking at that code, which is a tangle of goto statements and buffer allocations and accesses, it's a miracle any of it works in the first place. I bet there are tons more bugs in there.

Tangle of gotos? Those gotos all look reasonable -- they go to return conditions no longer than a few lines. Buffer allocations? They allocate to 2-3 buffers. That's all very reasonable. allocations and gotos aren't the devil in C.

Well, the control flow seems complicated at least.

Re: Glibc getaddrinfo stack-based buffer overflow

#358
post #335

Earlier quoted context omitted.

[deleted]

> Notice how you're defending criticisms I never made. I'm not defending anything, You didn't supply clarification of your point. You were asked for clarification, and provided someone else's experience (anecdotal) counteracting claims (which weren't even anecdotal, they were unsupported assertions), and you started out as classifying that response as defensive. > notice how you assume I don't know the difference bet…

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#359
post #319

Earlier quoted context omitted.

As I mentioned, C is legacy for Microsoft. The way forward for C on Windows from Microsoft own SDK is to use the clang frontend + Visual C++ backend, or another C compiler from someone else.

I definitely support that initiative. The more C++ programmers we can get to stop writing C the better.

Me too.

Yes, C++ is as unsafe as C, given its copy-paste compatibility, but at least it provides the tools to program safely (if one chooses to) and the C++ community cares much more about safety than the C one.

Re: Glibc getaddrinfo stack-based buffer overflow

#360

Has anyone put together a POC that doesn't require re-pointing the system nameserver and crashing other applications?

You can create a small chroot with a custom resolv.conf. Example (tested on Ubuntu 14.04 64-bit): mkdir -p root/lib/x86_64-linux-gnu root/lib64 root/etc cp -a --parents /lib/x86_64-linux-gnu/lib{c,nss,resolv}* root cp /lib64/ld-linux-x86-64.so.2 root/lib64 cp CVE-2015-7547-client root echo 'nameserver 127.0.0.1' > root/etc/resolv.conf sudo chroot root ./CVE-2015-7547-client If it prints nothing it crashed. Try runnin…

Brilliant. Thank you.
Post reply on HN