6 ms·
I think you missed the point of the post you are responding to. That person understands the value of the bug, and is just pointing out that Rust runs with unche
by ambulancechaser 10y ago
I think you missed the point of the post you are responding to. That person understands the value of the bug, and is just pointing out that Rust runs with unchecked math in production and would therefore be just as vulnerable in production. The benefit would come from it running with checked math in debug mode, but you, as the parent posted noted, would have to have a unit test or an integration test that realized this vulnerability to begin with and tried to exploit it.
The use of "unrealistic" was meant in the sense that you wouldn't think of it, not that you shouldn't guard against it once known.
- steveklabnik 10y ago> therefore be just as vulnerable in production. I think there's two components here: yes, this might lead to a _logic bug_, but it should never lead to a _memory safety_ bug. That is, to get that CVE, you need both, and Rust will still protect you from one.
- ars 10y agoNo, by default rust production builds run without memory safety turned on. Edit: I believe I confused rust with another language.
- steveklabnik 10y agoWhat do you mean?
- jerf 10y agoMy point is that it is not an unrealistic case. In a security context, it is perfectly realistic.
- castis 10y agoI agree that the case is perfectly realistic. > How does rust protect against such integer overflow caused by multiplication? To me, the question was whether or not Rust would have been able to natively protect against this, considering it was a runtime issue?
- arcticbull 10y agoTo be fair, I would probably also run my security test suite against a debug binary too if I knew this kind of thing could be caught.
- kscz 10y agoIn Rust overflows generally will cause a panic. So "2 + 2" will return 4 or panic if you're on a 2-bit system (they provide .saturating_add() and .wrapping_add() to get code that will never panic) Thus, you could have caused a denial of service by crashing a rust-based Curl, but the crash would have been modeled and just uncaught.
- adwhit 10y agoTo be clear, Rust only panics from integer overflow when in debug mode. In release mode it will silently overflow just as happily as C.
- steveklabnik 10y agoTo be extra extra extra clear: 1. Rust specifies that if overflow happens, it is a "program error", but it is well-defined as two's compliment overflow. 2. Rust specifies that in debug builds, overflow must be checked, and panic if it happens. In the future, if overflow checking ever has acceptable overhead, this allows us to say that it must always be checked. But for now, you will get a well-formed result.
- amadvance 10y agoModern C compilers also allow to control the integer overflow behavior. For example, with gcc -ftrapv you can make the program to abort on overflow.
- SiVal 10y agoI'm not a Rust user (yet), but I'm a little surprised that with its emphasis on safety Rust doesn't maintain all debug safety checks in production by default. You could then do some profiling and turn off only those few (or one or none) that actually turned out to provide enough real-world, provable benefit to be worth turning off in this specific piece of code. Since you would turn them off one at a time explicitly, rather than having a whole set of them disappear implicitly, you would probably also tend to have a policy of requiring a special test suite to really push the limits of any specific safety issue before you would allow yourself to turn that one off. Obviously, if this occurred to me at first glance, it occurred to the designers, who decided to do it the other way after careful consideration, so I'm just asking why.