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

381–390 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#381

Post by bcook »

steveklabnik wrote: post #238
autoreleasepool wrote: post #229

Earlier quoted context omitted.

Definitely. The ability to encapsulate code that is less strictly checked by the compiler is what makes Rust such a compelling alternative to C. I definitely think Rust is the ideal choice for a hobby kernel from scratch in 2016. My point is that unsafety is unavoidable. You can encapsulate unsafe Rust or wrap plain old C, it's, for all practical purposes, the same. At that level language features matter a lot less.…

Yeah, absolutely. Ultimately, the machine is not safe. Such is life.

Exactly... and users are even worse.

Re: Glibc getaddrinfo stack-based buffer overflow

#382

Post by alinspired »

shaggy wrote: post #112
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…

Thanks for these. Has anyone seen a link from/for CentOS yes?

centos patch has been released at http://mirror.centos.org/centos/6/updates/ Note: it's likely not propagated to all mirrors yet

Re: Glibc getaddrinfo stack-based buffer overflow

#383

Post by ossreality »

autoreleasepool wrote: post #186
chc4 wrote: post #140

Earlier quoted context omitted.

You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!" Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust. Also, extern "C" is for C FF…

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.

Wow, what a succinct way to let us know you don't know what you're talking about!

Re: Glibc getaddrinfo stack-based buffer overflow

#384

Post by bsder »

TeMPOraL wrote: post #205
voidlogic wrote: post #192

Earlier quoted context omitted.

>Some people don't get it that before it happened we were happily using other systems programming languages way safer than C. Maybe some people, but most systems programming was done is Assembly before C.

No, you're not getting it :). There was a whole world besides Assembly and C, now mostly lost to us. E.g. Lisp machines, which even had hardware support for Lisp-specific things like tagged pointers.

Whose performance was so bad that porting the Lisp Machine software to a general purpose Alpha added multiple factors of performance increase.

Re: Glibc getaddrinfo stack-based buffer overflow

#385

Post by caf »

dalore wrote: post #19
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…

But this is hard for them to 'scan' for. As they need to get vulnerable systems to query their dns server. But it's not hard to get a system to do a dns query. Sometimes even connecting to it will cause your ip to appear in the logs which are then sometimes reversed ip. But one could easily just create a webpage with img.src pointing to the host. DNS being distributed could halt the attack upstream by patching their…

I don't think a reverse query will tickle this bug, because this bug requires simultaneous A and AAAA lookups to be triggered whereas a reverse query uses a single PTR lookup.

Re: Glibc getaddrinfo stack-based buffer overflow

#386

Post by dbaupp »

gue5t wrote: post #267
dbaupp wrote: post #198

Earlier quoted context omitted.

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

You've hamstring the type system at the interface, internally you still get all the benefits. In any case, a typical use-case for a shared library like this is embedded into other applications, which may not be written in Rust at all, and hence things like generics don't work anyway.

In fact, this is reflected in a common way to expose an interface in this manner: have a main Rust interface (i.e. with normal generics etc.), with thin C-compatible shims that do the right set-up (e.g. converting arguments) to call that code.

Also, I'm not exactly sure how you expect arbitrary cross-crate generics to work for a dynamically reloadable library: they're somewhat inherently incompatible (a downstream type can be inserted deeply into a library's code). I vaguely recall inklings of some approach for C++, beyond just explicitly instantiating specific template parameter combinations in the shared library, so if you know more about that, I'd love to here.

Re: Glibc getaddrinfo stack-based buffer overflow

#387

Post by cbd1984 »

tkinom wrote: post #212
ploxiln wrote: post #180

Earlier quoted context omitted.

Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragma…

Agree. "C" to OS, Kernel, Computer Language, applications is like oxygen is to life on earth. Yes, O2 causes fire from time to time, but you can't live without it.

> "C" to OS

There's the solution! Replace C with "C", a garbage-collected version of C! The quotes mean it's safe!

/s

Re: Glibc getaddrinfo stack-based buffer overflow

#388

Post by cbd1984 »

andrewjl wrote: post #210
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…

I'd really like to see a good write up on a project that's trying to tackle this problem on the levels below C. (Assembly or even hardware level.)

The x86 ISA already has bounds-checking opcodes which can be used to ensure array accesses don't go off the deep end.

Re: Glibc getaddrinfo stack-based buffer overflow

#390

Post by dbaupp »

tomjakubowski wrote: post #260
dbaupp wrote: post #220

Earlier quoted context omitted.

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

I was more focusing on implementing the internals of mmap, since that's what I assumed the question was. For that task, the actual memory/pointer returned is essentially a black-box (i.e. it's never read nor written by mmap itself), mmap is just interacting with the operating system.

However, as you say, exposing a safe mmap version for libraries to call is a different problem with different difficulties. eddyb's sibling suggestion of teasing out the multiple entangled uses of mmap sounds like a good one, although someone would have to experiment with it to be sure.

Post reply on HN