> I think that sounded more like "Many of the programs which are UB in C are also UB in Rust, even though not (yet) specified as such."

Well, this seems either (a) false or (b) uninteresting to me. It's false because C and Rust have different semantics, and Rust rules out lots of programs that C doesn't. It's uninteresting because if the point is that Rust has accidental undefined behavior due to compiler bugs (and it does), then that UB is so rarely hit that it doesn't matter nearly as much in practice as the UB in C.

CPUs have bugs, too. Do we consider Java an unsafe language because of rowhammer?

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.

> 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.

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.

Use after free is a really common form of RCE. Have you heard the term "heap spray"? That's an exploitation technique for use after free.

"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."

It's so common there's a tutorial on it: http://www.fuzzysecurity.com/tutorials/expDev/11.html

Thanks!

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

Gah, it seems this one isn't good. I trust OWASP and skimmed, it seems that I agree with sibling commentors that this is more dangerous than is presented here.

Rust allows you to specify the behaviour you want:

Checked operations: https://doc.rust-lang.org/std/primitive.i8.html#method.check...

Saturating: https://doc.rust-lang.org/std/primitive.i8.html#method.satur...

Wrapping: https://doc.rust-lang.org/std/primitive.i8.html#method.wrapp...

Wrapping with notification: 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

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-...

> 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".

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.