3 ms·

> 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

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

AlienRobot 4mo ago
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.
- codedokode 4mo ago
  Nobody is going to write "checked_add" because that's too long and people are too lazy. The checked addition should be "+" operator.
  - zahlman 4mo ago
    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.
heinrich5991 4mo ago
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).
- pornel 4mo ago
  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.
  - uecker 4mo ago
    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.
    - pornel 4mo ago
      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 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.
- zahlman 4mo ago
  ... 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?
snvzz 4mo ago
>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.

AlienRobot 4mo ago

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.

codedokode 4mo ago
Nobody is going to write "checked_add" because that's too long and people are too lazy. The checked addition should be "+" operator.
- zahlman 4mo ago
  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.

heinrich5991 4mo ago

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

pornel 4mo ago
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.
- uecker 4mo ago
  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.
  - pornel 4mo ago
    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 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.
zahlman 4mo ago
... 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?

snvzz 4mo ago

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