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

261–270 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#261

Post by acconsta »

steveklabnik wrote: post #221
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…

> it can't be safe at that low level without a performance penalty. Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. Yes, sometimes you still need unsafe, but even then, it's a superset, not a subset: a lot of safety checks still happen inside an unsafe block. That said, I do think that building a libc in Rust would take a significant investment and I'm not sur…

>Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty.

But not bounds checks, which are unfortunately what you need with respect to buffer overflows.

Re: Glibc getaddrinfo stack-based buffer overflow

#262

Post by autoreleasepool »

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…

Practically useless was a bit of a stretch. Unsafe rust is definitely safer than plain C or Assembly. I admit I was a bit riled up after reading the "compile to asm.js" comment.

Cool stuff though, I really hope rust catches fire soon. I love that it has revitalized the appeal of implementing operating system level projects like text editors and shells. I never would have wanted to try and write a windowing system before Rust. Now that's something I'm actively investigating for fun.

Re: Glibc getaddrinfo stack-based buffer overflow

#263

Post by korethr »

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…

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

Re: Glibc getaddrinfo stack-based buffer overflow

#265

Post by kibwen »

efuquen wrote: post #189

Can someone give me technical reasons why this world isn't possible: Parts of the linux kernel or glibc or any other critical C code gets replaced by rust code little parts at a time, which is also calleable from C ( https://doc.rust-lang.org/book/ffi.html )? That way these libraries could be made safer in a controlled and incremental manner. And to reiterate I'm asking for technical limitations, not political or dog…

The biggest technical limitation is that there's currently only one Rust compiler, and it targets LLVM, which means that it can currently compile for only a subset of all platforms that C can compile to.

For some projects this isn't a problem. For example, Firefox is replacing bits of itself little by little with Rust, which is fine because Rust targets all platforms that Firefox is built for (though it did take some wrangling to get Rust working on Windows XP). However, a project like glibc is used across a much greater variety of platforms, and many of those platforms may have nothing but C compilers. And those C compilers may very well be buggy and nonstandard, so even transpiling to C won't help unless you're willing to hand-tweak the generated code.

Re: Glibc getaddrinfo stack-based buffer overflow

#266

Post by dang »

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.

Please stop doing it on HN. We understand the fun of sparring, but on a large, weakly cohesive forum like HN, it causes damage, mostly by provoking others who don't feel the sport. Also the big flamewar discussions are all super generic and thus unsubstantive, and they end up consuming everything more interesting. Just look at what you did to the topic of this thread.

The reason we're so proactive about asking people not to do this isn't that we don't get how stimulating it can be. Rather, it's empirical: experience shows that we can't have both blood sport and a high-quality site in the long run. A high-quality site is more important than blood sport.

Edit: I like the rugby analogy:

https://news.ycombinator.com/item?id=8609481

https://news.ycombinator.com/item?id=11051605

Re: Glibc getaddrinfo stack-based buffer overflow

#267

Post by gue5t »

dbaupp wrote: post #198
gue5t wrote: post #82

Earlier quoted context omitted.

Remote code execution occurs in one of exactly two ways. - eval/exec() of untrusted turing-complete code - memory unsafety There are strange machines and logic vulnerabilities, which as you're aware are pitfalls present in all languages, and can be very subtle. But these are not the same as executing arbitrary operations with all the privileges of the process. This is something we can end today, and Rust would suffic…

Rust code exposing a C ABI (e.g. as a slot-in replacement for an existing C library) behaves like any other upgradable shared library.

Of course, but then you've hamstrung the typesystem that makes Rust safer than C, and generated a lot of work for developers who have to convert all internal types to #[repr(C)] ones at library boundaries. Rust without cross-crate generics is way less fun--you lose "theorems for free", unless you can make guarantees about the pre-ABI translation to/from C types (which would ultimately amount to defining an ABI).

Re: Glibc getaddrinfo stack-based buffer overflow

#268

Post by AsyncAwait »

denim_chicken wrote: post #151
ufo wrote: post #88

Earlier quoted context omitted.

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

Neither is Rust, which comes with a huge RTS that itself likely full of such bugs. The library and the compiler too may have bugs that compromise the "guaranteed" memory safety of a libc written in Rust. There is no silver bullet here. If one takes into account all the sources of bugs, C may very well be the best choice given its maturity and its ecosystem. Our best bet is likely to put more resources towards glibc d…

That doesn't mean sticking with the status-quo is the solution.

Rust certainly looks like a better starting point for modern, safe low-level programming than C. C served us quite well for over 40 years, but perhaps it's time to move on...

Re: Glibc getaddrinfo stack-based buffer overflow

#269

Post by dne »

tomputer wrote: post #252
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…

Also see "needrestart", which automatically offers to do the above when upgraded packages have been installed: https://packages.debian.org/jessie/needrestart

Re: Glibc getaddrinfo stack-based buffer overflow

#270

Post by w8rbt »

mentat wrote: post #179
asveikau wrote: post #132

Earlier quoted context omitted.

Unless you are linking statically (and I don't really understand why you would) you update glibc and that's it. This question had me feeling kind of old. Does nobody learn what shared libraries are anymore?

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.
Post reply on HN