Hacker News new | past | comments | ask | show | jobs | submit login

Integer overflow bug causing manual memory allocation bug leading to RCE. All too common. We need to stop relying on software written in unsafe languages.



It is about safe and unsafe implementations rather than safe and unsafe languages.


This specific type of vulnerability and the tens of thousands of similar ones like it would absolutely have been prevented by a safe programming language.


This specific type of vulnerability would not be an issue in a safe C implementation for example, just like it would be an issue in an unsafe rust implementation.


There have been research projects that have attempted to make a standards compliant "safe C" a number of different times. You either end up with a 3x execution time overhead, only support a subset, or break programs that do unsafe type punning. As a result, this is not viable.


"safe C" and "unsafe Rust" sound like variant languages to me.


How is "safe C" a variant language when it is within what the standard allows?


The unsafeness of C is pretty widespread and fundamental. Whatever code you end up with is either going to be incompatible with normal compilers, or it's going to be so full of library calls that you can barely recognize it as C anymore.

Unless you count sandboxing the entire program, and allowing errors inside the sandbox as long as they don't escape. Then C-to-WASM would be a safe C compiler, I guess.


> Whatever code you end up with is either going to be incompatible with normal compilers

I do not believe that this is necessarily the case.


Can we name any programmers who are actually capable of a safe implementation using an unsafe language? DJB failed, Knuth's code has bugs, how can I expect you or I to succeed?


That's a good point, but on the other hand, who wrote the languages? Is it possible for a human to write a language which another human can use and create no bugs?

In either case - unsafe language and safe implementation, safe language and unsafe implementation - there is the possibility for bugs, and definitely security ones. Just because you can't cause integer overflow doesn't mean you can't exfiltrate petabytes of data.

I think the major security consideration should be a comprehensive review of the entire system. Regardless of the language or implementation, a regular architectural and non-functional review of all the components in a systematic way is going to provide more security gains than any other single thing. Maybe we should be focusing less on the tools we use and more on improving that workflow.


I am not talking about safe implementations of programs but rather safe implementations of languages. A (kind of bad example because it does not catch everything) is the address sanitiser that clang and gcc have.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: