> Web engines are full of security vulnerabilities, like buffer overflows, null pointer dereferences, and use-after-frees.
Off-topic to the issue at hand, but I am curious: would Servo[1], the browser engine written in Rust be having lesser (chances of) issues like this? I have written very little Rust, but it seems that the above issues are extremely unlikely to occur with Rust.
Well, chances are that Servo will have much fewer bugs than today's browser engines. The approach of Servo and Rust is to design in a way that certain classes of bugs are eliminated by default. Only time will tell how good this will work, but I'm hopeful.
That would mean you have a smaller problem. Fewer vulns, fewer reasons to have security updates.
But it's unlikely that Servo will have no vulns at all. There are classes of bugs (e.g. logic vulns) that are unlikely to have any "generic" strategy to beat them. So you still need a working process to deliver security fixes to the user.
Servo also uses the SpiderMonkey engine for Javascript, which is written in C++, although also is hopefully battle-tested enough that there aren't too many bugs in it.
No software is bug-free. The problem here is distribution. If clients were using Servo instead of WebKit, they'd still be stuck on old insecure and/or buggy versions.
Very true. However, the number of remote code execution vulnerabilities resulting from memory safety problems would be lower. This matters because these comprise the vast majority of vulnerabilities on the list.
Never underestimate what misguided cleverness can do. Heartbleed, the most famous of these issues in the last few years, would have not occurred on systems like OpenBSD, were it not for its developers' quest for optimization in their malloc wrapper.
I've seen buffer overflows in Java, too. It's immune to writing past the end of the arrays, but it's not immune to, say, smart programmers using one large array to hold multiple buffers that they manually manage, because who knows when the GC kicks in and wrecks havoc. Python may be immune to use-after-frees, but the OpenGL bindings that it calls through the FFI aren't.
To err is human, and languages like Rust don't make it less likely to err, they just give you new opportunities to do it.
Moving to a safe language like Rust would help, absolutely, but to a far lesser degree than people hope. It would close far fewer cans of worms than the hive mind hopes, and it's so new no one really knows how big its own can of worms is.
> To err is human, and languages like Rust don't make it less likely to err, they just give you new opportunities to do it.
That's completely false as stated. Memory safety vulnerabilities are far, far less common in Python (say) than Java. You may have seen buffer overflows in Java, but they're extremely rare in comparison.
You're falling to the "black and white security" fallacy: the belief that if you can't solve a security problem 100% it's not worth solving it at all. In reality, a 99% solution is extremely valuable and in fact almost always the best you can do.
> Moving to a safe language like Rust would help, absolutely, but to a far lesser degree than people hope. It would close far fewer cans of worms than the hive mind hopes, and it's so new no one really knows how big its own can of worms is.
It makes it less likely that those errors that we're familiar with from C get compiled and released. There's no debate there. It's all those errors that we're not familiar with from C that it won't do anything against.
Not to mention errors stemming from our own arrogance and short-sightedness, which no language can ever protect us against.
If it makes it less likely that some errors get out, and doesn't do anything against other errors, then overall it makes it less likely that errors get out.
Please tell me how Rust introduces more possibilities for remote code execution vulnerabilities (the most severe). We're not talking about errors as a whole here.
The only RCE classes unique to memory-safe languages that come to mind are, like, dynamic deserialization vulnerabilities (like the Rails one) and remote includes (like PHP). Neither of these are applicable to Rust.
errors are not zero-sum. There's no finite pool of error that we're whittling down - there will likely be new error types we didn't know about or introduced by the new code.
> It makes it less likely that those errors that we're familiar with from C get compiled and released. There's no debate there. It's all those errors that we're not familiar with from C that it won't do anything against.
Those "errors", by and large, do not result in security problems (especially remote code execution), whereas the problems in C largely do. For example, Rust does introduce a new category of error, "Option.unwrap() failed". But so what? Option.unwrap() is security irrelevant.
Unless they mis-use `unsafe` the chances are very low and would be in the compiler rather than the source code. So yes, those errors should not appear.
Others are still possible and might be just as bad.
Off-topic to the issue at hand, but I am curious: would Servo[1], the browser engine written in Rust be having lesser (chances of) issues like this? I have written very little Rust, but it seems that the above issues are extremely unlikely to occur with Rust.
[1]: https://servo.org/