3 ms·
This is counting the number of bugs, but what about the severity? https://curl.se/docs/CVE-2018-1000007.html https://curl.se/docs/CVE-2018-1000007.html is a lo
by duckerude 6y ago
This is counting the number of bugs, but what about the severity?
https://curl.se/docs/CVE-2018-1000007.html https://curl.se/docs/CVE-2018-1000007.html is a logic bug that may cause sensitive headers to be sent to the wrong host on redirects. It's slightly obscure, but I can imagine what an exploit looks like.
https://curl.se/docs/CVE-2018-1000120.html https://curl.se/docs/CVE-2018-1000120.html is a memory bug that lets you write a single null byte out of bounds. That's a security issue, but exploiting it seems less straightforward. (Though maybe it is more dangerous than the other one on net? I don't know enough about these issues to say.)
It could be that Rust would prevent half the vulnerabilities yet prevent much less than half the danger caused by vulnerabilities.
- lostcolony 6y agoSo you're saying Rust would make it more secure, but is not a magical panacea that prevents all security holes? I mean...okay. Still seems like a good reason to write it in Rust?
- duckerude 6y agoI'm only saying that Daniel's claim that "C is not the primary reason for our past vulnerabilities" might be basically right, even though the article says it's wrong. I'm a big fan of Rust, if it matters.
- tux3 6y agoDo note that the "single out of bound NULL byte" vulnerability has famously caught people off-guard in the past due to it being unexpectedly exploitable =) https://googleprojectzero.blogspot.com/2014/08/the-poisoned-nul-byte-2014-edition.html https://googleprojectzero.blogspot.com/2014/08/the-poisoned-... Those kind of exploits are thankfully getting harder with the many layers of mitigations we have today, but trying to predict which memory bug will or will not be exploitable is a very unintuitive and inadvisable exercise.