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

451–460 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#451

Post by sveiss »

tasqa wrote: post #38

Looking for a quick mitigation technique before patches start rolling out... Would it be wise to limit responses to 512 bytes so the payload cannot be loaded? Configuring BIND to use a specific buffer size (only for BIND 9.3.2 and newer): Add the following line to the "options" section of your named.conf file: edns-udp-size: n Configuring Unbound to use a specific buffer size: Add the following line to the "server" s…

I haven't tested it, but I'd expect not. Given a limited EDNS0 buffer size, UDP responses would either come back with a truncated flag or not at all. Either case would trigger a TCP retry, and the bug can be triggered that way.

Re: Glibc getaddrinfo stack-based buffer overflow

#452

Post by 102030485868 »

kimundi wrote: post #430
102030485868 wrote: post #47

Earlier quoted context omitted.

I'm not sure how likely that'll be. It's definitely possible, but I think there are going to be a few hurdles. The main one being, symbol versioning. This is important if you export multiple symbols for a function, that is, have a program that depends on a specific implementation of a function. That could mean you depend on different versions of the same library ("functionname@@VERSION_1, functionname@@VERSION_2"), o…

The default name mangling of Rust library symbols is already kinda versioned because it includes a hash of the library, so two different versions of a library can coexist at the same time. As far explicitly using the symbol versioning scheme you mentioned, you can do it with an attribute today: https://play.rust-lang.org/?gist=92be155702d53c6411b2&versio... (Disclaimer: I haven't actually compiled this as a dynamic l…

Woah, I didn't know that is a thing. Thank you!

It seems as if symbol versioning in Rust is nicer than in C. I'll have to play around with that a little bit.

I'm hoping I never to have to deal with writing version scripts or inline assembly again -- or at least having to write less.

Re: Glibc getaddrinfo stack-based buffer overflow

#453

Post by kbenson »

autoreleasepool wrote: post #422
kbenson wrote: post #327

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…

I re-read this and I see where I went wrong. I thought I had made a general statement about the cost of memory safety abstractions in programming languages that was misinterpreted as a specific statement about Rust and safety in general. This was because I was not clear in my phrasing. I guess I felt I was being attacked for a point that I wasn't even trying to make. That is, I was responding to you under the impress…

Thanks, and sorry if the way I worded any replies contributed to that in any way, it wasn't my intention. I hope you have a good day too. :)

Re: Glibc getaddrinfo stack-based buffer overflow

#454

Post by _0w8t »

gpderetta wrote: post #433
_0w8t wrote: post #118

Earlier quoted context omitted.

The problem is not C as one can compile C into NaCl or asm.js and get memory safe code. One can also use a number of static checkers. The real problem is that even this is not done in cases when using C is a must due to project nature.

Compiling to NaCl or asm.js doesn't make an arbitrary C program memory safe. It "merely" prevents any memory safety failure to affect anything outside the container. This is different from, for example, java bytecode which is verified and guaranteed to be memory safe. This is not a mere technicality: an heartbleed vulnerable version of openssl compiled on top of asm.js or NaCl would still leak secret information. edi…

Both asm.js and NaCl guarantee execution stack integrity and allow jumps only at predefined targets in code making exploiting bugs like this highly problematic. Data-only exploits are hard and in asm.js case they are father limited as access outside of the memory leads to program termination.

On the other hand memory safety does not prevent bugs like Heartbleed or resent OpenSSH key leak. As the underling issue is related to broken reuse of a cached buffer, such code can be written in Java or even Rust just as well.

Re: Glibc getaddrinfo stack-based buffer overflow

#455

Post by AndyMcConachie »

sveiss wrote: post #447
AndyMcConachie wrote: post #443

I have a question that hopefully someone can clear up for me. If I understand the Google sec article correctly, this requires a single packet > 2048 bytes to be received by a host using glibc. > The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Is my understanding correct? If it is, then it's worth pointing out that many li…

Datagrams larger than the MTU can be sent, they'll just be fragmented. The point of PMTU is to avoid fragmentation where necessary, but it's still possible.

Sometimes datagrams larger than 1500 bytes can be sent, sometimes they won't reach their destination. Fragmentation doesn't really work, and at the very least will almost always ensure out-of-order delivery. Either way you can't depend on it.

PMTUD doesn't work at all on the modern Internet, not for IPv4, and not for IPv6. So again, I'm just wondering how dangerous this exploit really is. I'm not saying it isn't dangerous, I'm saying our understanding of it should be tempered somewhat due to many links not fragmenting properly that have MTUs of 1500 bytes.

Re: Glibc getaddrinfo stack-based buffer overflow

#456

Post by xorcist »

lmm wrote: post #367
xorcist wrote: post #190

