4 ms·

Help me out here, I don't know much about Rust. Which bad programs does Rust rule out? I know about the borrow checker, but I don't think ownership bugs is a t

Help me out here, I don't know much about Rust. Which bad programs does Rust rule out? I know about the borrow checker, but I don't think ownership bugs is a type of bug that Mr. Hipp frequently produces. It's a program design issue -- not something you think about at every single line you write. A well-designed program does not do many ownership transfers. As someone else noted, out-of-bounds errors are sadly a pain to debug in C. For testing code, C has at least valgrind (and certainly many less well-known tools). For production code, you might not want dynamic index checking. It would invalidate performance arguments for Rust. I think the real nasty cases of UB in C, which frequently occur as not statically refutable, are signed arithmetic overflow and shifts. As with out-of-bounds errors, I don't think Rust has a better story here -- only better built-in tooling.

viraptor 11y ago
Rust allows you to specify the behaviour you want: Checked operations: https://doc.rust-lang.org/std/primitive.i8.html#method.checked_add https://doc.rust-lang.org/std/primitive.i8.html#method.check... Saturating: https://doc.rust-lang.org/std/primitive.i8.html#method.saturating_add https://doc.rust-lang.org/std/primitive.i8.html#method.satur... Wrapping: https://doc.rust-lang.org/std/primitive.i8.html#method.wrapping_add https://doc.rust-lang.org/std/primitive.i8.html#method.wrapp... Wrapping with notification: https://doc.rust-lang.org/std/primitive.i8.html#method.overflowing_add https://doc.rust-lang.org/std/primitive.i8.html#method.overf... These apply to shifts too and you can tag types themselves to always behave one way. Overflows at compile time are caught as errors. More info at: https://github.com/rust-lang/rust/issues/22020 https://github.com/rust-lang/rust/issues/22020 If the requested behaviour is unspecified (just `a+b`), overflows cause runtime panic (edit: or wrapping behaviour in release build) See https://doc.rust-lang.org/1.7.0/reference.html#behavior-not-considered-unsafe https://doc.rust-lang.org/1.7.0/reference.html#behavior-not-...
- jstimpfle 11y ago
  > If the requested behaviour is unspecified (just `a+b`), overflows cause runtime panic. As far as I know most machines can't trap on signed integer overflow. Which means having runtime panic is not practical. The page you linked says "no checking by default for optimized builds".
  - viraptor 11y ago
    Ok, I simplified this too much. For full details of what happens you'll have to read the docs. The non-release mode panics. Release mode with debug asserts turned on panics. Release mode with forced overflow checks panics. Release mode with no special options results in the same result as a wrapping operation.
comex 11y ago
> I know about the borrow checker, but I don't think ownership bugs is a type of bug that Mr. Hipp frequently produces. The borrow checker eliminates use-after-free. And use-after-free is one of the most common types of vulnerability exploited in practice today, if not the single most common. (For evidence, look at reports about Pwn2Own.) Index checking is quite cheap for most programs, and LLVM is good at eliminating redundant checks. As a useful comparison in another languages, Chromium compiles with bounds checks on std::vector by default (the [] operator, not the at() method which is required to be checked.) Actually, there are a lot of issues with Rust's current machine code output that I think slow it down, but index checking isn't one of them.
- jstimpfle 11y ago
  I don't think you can count use-after-free as exploitable. Sure, if you have them (and I think those cases can largely be ruled out by good design), it leads to crashes. But for memory type exploits you need control over the value in it. Not a security specialist but I'm not aware of common attacks besides overflowing buffers. In hot paths (like codecs, compression algorithms...) I'm sure you never want bounds checking. It can be optimized away for sequential loops of course, but not so easily in the case of data lookups.
  - steveklabnik 11y ago
    https://www.owasp.org/index.php/Using_freed_memory https://www.owasp.org/index.php/Using_freed_memory
    - jstimpfle 11y ago
      "While it is technically feasible for the freed memory to be re-allocated and for an attacker to use this reallocation to launch a buffer overflow attack, we are unaware of any exploits based on this type of attack."
      - comex 11y ago
        I have no idea what that article is talking about. Use-after-free exploits have been extremely common for years. Like I said, look at Pwn2Own (which requires submitting an actual working exploit): https://www.google.com/search?q=pwn2own+use-after-free https://www.google.com/search?q=pwn2own+use-after-free

