Live data from Hacker News

Glibc getaddrinfo stack-based buffer overflow

googleonlinesecurity.blogspot.com

51–60 of 480 posts

Re: Glibc getaddrinfo stack-based buffer overflow

#51
post #40

Why don't more distros use the lighter weight C runtimes?

For example, Node.js still has test case failures when running on musl on Alpine Linux:

https://github.com/nodejs/docker-iojs/issues/44#issuecomment...

Most apps will work out of the box, but you can see in that issue 1+ year of various people debugging and fixing issues to just get existing test cases to pass.

Re: Glibc getaddrinfo stack-based buffer overflow

#52
As far as I see the bug primarily lies within this function here... resolv/res_send.c https://github.com/bminor/glibc/blob/master/resolv/res_send....

Lines 952 ... 1389 [=~450 lines of code], with more than a dozen of variables holding random state. Think about the complexity you have with all the conditionals and loops, often copying and pasting similar conditions with (xx1 && xx2) variants.

While discusions about the relative merits of Rust, C, Ocaml, Intercal are fun, with enough dedication you can write unauditable/unreviewable code in any language. Even though you might avoid memory corruption, you still can't prove that such kind of code does anything correct.

Re: Glibc getaddrinfo stack-based buffer overflow

#55
post #22

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…

Written properly, C++ is not unsafe.

Certain language own certain domains, for better or worse, this means that most developers interested in low level programming will know C/C++, and that the will be a substantial amount of tooling already in place.

Re: Glibc getaddrinfo stack-based buffer overflow

#56
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 reasonable), but in that case why wouldn't you use Rust's standard library as the backbone of that system?

Let me put it this way, if the GNU/Linux C standard library gets rewritten in Rust or Idris (sigh... seriously?) I will switch to Windows 10 with default settings for the rest of my life. I would rather have the NSA log my every key stroke than participate in a community where that is considered a good idea.

Re: Glibc getaddrinfo stack-based buffer overflow

#57

Earlier quoted context omitted.

"It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack. Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.

Rust is actually a decent contender in this space. Memory safe and with the performance of C. > I assume he would argue this is a matter of shitty developers, not a shitty language. All developers are shitty.

Rust also has nearly no runtime and no garbage collector. Lack of GC makes it possible to integrate a Rust library into scripting languages etc. This is an easier upgrade path from C, which D, Go, Nim, etc cannot provide.

(For my projects I prefer D, but Rust has a point here)

Re: Glibc getaddrinfo stack-based buffer overflow

#58

[flagged]

EDIT> Also, do you seriously think humans will be programming in 20-50 years? We'll be operating at a higher level and just boiling it down to C/asm anyway. If you want to make a difference, then work on machine programming. If you're inventing a new programming language, then you're fighting yesterday's battle.

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#59

Earlier quoted context omitted.

"It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack. Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.

Rust is actually a decent contender in this space. Memory safe and with the performance of C. > I assume he would argue this is a matter of shitty developers, not a shitty language. All developers are shitty.

[deleted]

Re: Glibc getaddrinfo stack-based buffer overflow

#60

Earlier quoted context omitted.

"It'll be slower than C", they'll say. However, I would gladly sacrifice performance for memory safety, at least in an alternate, opt-in, network stack. Unfortunately, I doubt this will ever happen while Linus is around. He seems to be quite fond of C. I assume he would argue this is a matter of shitty developers, not a shitty language.

Rust is actually a decent contender in this space. Memory safe and with the performance of C. > I assume he would argue this is a matter of shitty developers, not a shitty language. All developers are shitty.

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