Hacker News new | ask | show | jobs
by dcsommer 1256 days ago
Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation. Safe rust doesn't (in any build mode), but C/C++ does.
3 comments

> Integer overflow isn't a security issue unless your program's memory safety depends on the correctness of the integer operation.

That's simply not true and has wide-reaching horrible effects that can occur. The wrong number of tickets can be purchased from a website, charging for less than were purchased. The DNR order can be put in place instead of SAVE LIFE. There are countless security issues that can occur.

Saying that integer overflow is only an issue for memory safety is really bad and incorrect advice.

That's most logic issues though, is it not? I agree with you though, i wish Rust more commonly pushed "safer" (not in the UB way) code, like `Vec::get` and `u32::overflow_add` and etc.

Luckily lints help to easily ban the arithmetic/etc ops from projects. Nevertheless i feel it should be a bit closer to Rust's home.

Do you have data on the relative frequency and severity of non-memory safety integer overflow security issues?
Here are over 3k CVEs that contain "integer overflow". That shouldn't be considered a comprehensive search.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=integer+ove...

You don't need to have to have historical stats to show that it can be a security issue.
I know at least about the DAO hack.
To elaborate on this: Rust always performs bounds checks on array accesses, so you can't get an out-of-bound read/write.
Is there a way to turn this off?
Not via a compiler flag, no. The way to "opt out" of bounds checks is to replace `foo[bar]` with `unsafe { foo.get_unchecked(bar) }` at a given callsite. And the use of `unsafe` is going to immediately raise the eyebrow of any code reviewer or auditor.
You don't know the business logic of every program. You can't say that a rust program won't have a security issue due to this.

`UserAccessLevel > Threshold`

Like there could be a million ways an integer becoming small could mess up something.

Also there are business logic issues as well

Sure, but a logic error is a fundamentally different class of error compared to a memory error. The potential harm of a logic error is limited in scope to what the program was written to be able to do. A memory error can lead to arbitrary code execution.
Logic errors can still be security issues, even if they don't violate memory safety.
Absolutely, and I didn't suggest otherwise. But a logic error generally won't lead to your entire system getting pwned unless the program that has the logic error is one for something like user administration or managing a database etc.