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

71–80 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#71

Post by gpderetta »

jblow wrote: post #66
JabavuAdams wrote: post #41

[flagged]

There absolutely are some silver bullets. ALL of these buffer overflows in C happen because the C stack grows backward, and old space is after new space. If anyone have enough of a crap just to standardize a calling convention that went the other way, stack buffer overwrites would ALWAYS go into unused memory. Then security-minded people would switch to this calling convention for secure programs, and many problems w…

C stack doesn't grow on any specific directions. On some ABIs it grows down, on others it grows up. Both are vulnerable to stack overflow attacks.

edit: typo

Re: Glibc getaddrinfo stack-based buffer overflow

#72

Post by pjmlp »

[deleted] wrote: post #62
avian wrote: post #26

Earlier quoted context omitted.

> It is time for the bimonthly Internet security meltdown. Time for the bimonthly Hacker News hour of C and C++ hate.

[deleted]

Yes, UNIX was adopted by the corporations and brought C with it.

Some people don't get it that before it happened we were happily using other systems programming languages way safer than C.

Re: Glibc getaddrinfo stack-based buffer overflow

#73

Post by matthewaveryusa »

Ono-Sendai wrote: post #53

Looking at that code, which is a tangle of goto statements and buffer allocations and accesses, it's a miracle any of it works in the first place. I bet there are tons more bugs in there.

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.

Re: Glibc getaddrinfo stack-based buffer overflow

#74

Post by School-Cotton »

autoreleasepool wrote: post #56
rtpg wrote: post #18

Are there any big efforts to rewrite glibc in something like rust? ... Is that a thing that is even possible? An in-place replacement library for dynamic or static linking. I'm really worried that I still hear about buffer overflows in this day and age. Of all the libraries in the world, glibc should probably be written in some subset of Idris that compiles into 100% safe C. We have the technology to move to this now

I'm not trying to be rude, but I'm sorry... Are you seriously suggesting that rewriting an implementation of the C standard library in a language that isn't C is something that makes any bit of sense? I think you have a fundemental understanding of the roll the C-standard library plays in the C language. Not to mention UNIX in general. Maybe you're suggesting we need an OS based in Rust instead of C (which is more re…

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.

Re: Glibc getaddrinfo stack-based buffer overflow

#75

Post by LinuxBender »

gtirloni wrote: post #67
LinuxBender wrote: post #50

Has anyone actually tried the PoC on their systems? I will test on CentOS 6 and 7 after I have had my coffee. Anyone willing to volunteer to test on Ubuntu and Debian? Here is CentOS 7 [ 389.064412] do_general_protection: 159 callbacks suppressed [ 389.064416] traps: CVE-2015-7547-c[1161] general rotection ip:7fa6b0d8fd67 sp:7ffdaf034a30 error:0 in libresolv-2.17.so[7fa6b0d87000+16000]

https://access.redhat.com/security/cve/cve-2015-7547

Thanks @gtirloni

Re: Glibc getaddrinfo stack-based buffer overflow

#77

Post by School-Cotton »

zzzcpan wrote: post #21
oakhaven wrote: post #17

Is getaddrinfo usually statically linked or dynamically linked to stuff? Which pkgs on Ubuntu will be necessary to upgrade once they roll the fix to the repos?

This is one of those things that usually cannot be linked statically at all. So, not many things to upgrade.

Why can't it be linked statically?

Re: Glibc getaddrinfo stack-based buffer overflow

#78

Post by tosseraccount »

sargun wrote: post #22
Munksgaard wrote: post #2

Can we agree that it's urgently necessary to rewrite most of the core Linux/OSS stack in memory safe languages? Exploits like this come up all the time, and we know how to completely eliminate them. I don't care if it's Rust or D or Go or Haskell or OCaml or anything else, as long as it's not C. The sooner we do this, the better.

I'm still unsure why people start projects with C, or C++ (or other unsafe languages), that do not need it. I totally understand that there are use cases where C++ and C make sense. In my mind, these use cases are quite limited though - integration into 3rd party libraries, legacy codebases, and working in embedded environments. I also agree that performance can be a reason, but see Knuth's opinion on premature optim…

Because you can't release a single file statically compiled native binary that relies only on established system calls. People typically can't install packages anymore. They can grab an exe.

Re: Glibc getaddrinfo stack-based buffer overflow

#79

Post by IgorPartola »

pjmlp wrote: post #64
IgorPartola wrote: post #42

Earlier quoted context omitted.

> Java FTW on Android This made me smile. Need I point out that Android runs on top of Linux? Or that you can still use C/C++ on Android? http://developer.android.com/tools/sdk/ndk/index.html

Yes and I use it. I also feel the pains that Android teams imposes on the NDK users to use it as little as possible. If you bothered to read the contents of the link that you pushed. "Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity. In general, you should only use the NDK if it is essential to your app—never because yo…

Nonetheless, it's something that is available to you as a developer. I am firmly in the "right tool for the job" camp, and I can see situations where C is the better tool. I don't see why mobile app development would benefit from it, but I almost never have the opportunity to work with Android.

I have never attempted to put together a full libc in ANSI C, no. My experience there is limited to putting together parts of it for various microcontrollers, where I was more or less bound to ANSI C and chose to use no assembly.

That's a long way of saying, what's your point? And why do you feel the need to get personal?

Re: Glibc getaddrinfo stack-based buffer overflow

#80

Post by cmrx64 »

pjmlp wrote: post #72
[deleted] wrote: post #62

Earlier quoted context omitted.

[deleted]

Yes, UNIX was adopted by the corporations and brought C with it. Some people don't get it that before it happened we were happily using other systems programming languages way safer than C.

(For the record, grandparent originally ended with "Some people just don't get it")
Post reply on HN