Repeat after me: Rust is a machine that turns security incidents into downtime incidents
-
Repeat after me: Rust is a machine that turns security incidents into downtime incidents
-
Repeat after me: Rust is a machine that turns security incidents into downtime incidents
@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.
-
Repeat after me: Rust is a machine that turns security incidents into downtime incidents
@mcc isn't a DoS vulnerability (which boils down to "downtime") a type of security incident?
-
@mcc isn't a DoS vulnerability (which boils down to "downtime") a type of security incident?
@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?
-
@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?
@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.
-
@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.
@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.
-
@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.
@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.
-
@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.
@dotstdy @whitequark I decline to recognize "potentially benign" as a category
-
undefined oblomov@sociale.network shared this topic on
-
@dotstdy @whitequark I decline to recognize "potentially benign" as a category
@mcc @whitequark "not exploitable" is probably a better category anyway. issues which cannot be leveraged into a compromise.
-
@mcc @whitequark "not exploitable" is probably a better category anyway. issues which cannot be leveraged into a compromise.
@mcc @whitequark btw for a fun example of DoS being an "actual" compromise, you can consider matchmaking in video games. If you're losing and you have a way to kill the game server, you can trigger your denial of service to take out the game server as soon as it looks like you're losing. voila: 100% win-rate matchmaking exploit! (plus any kind of fail-open system can be bypassed with a DoS)