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

321–330 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#321

Post by mikeash »

pjmlp wrote: post #318
mikeash wrote: post #228

Earlier quoted context omitted.

The initial versions were pure assembly. There was no room for any high-level code. As time went on and more storage was available, that became a possibility, but much of the OS remained assembly. This was a big part of why so much of the OS ran under emulation when the PowerPC Macs were introduced.

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 contain Pascal. The early versions were subject to absurd space constraints that required everything to be written in assembly. My understanding is that high level languages started to be used for parts of the OS later on, but it remained predominantly assembly until well after the PowerPC transition.

Re: Glibc getaddrinfo stack-based buffer overflow

#322

Post by marshray »

pjmlp wrote: post #314
marshray wrote: post #291

Earlier quoted context omitted.

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.

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.

Re: Glibc getaddrinfo stack-based buffer overflow

#323

Post by weinzierl »

msbarnett wrote: post #127
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?

Literally the next sentence: > We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.

I read that, I just found the examples strange. Browsers are incredibly important for an incredible number of people while curl is not.

Re: Glibc getaddrinfo stack-based buffer overflow

#326

Post by autoreleasepool »

pjmlp wrote: post #319
autoreleasepool wrote: post #105

Earlier quoted context omitted.

IIRC, that's because it's a C++ library, not a real C library. Aside from a few exceptions, it only includes the parts of the C standard that are required by the C++ standard. Hence the dismal C99 support on that platform.

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.

Re: Glibc getaddrinfo stack-based buffer overflow

#327

Post by kbenson »

autoreleasepool wrote: post #302
nightpool wrote: post #288

Earlier quoted context omitted.

pcwalton is talking about safe rust. Unsafe rust is not really any faster in a lot of cases, and even when it is the goal is to compartmentalize the unsafe code into very small, distinct, easily testable segments.

Again, I'm not talking about performance. I'm talking about low level safety and the difficulties in achieving that in any meaningful way. I wasn't talking about just Rust when I said abstractions cost you speed. It was a (perhaps unclear) general statement about programming. As an aside, unsafe rust is faster than safe rust for a lot of cases. I re-read what I wrote and I fail to see where I attacked or even (God fo…

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

This is more about backing up claims with concrete examples. pcwalton is a Rust developer, I'm sure he would be very happy to hear a specific shortcoming he wasn't aware of, or was undervaluing. That's how improvements are made.

> So far IME, the rust community is extremely defensive and antagonistic to anyone they perceive to have made the slightest criticism. It's immature and irritating. It's the only thing that really turns me off from fully embracing it.

There may be some of that, but I also see a lot of rust community members trying to explain where people's assumptions are wrong, and it being taken as being antagonistic. The fact that Rust has some compile time checking that could actually make some of the low-level code faster is what I think is being alluded to by pcwalton. Of course there will be things that rust won't catch, and will need to be done in both C and rust, and there's things that other languages may catch that rust doesn't and vice-versa.

> I can't participate in a community that's fundamentally hostile to skepticism.

That's an interesting way to put it. You've made assertions, and when asked for clarification or evidence, began your response by calling the other commentor's motives into question (is it a reasoned response, or was it overly emotional because they were "defensive"). Asking for evidence of assertions is skepticism, and to balk in face of requests to do so is actually what I would consider being defensive.

To be absolutely clear, I don't think you would have been downvoted if you didn't start your reply with "A little defensive, maybe?". I didn't downvote you, but my initial assumption was that the downvoting I saw was because of that.

Re: Glibc getaddrinfo stack-based buffer overflow

#328

Post by weinzierl »

thrownaway2424 wrote: post #136
weinzierl wrote: post #121

Can this be used to exploit DNS servers via other rogue DNS servers? What if I setup a rogue DNS and wait for it to be queried by 8.8.8.8. When I own 8.8.8.8 I can exploit every client that queries it. Browsers use getaddrinfo(), don't they?

You think Google's DNS service is based on third-party resolver code?

I'm out of my element here but is it really so far fetched?

A quick search in the PowerDNS codebase [1] reveals four sites where getaddrinfo() is called. This isn't obviously the code for recursive lookups but that doesn't matter. If an attacker can trick it to query their rogue DNS they have won.

I don't want to suggest that Google uses PowerDNS, I just used is as an example.

[1] https://github.com/PowerDNS/pdns/search?utf8=%E2%9C%93&q=get...

Re: Glibc getaddrinfo stack-based buffer overflow

#329

Post by [deleted] »

kbenson wrote: post #327
autoreleasepool wrote: post #302

Earlier quoted context omitted.

Again, I'm not talking about performance. I'm talking about low level safety and the difficulties in achieving that in any meaningful way. I wasn't talking about just Rust when I said abstractions cost you speed. It was a (perhaps unclear) general statement about programming. As an aside, unsafe rust is faster than safe rust for a lot of cases. I re-read what I wrote and I fail to see where I attacked or even (God fo…

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

Re: Glibc getaddrinfo stack-based buffer overflow

#330

Post by TazeTSchnitzel »

avian wrote: post #26
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…

> It is time for the bimonthly Internet security meltdown. Time for the bimonthly Hacker News hour of C and C++ hate.

Which is quite justified, as with more modern programming languages, these sorts of bugs are much less likely to happen.
Post reply on HN