viraptor 11y ago

Rust allows you to specify the behaviour you want: Checked operations: https://doc.rust-lang.org/std/primitive.i8.html#method.checked_add https://doc.rust-lang.org/std/primitive.i8.html#method.check... Saturating: https://doc.rust-lang.org/std/primitive.i8.html#method.saturating_add https://doc.rust-lang.org/std/primitive.i8.html#method.satur... Wrapping: https://doc.rust-lang.org/std/primitive.i8.html#method.wrapping_add https://doc.rust-lang.org/std/primitive.i8.html#method.wrapp... Wrapping with notification: https://doc.rust-lang.org/std/primitive.i8.html#method.overflowing_add https://doc.rust-lang.org/std/primitive.i8.html#method.overf... These apply to shifts too and you can tag types themselves to always behave one way. Overflows at compile time are caught as errors. More info at: https://github.com/rust-lang/rust/issues/22020 https://github.com/rust-lang/rust/issues/22020 If the requested behaviour is unspecified (just `a+b`), overflows cause runtime panic (edit: or wrapping behaviour in release build) See https://doc.rust-lang.org/1.7.0/reference.html#behavior-not-considered-unsafe https://doc.rust-lang.org/1.7.0/reference.html#behavior-not-...

jstimpfle 11y ago
> If the requested behaviour is unspecified (just `a+b`), overflows cause runtime panic. As far as I know most machines can't trap on signed integer overflow. Which means having runtime panic is not practical. The page you linked says "no checking by default for optimized builds".
- viraptor 11y ago
  Ok, I simplified this too much. For full details of what happens you'll have to read the docs. The non-release mode panics. Release mode with debug asserts turned on panics. Release mode with forced overflow checks panics. Release mode with no special options results in the same result as a wrapping operation.

comex 11y ago

> I know about the borrow checker, but I don't think ownership bugs is a type of bug that Mr. Hipp frequently produces. The borrow checker eliminates use-after-free. And use-after-free is one of the most common types of vulnerability exploited in practice today, if not the single most common. (For evidence, look at reports about Pwn2Own.) Index checking is quite cheap for most programs, and LLVM is good at eliminating redundant checks. As a useful comparison in another languages, Chromium compiles with bounds checks on std::vector by default (the [] operator, not the at() method which is required to be checked.) Actually, there are a lot of issues with Rust's current machine code output that I think slow it down, but index checking isn't one of them.

jstimpfle 11y ago
I don't think you can count use-after-free as exploitable. Sure, if you have them (and I think those cases can largely be ruled out by good design), it leads to crashes. But for memory type exploits you need control over the value in it. Not a security specialist but I'm not aware of common attacks besides overflowing buffers. In hot paths (like codecs, compression algorithms...) I'm sure you never want bounds checking. It can be optimized away for sequential loops of course, but not so easily in the case of data lookups.
- steveklabnik 11y ago
  https://www.owasp.org/index.php/Using_freed_memory https://www.owasp.org/index.php/Using_freed_memory
  - jstimpfle 11y ago
    "While it is technically feasible for the freed memory to be re-allocated and for an attacker to use this reallocation to launch a buffer overflow attack, we are unaware of any exploits based on this type of attack."
    - comex 11y ago
      I have no idea what that article is talking about. Use-after-free exploits have been extremely common for years. Like I said, look at Pwn2Own (which requires submitting an actual working exploit): https://www.google.com/search?q=pwn2own+use-after-free https://www.google.com/search?q=pwn2own+use-after-free