Repeat after me: Rust is a machine that turns security incidents into downtime incidents
8
Discussion
Loading...
@bdod And this is a meaningful, important improvement. Unless the thing you were using before is Java, C#, JS/TS, Python, or Go. Then it is a lateral step which may or may not justify itself depending on your use case.
@mcc I speak Spanish, but I get you speak about other types of languages.
Well, that's a good point
1
@mcc @whitequark more precisely, Rust turns security incidents that remove any and all of confidentiality, integrity, and availability at the attacker's choosing, into security incidents that only remove availability
@mcc what we need, though, are languages that turn security incidents into compile errors
1
@kitten_tech *shrugs* make dependent typing fast and ergonomic and you've got yourself a defensible PHD thesis
1
@mcc isn't a DoS vulnerability (which boils down to "downtime") a type of security incident?
1
@whitequark *thinks* Making sure I understand the question. You're suggesting someone will find a endpoint tickle that in mediocre C++ code would have resulted in a security incident and in mediocre Rust results in a program halt, and then call this endpoint tickle repeatedly as a DOS?
2
@mcc I disagree on principle that "downtime incidents" are not "security incidents", if for no other reason that DoS vulnerabilities get CVEs every time (so, clearly, the possibility of unexpected/undesired downtime is fully recognized as being in the domain of "security")
1
@whitequark Okay. This is a good point
1
@mcc also, if you accept this, the result is a much more nuanced take of "Rust is a machine that reliably and at scale significantly lowers the severity of security incidents"
1
@whitequark what I like about DOS vulnerabilities as opposed to other types of vulnerabilities is that the range of possible outcomes is easier to constrain
2
2 more replies (not shown)
@mcc @whitequark an example would be an out-of-bounds access that is benign in the actual compiled binary (e.g if due to luck it always returns zero, which is harmless in the context), which is reasonably common. so in that case you're escalating a code issue, that has no security relevance in the actual product, to a DoS which does.
1
@dotstdy @whitequark "i.e. due to luck it always returns zero"
I do not believe in this sort of luck. In my experience, this sort of "luck" has a tendency to evaporate on events like ABI changes or compiler upgrades.
1
@mcc @whitequark right, and I'm not suggesting it's a good security posture. but you are turning potentially benign issues into a denial of service CVE, in that case.
1
@dotstdy @whitequark I decline to recognize "potentially benign" as a category
2
2 more replies (not shown)
@mcc@mastodon.social the scary thing about this framing is that it rather highlights the fact that security issues don't tend to have (short term) cash flow implications, while downtime incidents do.
1
@mavnn @mcc It reminds me how newbie programmers often find compiler errors so frustrating, because they just want to see the program run even it it produces garbage, and to them the value of preventing a whole class of run-time errors without having to debug a running program isn't apparent.
Only instead of teenagers we're talking about corporate executives weighing the cost of an angry customer right now vs. having to send another "oops, have a year of credit monitoring services" email later.
@mcc As any language that turns undefined behavior into exceptions?