5 ms·
There is some important context missing from your comment here. At least two points anyway: In Rust, overflow is not undefined behavior (neither signed nor uns
by burntsushi 4y ago
There is some important context missing from your comment here. At least two points anyway:
In Rust, overflow is not undefined behavior (neither signed nor unsigned). Today, arithmetic wraps in release mode (panics in debug mode), but it may panic in release mode in the future.
The other point is that, since overflow wraps, that may indeed result in logic bugs. And in theory that logic bug could be used to lead to exploit, such as a buffer overrun. But Rust uses bounds checking by default everywhere, so the worst case you'll usually end up with here is a panic or a DoS vulnerability. Not great, but probably preferable to other types of vulns that grant access to sensitive data.
So I think two things would need to happen, at minimum, to get a non-DoS vulnerability here. You'd need to find a bug that caused arithmetic to overflow where it otherwise shouldn't, and you need to find some way to connect that to an explicitly `unsafe` unchecked access into memory.
- estebank 4y agoBeyond the above, IIRC Android ships with integer overflow enabled (but can't find where I read this).
- est31 4y agoYou can confirm it by looking into the source code: https://android.googlesource.com/platform/build/soong/+/refs/heads/android13-release/rust/config/global.go#49 https://android.googlesource.com/platform/build/soong/+/refs... Not an expert, but a file named "global.go" makes me confident :).
- saagarjha 4y agoAmusing to see that the compiler flags for Rust are stored in a Go file ;)
- insanitybit 4y agoNot that it's important, but just a note that unless you recompile the standard library yourself, integer overflow will still be off for that code since it ships compiled. (Correct me if I'm wrong, that's my recollection).
- est31 4y agoThe Android project compiles the standard library themselves: https://android.googlesource.com/platform/prebuilts/rust/+/android13-release/Android.bp https://android.googlesource.com/platform/prebuilts/rust/+/a...
- insanitybit 4y agoFigures, thanks.
- masklinn 4y agoAn other thing to note is that java does not check for overflow either. Having the “native” langage be no worse than the “managed” one is a better situation to be in than the reverse. Also Rust allows enabling overflow checking in release, it’s a perfectly valid configuration.
- Arnavion 4y ago>You'd need to find a bug that caused arithmetic to overflow where it otherwise shouldn't, and you need to find some way to connect that to an explicitly `unsafe` unchecked access into memory. Yes, it's particularly a dangerous problem when doing FFI. Eg you have a `data: &[u8]` and you need to call `extern "C" fn foo(data: *const u8` and `data_len_in_bits: usize)`, you could write `data.len() * 8` for the second parameter and Rust wouldn't stop you. It's also annoying that the only way to do checked arithmetic is replace all the simple arithmetic operators with `.checked_*()?` function calls. libstd doesn't have a `std::num::Checked<T>` like it has `Wrapping` that would implement all the arithmetic traits in terms of `checked_*` and return `Result<>`. But at least it's not hard to do yourself. ( https://github.com/Arnavion/terminal/blob/475d917377eea43b5284ca3be842658f6750cb40/src/terminfo/mod.rs#L711-L736 https://github.com/Arnavion/terminal/blob/475d917377eea43b52... )
- codedokode 4y agoWrapping arithmetic operations have been a reason of vulnerabilities in Linux kernel though. Developers need real addition, not addition modulo 2^32.
- burntsushi 4y agoI don't understand if you're disagreeing with me or writing something that you think is inconsistent with what I said. Because I don't see anything inconsistent between what I said and what you wrote.