Earlier quoted context omitted.

> the language is the problem It was literally weeks after Heartbleed. The screams for modern languages with managed runtimes had barely subsided. Then Tomcat, in common use world wide in the poster boy managed language, had a bug with exactly the same impact. Nobody abandoned Java after that. Just as nobody will abandon C because of this. > Ruby isn't great, but it's not had anything like the same defect rate I woul…

> It was literally weeks after Heartbleed. The screams for modern languages with managed runtimes had barely subsided. Then Tomcat, in common use world wide in the poster boy managed language, had a bug with exactly the same impact. You're talking about POODLE? Not remotely the same impact. It was a severe vulnerability, but it only leaked plaintext, not key material. > I like modern languages as much as the next guy…

> You're talking about POODLE?

Why would I? That wasn't Tomcat, and it didn't leak keys.

I won't read through the CVE list right now (because it is long, and that's only counting Tomcat and not the JRE itself), but it reused buffers and leaked potentially anything, very much like Heartbleed. If you were in a Java shop at the time you know about it.

> It's not about adding abstraction. There are plenty of safe systems programming languages.

No true Scotsman, eh?

Most people who go about how the world would be saved if we just got rid of C are provably wrong, because popular application in their pet language are just as bad. It used to be Java fanboys, that's why I mentioned Tomcat. Then it was Ruby (and don't get me started on the security disasters Rails brought with it). Most of these do indeed pile abstractions on popular data structures to minimize the possible errors. There are promising languages, but none in popular use, and very far from something you could audit.

Re: Glibc getaddrinfo stack-based buffer overflow

#457

Post by J_Darnley »

GregBuchholz wrote: post #450
J_Darnley wrote: post #276

Earlier quoted context omitted.

> 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 thing…

>I want a region of memory in which I can treat as a bitmap... ...Show me your malloc equivalent and see if I can go from there. http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_a... https://wiki.haskell.org/Numeric_Haskell:_A_Vector_Tutorial#...

Thank you.

Re: Glibc getaddrinfo stack-based buffer overflow

#458

Post by mark-wagner »

pferde wrote: post #435
korethr wrote: post #263

Earlier quoted context omitted.

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

Do I understand it correctly that Gentoo does not plan to push out a fix for this sooner than in 30 days?

No, they were talking about marking glibc-2.22 as stable i.e., removing the tilde from the arches in the KEYWORDS of the ebuild.

glibc-2.22-r2 was released at the same time as glibc-2.21-r2 and it contains the fix for this issue. The Changelog merely says "misc upstream fixes" but I verified the relevant changes are there.

The GLSA is https://security.gentoo.org/glsa/201602-02

Re: Glibc getaddrinfo stack-based buffer overflow

#459

Post by JdeBP »

weinzierl wrote: post #331
inopinatus wrote: post #234

Earlier quoted context omitted.

No. Recursive resolvers do not use getaddrinfo(3) to resolve DNS queries.

That was what I was thinking but it was stupid idea. My point is that if you could use this bug to use one rogue DNS to own other DNSes this could be leveraged to bring large parts of the Internet down. I don't know how hard or easy this could be. A quick glance into PDNS reveals four calls to getaddrinfo()[1]. So it might be possible... [1] https://github.com/PowerDNS/pdns/search?utf8=%E2%9C%93&q=get...

Out of those four calls:

One uses AI_NUMERICHOST and thus doesn't do any DNS client activity. A second isn't supplied arbitrary domain names as input, they being the ones configured for the location of a specific back-end data source by the server administrator. The third is used only inside a "zone transfer" subsystem and again isn't supplied arbitrary domain names as input, the domain names again being in local data specified by the server administrator.

And the fourth is not even part of the executable program, the code being disabled with #if 0 .

The "S" in "DNS" stands for "system", not "server", by the way. A rogue DNS server would "own" other DNS servers.

Re: Glibc getaddrinfo stack-based buffer overflow

#460

Post by kimundi »

102030485868 wrote: post #452
kimundi wrote: post #430

Earlier quoted context omitted.

The default name mangling of Rust library symbols is already kinda versioned because it includes a hash of the library, so two different versions of a library can coexist at the same time. As far explicitly using the symbol versioning scheme you mentioned, you can do it with an attribute today: https://play.rust-lang.org/?gist=92be155702d53c6411b2&versio... (Disclaimer: I haven't actually compiled this as a dynamic l…

Woah, I didn't know that is a thing. Thank you! It seems as if symbol versioning in Rust is nicer than in C. I'll have to play around with that a little bit. I'm hoping I never to have to deal with writing version scripts or inline assembly again -- or at least having to write less.

Note that I'm not really familiar enough with versioned symbols to know whether there is much more to it than just a specially formatted name.
Post reply on HN