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

251–260 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#251

Post by AsyncAwait »

JabavuAdams wrote: post #200
pcwalton wrote: post #187

Earlier quoted context omitted.

> Languages like Ruby have had their host of ridiculous security errors. > Fuck Rust and you naive and self-serving evangelists. Come back to me in 20 years with what you've learned. This might be a cogent criticism (although a pointlessly mean one) if we hadn't started the Rust project with an analysis of precisely what the contents of our security bugs consist of, and designed the project to target those.

Fair enough. Obviously my emotional venting is not the strong part of my argument. I love this safe world where we don't have to fear our neighbours, but I hate this safe world where I can't verbally punch someone in the face. I need blood sport.

> Obviously my emotional venting is not the strong part of my argument.

The fact that you haven't provided any actual, technical reason why "Fuck Rust" is perhaps another part of the puzzle.

Re: Glibc getaddrinfo stack-based buffer overflow

#252

Post by tomputer »

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…

On Debian there is also the tool checkrestart available, it is part of the debian-goodies package. This might be useful if a reboot is (currently) not possible.

  apt-get install debian-goodies
Then you can run:

  checkrestart
And it will list services which require a restart. For example:

  service sudo restart
  service ssh restart
  service cron restart
  service ...
On Debian 8 (Jessie) i had to restart the systemd services as well:

  systemctl daemon-reexec 
  systemctl restart systemd-journald
  systemctl restart systemd-logind

Re: Glibc getaddrinfo stack-based buffer overflow

#253

Post by friendcomputer »

If this was originally filed on an open bug tracker in July 2015, what were the glibc team doing in the mean time? The Google post indicates they were "working on it" when Google got in touch. How much work was going on, exactly? How did this languish for so long?

Re: Glibc getaddrinfo stack-based buffer overflow

#254

Post by dap »

alkonaut wrote: post #249
djsumdog wrote: post #230

Earlier quoted context omitted.

All this "Let's replace everything with Rust" is extremely childish. Be wary of making programming languages a religion. The Java zealots did it, and you can see the results where full Java projects are used in places where a 20 line Python script would have been easier. If you're serious, one of your pet projects should be trying to implement BSD sockets with Rust. Then try compiling some C apps against your impleme…

It doesn't have to be a big rewrite of "everything" to Rust. It would at the very least be a slow successive rewrite whenever a major change is needed. For this particular piece of code one would hope that the fix we'll see now would also include around 100 new lines of comments, splitting of hundred-line functions into a dozen smaller ones etc. I suspect that just by doing that someone would notice another flaw of t…

> It doesn't have to be a big rewrite of "everything" to Rust. It would at the very least be a slow successive rewrite whenever a major change is needed.

That's why the suggestion to implement BSD sockets first is an interesting one. It's a non-trivial interface (which is important to be a useful proof of concept), but it's widely used, relatively well-defined, and could potentially be plugged into applications without replacing other pieces (though that may turn out to be tricky). If it works, you could start implementing more native interfaces that way. If it doesn't, maybe we'll understand better why C remains so dominant for system libraries. (Personally, I don't think it's just inertia or the cost of rewriting all that software, but that's why I'd like to see a project like the one suggested.)

Re: Glibc getaddrinfo stack-based buffer overflow

#255

Post by tomjakubowski »

dbaupp wrote: post #206
SCHiM wrote: post #149

Earlier quoted context omitted.

No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others. Eg. Don't use C++ as C with vectors, use C++ with the more modern language features: It's the difference between: // where f is of type fstream of a file containging "this is a string\r\n"No I think he meant that if you adhere to certain language constructs the language is just as memory safe as R…

> No I think he meant that if you adhere to certain language constructs the language is just as memory safe as Rust/others. It's not; as soon as code uses (for instance) references, you're running the memory-unsafety gantlet. E.g. even something super-modern like for (auto& thing: vector) is risky: what if the loop body happens to somehow call `vector.push_back(x)`?

> is risky: what if the loop body happens to somehow call `vector.push_back(x)`?

Some people like to say that these bugs are trivial to avoid ("who would write code like that?!"), but they miss the insidious (and common) case: when code several layers down the call stack (in some arbitrary callback assigned at runtime, say) grows the vector/map from under you.

Re: Glibc getaddrinfo stack-based buffer overflow

#256

Post by aikah »

ufo wrote: post #88
denim_chicken wrote: post #60

Earlier quoted context omitted.

Rust is not a decent contender. It is far too immature. The only reasonable contender is C++.

C++ is not reasonable if your goal is to avoid memory safety bugs.

> C++ is not reasonable if your goal is to avoid memory safety bugs.

I'll get crucified for saying this but it's easier to write safe code in C++ than C. C requires a perfect discipline very few people can maintain.

Cyclone-lang had good ideas about how to fix C, almost 10 years ago. I wish it has been more successful. i was less "alien" looking than Rust.

Re: Glibc getaddrinfo stack-based buffer overflow

#257

Post by vdfs »

weinzierl wrote: post #123
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…

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

Re: Glibc getaddrinfo stack-based buffer overflow

#258

Post by autoreleasepool »

pcwalton wrote: post #246
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…

> 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 that low level unless they can be enforced at compile time. I'm concerned by some of the magical thinking being espoused in this thread about what's actually reasonable in terms of the trade offs you can make.

In other words I was talking about safety, not speed.

I'm glad to hear Rust is out performing C though. I just wish I had a better IDE than atom... Didn't you once mention Xcode support for Rust?

Re: Glibc getaddrinfo stack-based buffer overflow

#259

Post by stevekemp »

mwcampbell wrote: post #184

The Debian glibc package update that fixes this vulnerability is dated February 11. But the patch wasn't posted on the glibc mailing list until today. So did Debian get the patch even before it was made public upstream? If so, then why didn't Ubuntu get it early as well?

Sufficiently "bad" issues are disclosed to multiple Linux vendors at the same time, via the vendor-sec mailing list. If you're a member of a security team for a distribution this is generally where you hear about issues.

From there coordinated release dates will be agreed, and barring big surprises like one distro pushing out an update too soon everybody _should_ release at the same time.

Sometimes people get sick, take a holiday, or drop the ball for other reasons. I'd expect Ubuntu did get notified, but haven't yet tested/built their fixed packages to push out.

Re: Glibc getaddrinfo stack-based buffer overflow

#260

Post by tomjakubowski »

dbaupp wrote: post #220
autoreleasepool wrote: post #120

Earlier quoted context omitted.

It's still completely pointless. How would mmap be any different if it was implemented in Rust rather than in C? You need unsafe to implement it! The safety mechanisms are practically useless at such a low level. Wrap existing C with safe Rust, not the other way around! We don't rewrite unsafe C code in Unsafe Rust so that it can be called from all the unsafe C code in UNIX. Such a translation is so pointless and err…

> How would mmap be any different if it was implemented in Rust rather than in C? You need unsafe to implement it! The safety mechanisms are practically useless at such a low level. They're definitely not. The power of Rust is not avoiding all `unsafe` ever, but wrapping that unsafe into finite-scope, safe wrappers. Something like mmap would presumably interface with the OS's internal memory management routines, whic…

It seems hard (impossible?) to write a safe, full-featured mmap wrapper in Rust, because of the potential for multiple processes sharing mutable access to the memory and defeating Rust's aliasing checks.

Maybe you could separately map shared RefCells to guard the pages returned by the mmap wrapper? If the region is backed by a file, you'd need to check those RefCells on every IO access too, though.

Post reply on HN