← Back to context

Comment by UncleMeat

4 years ago

That's totally untrue, unless you are using a really weird definition of "memory safety". A rust program that doesn't make use of the unsafe keyword will not have memory safety bugs. We've had programming languages for decades that are able to happily process arbitrary bytestreams with incredibly buggy code without ever actually writing to a memory region not reachable through pointers allocated by the ordinary program execution.

A Java program can't write over the return address on the stack.

7 comments

UncleMeat

Reply
scoutt  4 years ago

> A rust program that doesn't make use of the unsafe keyword will not have memory safety bugs

https://www.cvedetails.com/vulnerability-list/vendor_id-1902...

What if the bug is in std?

What if I use a bugged Vec::from_iter?

What if I use the bugged zip implementation from std?

You'll probably blame unsafe functions, but those unsafe functions were in std, written by the people who know Rust better than anyone.

Imagine what you and me could do writing unsafe.

Imagine trusting a 3rd party library...

  • UncleMeat  4 years ago

    Sure, and the JVM can contain an exploitable buffer overrun.

    We are on a thread about "a case against security nihilism".

    1. Not all vulnerabilities are memory safety vulnerabilities. The idea that adopting memory safe languages will prevent all vulns is not only a strawman, but empirically incorrect since we've had memory safe languages for many decades.

    2. It is the case that a tremendously large number of vulns are caused by memory safety errors and that transitioning away from memory-unsafe languages will be a large win for industry safety. 'unsafe' is a limitation of Rust, but compared to the monstrous gaping maw of eldritch horror that is C and C++, it is small potatoes.

    3. You are going to struggle to write real programs without ever using third party code.

  • cute_boi  4 years ago

    Then same logic applies for python, java too? What if there is bug in internal implementation?

    Rust Lang strives for safety and safety is no 1 priority. Regarding the unsafe in std please read the source code just to know how much careful they are with the implementation. They only use unsafe for performance and even with unsafe rust, it doesn't provide too much freedom tbh.

    The 3rd party thing you are referring etc sounds childish. They are not the rust lang fault tbh. If you don't trust them don't use. It is as simple as that.

    So I think telling people rust program that doesn't have unsafe will not have memory safety bugs. Exceptions to this statement do occurs but are rare.

bogomipz  4 years ago

>"A Java program can't write over the return address on the stack."

Could you say why Java is not susceptible to ROP?

  • UncleMeat  4 years ago

    ROP isn't the vulnerability, but instead the exploitation technique. "Memory safety errors" were around for decades before ROP was widely understood.

    A Java program, by construction, cannot write to memory regions not allocated on the stack or pointed to by a field of an object constructed with "new". Runtime checks prevent ordinary sorts of problems and a careful memory model prevents fun with concurrency errors. There are interesting attacks against the Java Security Manager - but this is independent of memory safety.