It can however make it extremely difficult to exploit and it can make such use cases very esoteric (and easier to implement correctly).
A Java program can't write over the return address on the stack.
Could you say why Java is not susceptible to ROP?
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...
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.
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.
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.
There are runtime checks around class structure that ensure that a field load cannot actually read some unexpected portion of memory.
There are runtime checks that ensure that you cannot read through a field on a deallocated object, even when using weakreference and therefore triggering a GC even while the program has access to that field.
There are runtime checks around array reads that ensure that you cannot access memory outside of the allocated bounds of the array.
I have no idea why "susceptible to something like ROP" is especially relevant here. ROP is not the same as "writing over the return address" ROP is a technique you use to get around non-executable data sections and happens after you abuse some memory safety error to write over the return address (or otherwise control a jump). It means "constructing an exploit via repeated jumps to already existing code rather than jumping into code written by the attacker".
But just for the record, Java does have security monitoring of the call stack that can ensure that you cannot return to a function that isn't on the call stack so even if you could change the return target the runtime can still detect this.