On: Microsoft is creating a new Rust-based programming...

[zozbot234]

> Need to keep old insecure code around

That's what process boundaries are for. (As a bonus, you get protection from any Spectre-like issues arising in the old code.)

[saagarjha → zozbot234]

Not everything can be neatly refactored out of a process.

[pjmlp → zozbot234]

Process boundaries don't protect against internal exploits, which is what most of the C and C++ exploits are all about.

If you are able to force a process to change its behaviour, the process boundaries become useless.

[saagarjha → pjmlp]

Process boundaries specifically protect against these exploits.

[pjmlp → saagarjha]

So how does a process boundary protect against Heartbleed?

[saagarjha → pjmlp]

Process boundaries help you when you start jumping through a ROP chain that spawns a shell because your process doesn't have access to things that it shouldn't, even when compromised. Calling Heartbleed an example of a process "changing its behavior" doesn't really make sense in the context of exploits that can cause arbitrary code execution.

[dx87 → saagarjha]

You don't have to spawn a shell as a seperate process. Injecting and executing code inside a vulnerable process has been done for a long time.

[saagarjha → dx87]

A shell spawned in an unprivileged process is not very useful.

[pjmlp → saagarjha]

One doesn't need to spawn a shell.

[iCodeSometime → pjmlp]

Injecting and executing code inside an unprivileged process is not very useful.

[pjmlp → iCodeSometime]

Some black hats would consider stealing data, data corruption or triggering DOS already very useful for ransonware.

[pjmlp → saagarjha]

So each one gives an example that suits their own sales pitch.