391–400 of 480 posts
Earlier quoted context omitted.
>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.
Yes, absolutely.
[1]: http://doc.rust-lang.org/std/primitive.slice.html#method.get...
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.
> Can we agree that it's urgently necessary to rewrite most of the core Linux/OSS stack in memory safe languages? Why do "we" have to agree? If somebody really believes this is necessary, why don't they just do it?
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.
[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…
This isn't true, as pointed out elsewhere in the thread. In fact, it even looks likely that this specific bug is still exploitable under your proposal.
Here is the bug: https://github.com/lattera/glibc/blob/a2f34833b1042d5d8eeb26...
The buffer overflow occurs here: https://github.com/lattera/glibc/blob/a2f34833b1042d5d8eeb26...
Notice that the buffer overflow occurs not in __libc_res_nquery itself but in one of the functions it calls, send_dg. From a quick glance it looks like the call chain is __libc_res_nquery -> __libc_res_nsend -> send_dg.
Because the buffer is alloca'd in __libc_res_nquery but overwritten in a later call frame, an attacker should be able to overwrite either the return address of send_dg or __libc_res_nsend even if stacks grow the other way. So your proposed fix doesn't address this issue.
Earlier quoted context omitted.
> Thinking a bit more long term, it's pretty clear at this point that we need to expunge all C language networking code from the world, replacing it with Rust or pretty much anything else. That's not sufficient by itself, but it is necessary, or else the periodic Internet security meltdowns won't ever stop. It was already clear in 1961 when Burroughs used Algol and C wasn't even born. It was clear when Hoare stated o…
I think the other thing that changed is that branch predictors are roughly infinitely times better than they were in 1980. The is-this-subscript-ok check should be easily predictable and I wonder if these checks even cost anything in a hot loop on a modern CPU.
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.
> Can we agree that it's urgently necessary to rewrite most of the core Linux/OSS stack in memory safe languages? Why do "we" have to agree? If somebody really believes this is necessary, why don't they just do it?
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…
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…
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 t…
Thank you for sharing that. It's really nothing to do with C, I agree. Just a drastic lack of coding standards. Don't people refactor key code after functionality is proven and tests developed?!
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…
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…
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.