Hacker News Reader

Comment by codedokode | Hacker News Reader

> DFVULN-123 (Integer Overflow): In the RTP LATM depacketizer (rtpdec_latm.c), latm_parse_packet() performs a signed 32-bit addition that overflows and bypasses its bounds check

Again there is another vulnerability caused by unchecked addition, and still modern languages like Rust or Go do not raise exception on overflow, and modern CPU architectures like RISC-V provide no overflow traps. And older languages like C or C++ do not have overflow checks also.

Ridiculous. It is obvious that humans cannot be trusted with writing correct arithmetics code.

View on HN

Rust enables overflow checking in debug mode, you can (and I do) enable it in release mode as well.

Rust's default integer overflow in release mode is defined as well, it'll just wrap around. This makes it less likely to result in a vulnerability (unless you start writing unsafe Rust).

Additionally, integer overflow is less immediately dangerous in Rust, because buffer access is bounds-checked after the arithmetic. You can still get some logic bugs that eventually lead to vulnerabilities, but it's not an arbitrary memory write gadget.

What convinced me that this is wishful thinking was CVE-2023-53156. Yes, it used "unsafe" but the wraparound in release defeated the manual check, and when you aim for performance comparable to C, Rust tends to be full of unsafe blocks.

IMHO better C tooling would be a far better investment than rewriting in Rust.

Incremental/quantitative improvement isn't disproven by contradiction. Anecdote is not data. Look at a bigger dataset, e.g. https://github.com/rust-fuzz/trophy-case there's a ton of overflows that result in caught panics or OOMs, and not bypasses. It works to reduce defect rate and severity.

Note that C's tools for this like Valgrind, instrumented allocators and LLVM sanitizers work with Rust too. Investment in catching these in C generally helps unsafe Rust too, but Rust also has Miri, and a much better baseline for static analysis.

... do `unsafe {}` blocks not have the same semantics? I thought that was only about memory safety. Or are you thinking of cases where a wrapped-around integer gets interpreted as a pointer or something?

unsafe never changes the semantics of anything. Unsafe gives you access to additional features, never changes the meaning of a feature.

Zig raises overflow. There are +|= and +%= operators for clamped and wrapping addition.

Rust doesn't raise overflow by default. But you can just 123.checked_add(321). Now your code is unreadable, but it's overflow safe.

Honestly, based on the way I write code I'd rather something like an end of line comment. Like:

   var x = y + z; # wrapped

Because I'm very unlikely to mix wrapped/checked/clamped arithmetic in a single line. It can't be a compiler state like doing(wrapped) { x + y } because in Zig every line must be "compilable" by itself, without requiring context from other parts of the code. Function names are too verbose. Casting is too verbose. Having a statement-level modifier would be a good compromise.

Nobody is going to write "checked_add" because that's too long and people are too lazy. The checked addition should be "+" operator.

Agreed, the option that sacrifices security in search of performance should be the more verbose one. There's a reason Rust doesn't have `safe {}` blocks and there's a reason it chose immutable-by-default semantics.

>modern CPU architectures like RISC-V provide no overflow traps

Irrelevant. Simplicity here is better than complexity.

Unless you're handwriting assembly, this is a compiler's job.

Reply on news.ycombinator.com