3 ms·

I'd say it depends. > heartbleed was bad, but those type of bugs are rare Not really. There's a constant stream of security vulnerabilities arising from buffe

I'd say it depends. > heartbleed was bad, but those type of bugs are rare Not really. There's a constant stream of security vulnerabilities arising from buffer-overflows and memory-management bugs, even in the most high-profile C/C++ codebases like the Linux kernel and Chromium. C and C++ are minefields for undefined behaviour, and many security vulnerabilities can be tracked back to instances of undefined behaviour. Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities. That's not to say I'd uncritically jump aboard a safe-Rust replacement for OpenSSL. As you say, there's much value in mature and battle-tested code, and Rust's safety guarantees wouldn't guarantee you a bug-free SSL library, they only guarantee the absence of certain kinds of errors. Even a fully formally verified implementation in SPARK could still have side-channel vulnerabilities (e.g. timing issues).

xondono 6y ago
Bugs are frequent, but most of them have limited scope, bugs that break everything from computers to smart toasters are rare. As a C programmer myself I’m well aware of how big the mine field is, and I’m a big proponent for validation in the Rust style, but that was not the point. This guide advocates for replacements for programs and libraries written in C++, with most of those replacements being written also in C++, but with “superior programming practices”, even when those replacements are very rarely used in most environments.
- MaxBarraclough 6y ago
  Even there it depends. 'Programming practices' is vague. Even C can be tamed, at great expense, using formal methods techniques. [0][1][2][3] Adoption of such methods can give a solid assurance of the lack of UB, like use of a safe language. Weaker measures, like adopting MISRA C, don't provide such strong assurances (although they can eliminate certain categories of errors), and as you indicate, their real value is a bit more subjective. Mandating a bad programming style could actively make things worse. [0] https://trust-in-soft.com/ https://trust-in-soft.com/ [1] https://www.eschertech.com/products/perfect_developer.php https://www.eschertech.com/products/perfect_developer.php [2] https://github.com/microsoft/Armada https://github.com/microsoft/Armada [3] https://www.microsoft.com/en-us/research/project/vcc-a-verifier-for-concurrent-c/ https://www.microsoft.com/en-us/research/project/vcc-a-verif...
nineteen999 6y ago
> Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities. Unfortunately this is easier said than done, as evidenced by the fact that it is said a lot, and never done.
- MaxBarraclough 6y ago
  Agree. Not something I know a lot about but it seems to be a significant undertaking. I figure a production-grade implementation in safe Rust is more likely than a verified implementation in SPARK. I don't know how serious the rustls implementation is. Nice to see it makes no use of Rust's unsafe features. https://github.com/ctz/rustls https://github.com/ctz/rustls

xondono 6y ago

Bugs are frequent, but most of them have limited scope, bugs that break everything from computers to smart toasters are rare. As a C programmer myself I’m well aware of how big the mine field is, and I’m a big proponent for validation in the Rust style, but that was not the point. This guide advocates for replacements for programs and libraries written in C++, with most of those replacements being written also in C++, but with “superior programming practices”, even when those replacements are very rarely used in most environments.

MaxBarraclough 6y ago
Even there it depends. 'Programming practices' is vague. Even C can be tamed, at great expense, using formal methods techniques. [0][1][2][3] Adoption of such methods can give a solid assurance of the lack of UB, like use of a safe language. Weaker measures, like adopting MISRA C, don't provide such strong assurances (although they can eliminate certain categories of errors), and as you indicate, their real value is a bit more subjective. Mandating a bad programming style could actively make things worse. [0] https://trust-in-soft.com/ https://trust-in-soft.com/ [1] https://www.eschertech.com/products/perfect_developer.php https://www.eschertech.com/products/perfect_developer.php [2] https://github.com/microsoft/Armada https://github.com/microsoft/Armada [3] https://www.microsoft.com/en-us/research/project/vcc-a-verifier-for-concurrent-c/ https://www.microsoft.com/en-us/research/project/vcc-a-verif...

nineteen999 6y ago

> Rewriting in a safe language, like SPARK or the safe subset of Rust, would close the door on these vulnerabilities. Unfortunately this is easier said than done, as evidenced by the fact that it is said a lot, and never done.

MaxBarraclough 6y ago
Agree. Not something I know a lot about but it seems to be a significant undertaking. I figure a production-grade implementation in safe Rust is more likely than a verified implementation in SPARK. I don't know how serious the rustls implementation is. Nice to see it makes no use of Rust's unsafe features. https://github.com/ctz/rustls https://github.com/ctz/rustls