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

361–370 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#361

Post by rayvd »

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 feel like this would depend where in the BIND code the size restriction is being enforced.

Sounds promising, however.

Re: Glibc getaddrinfo stack-based buffer overflow

#362

Post by atom_enger »

ptrincr wrote: post #354
atom_enger wrote: post #342

Earlier quoted context omitted.

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

Yep I'm seeing it too. Thanks! Ubuntu just released this:

http://www.ubuntu.com/usn/usn-2900-1/

Re: Glibc getaddrinfo stack-based buffer overflow

#363

Post by Manishearth »

RaleyField wrote: post #337
pcwalton wrote: post #285

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…

> will require reference counting

or use an arena (or backing store of handles, or graph of indices, or ...); which is basically the same situation as doing it in C unsafely with more or less the same cost.

> but only on a subset of algorithms that are valid in idiomatic Rust

IME almost all algorithms can be implemented in safe Rust, just that it takes some work to make it safe (e.g. using an arena, or shuffling some code around). The "limitations" of the borrow checker, for example (where it might be considered overzealous) can always be worked around by twiddling a few lines of code.

If it really comes to that (it shouldn't), you can always make your algorithm work with a few lines of unsafe Rust, and verify that locally. Still better than the entire thing being unsafe.

Regarding the 50% more effort to develop, we've gotten consistent feedback that the effort involved in writing Rust code is not more than any other typed language once you internalize some of its rules (which takes some time, but not too much).

Re: Glibc getaddrinfo stack-based buffer overflow

#365

Post by zebra1287 »

autoreleasepool wrote: post #113
School-Cotton wrote: post #74

Earlier quoted context omitted.

Your post is just a bunch of pathos and doesn't explain why you actually think it's a bad idea. There's no technical reason why the C standard library can't be written in a language other than C. Lots of language libraries are written in languages other than the one they're primarily used with and work fine.

I mean, what problem is this solving? There's no technical reason why it can't be done, true. It's still a hilariously bad idea that would never succeed. That's aside from the fact that's a completely pointless wheel-reinventing endeavor. Rewrites in general are pretty difficult to justify. Sorry, I guess my aggressively pragmatic side is showing today. The idea is really dumb. To be honest, "Let's rewrite the C stan…

It will be finished together with GNU HURD.

Re: Glibc getaddrinfo stack-based buffer overflow

#366

Post by lmm »

JabavuAdams wrote: post #111
lmm wrote: post #101

Earlier quoted context omitted.

> Repeat after me: there is no silver bullet! Nonsense. How many buffer overflows - a vulnerability that simply doesn't happen in any modern language - would it take to convince you that the language is the problem? > Languages like Ruby have had their host of ridiculous security errors. Ruby isn't great, but it's not had anything like the same defect rate as C. > One advantage of legacy code is that it is battle-tes…

Do you think there are fewer currently unknown bugs in software we have yet to re-write, in languages that are currently untested? Don't make me quote Rumsfeld.

I think rewrites would have fewer bugs, yes. Maybe we know the defect rate more precisely for C than for other languages - but when it's this high, I'd sooner go with the unknown.

Re: Glibc getaddrinfo stack-based buffer overflow

#367

Post by lmm »

xorcist wrote: post #190
lmm wrote: post #101

Earlier quoted context omitted.

> Repeat after me: there is no silver bullet! Nonsense. How many buffer overflows - a vulnerability that simply doesn't happen in any modern language - would it take to convince you that the language is the problem? > Languages like Ruby have had their host of ridiculous security errors. Ruby isn't great, but it's not had anything like the same defect rate as C. > One advantage of legacy code is that it is battle-tes…

> 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, but I'm very tired of "the language is the problem". Shoving more layers of abstraction in there is not a silver bullet for security. We need to look more at system programming languages.

It's not about adding abstraction. There are plenty of safe systems programming languages. The problem is specifically C.

Re: Glibc getaddrinfo stack-based buffer overflow

#368

Post by AndyKelley »

alkonaut wrote: post #345
AndyKelley wrote: post #341

Earlier quoted context omitted.

Compare to the musl implementation: http://git.musl-libc.org/cgit/musl/tree/src/network/getaddri...

It's better. The musl version is slightly smaller and tidier but also doesn't handle all the same proticols so it's not a fair comparison. At least it doesn't have a lot of conditional compilation and macros. But the musl code too has bloody ZERO comments for a nearly 100 line long method of dense/opaque C code! Why? Is commenting and splitting code into functions frowned upon in "traditional" systems programming? Wh…

I feel like comments are extremely valuable in API documentation, but not so much in the implementation.

When you're reading an API you want to understand how it works without cracking open the source. When you're looking at an implementation it is your duty to load the source into your comprehension, at which point comments become irrelevant, or worse, misleading.

Re: Glibc getaddrinfo stack-based buffer overflow

#369

Post by muppetman »

w8rbt wrote: post #270
mentat wrote: post #179

Earlier quoted context omitted.

That isn't it, see siblings here. You have to restart all processes that load glibc and interact with the affected services.

Debian does this automatically and alerts the user what services are being restarted.

I updated this morning and nothing got restarted. Shouldn't pretty much every network service I have gotten a restart? sshd, postfix, apache, icecast2, dovecot

None of them restarted. So I restarted them all myself...

Re: Glibc getaddrinfo stack-based buffer overflow

#370

Post by 0x4a42 »

Ono-Sendai wrote: post #357
matthewaveryusa wrote: post #73

Earlier quoted context omitted.

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.

No
Post reply on HN