top | item 43851075

(no title)

benwilber0 | 10 months ago

> I probably would have gone for turning the UaF into an type confusion style attack

I'm aware that Linux is nearly 40 years old at this point, and C is even decades older. But it is mind-boggling to me that we're still talking about UAFs and jumping from dangling pointers to get privileged executions in the 21st century.

(rewrite it in Rust)

discuss

order

pjmlp|10 months ago

That was obvious to C.A.R Hoare in 1980, should have been obvious to the industry after the Morris worm in 1988, yet here we are, zero improvements to the ISO C standard in regards to prevent exploits in C code.

musicale|10 months ago

Multics (written in PL/I) didn't suffer from buffer overflows. Ada was (and is) memory safe. Pascal had (and still has) range checks and bounded strings.

But we do have -fbounds-safety in clang (at least on macOS).

snarf_br|10 months ago

What's stopping you from doing just that? Looking forward to your linux-rust kernel.

enigma101|10 months ago

Never if anything remove Rust from linux!

Ygg2|10 months ago

Nonsense, the C guy told me those happen to people that make mistakes, and that he, being the offspring of the Elemental of Logic, and "Hyperspace cybernetic intelligence and juvenile delinquent John Carmack" is completely immune to such pathetic issues. He works at Linux. Yes, all of Linux.

uecker|10 months ago

Yes, we need a languages that makes it impossible. But how could this happen in Rust? https://github.com/advisories/GHSA-5gmm-6m36-r7jh But clearly, this does not count because it used "unsafe", so it remains the programmer's fault who made a mistake. Oh wait, doesn't this invalidate your argument?

uecker|10 months ago

The last version of C is ISO C 23. I also do believe that rewriting in Rust is the best way to address memory safety in legacy C code and not even for new projects, nor do I think that memory safety is the most pressing security problem.