4 ms·

Buffer overflow without any dynamic allocation: #include <string.h> #include <stdio.h> int main() { char hello[5]; strcpy(hello, "hello"); printf("%s\n",

by hannob 8y ago

Buffer overflow without any dynamic allocation: #include <string.h> #include <stdio.h> int main() { char hello[5]; strcpy(hello, "hello"); printf("%s\n", hello); } (gcc warns about, interestingly clang does not)

wahern 8y ago
Rust recently had an integer overflow in str::repeat permitting a buffer overflow. It was a classic bug, the kind that gave C a bad reputation. And the error(s) in arithmetic occurred outside any unsafe block. If we want to be pedantic, all this talk of "fearless" wrt Rust is dangerous hyperbole. Once you move past juggling scalar values things get dicey, especially in C but also in so-called "safe" languages like Rust. And that, I think, was the previous poster's point--as you move away from dynamic allocation you tend to move toward using scalar (fixed-sized) objects. One of the original points of emphasis of Rust was to favor scalar values rather than pointers and even references. To a limited but useful extent you can mimic this in C. Rust examples that simply use Vec miss the point--1) the str::repeat bug overflowed a Vec, and 2) just because C doesn't come with a built-in Vec doesn't mean you can't write one or use one.
- lixtra 8y ago
  > Rust recently had an integer overflow in str::repeat permitting a buffer overflow. In case someone is interested of the details, like I was: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000810 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10008...
- Aengeuad 8y ago
  >And the error(s) in arithmetic occurred outside any unsafe block. This is completely misleading. The unsound check for integer overflow[0] was in 'safe' code but just because the code is not in an unsafe block does not absolve you of any potential bugs, and the subsequent writes to memory that were in an unsafe block clearly did not care about prior mistakes that were made. The PR that introduced the vulnerability[1] was due from switching a safe method to one that uses unsafe for performance reasons, I suggest checking out the commits for both the introduction of this bug as well as the commit that fixed it as they're both short and the actual bug only occurs on one short line. It's also worth noting that the vulnerability could have been found using a fuzzer[2] that did not exist (for Rust) at the time but that does now exist, and that integer overflows are checked for on debug builds (but not for release builds by default, again due to performance reasons) but that in this particular vulnerability it would have been extremely unlikely that any legitimate code would have triggered this integer overflow. The take away here isn't that 'even 'safe' languages get it wrong', but that unsafe operations are difficult to do correctly, and that's true in either C or Rust. There's further discussion[3] on this bug if anybody is interested. [0] https://github.com/rust-lang/rust/pull/54397 https://github.com/rust-lang/rust/pull/54397 [1] https://github.com/rust-lang/rust/pull/48657 https://github.com/rust-lang/rust/pull/48657 [2] https://medium.com/@shnatsel/how-ive-found-vulnerability-in-a-popular-rust-crate-and-you-can-too-3db081a67fb https://medium.com/@shnatsel/how-ive-found-vulnerability-in-... [3] https://internals.rust-lang.org/t/pre-rfc-fixed-capacity-view-of-vec/8413/35 https://internals.rust-lang.org/t/pre-rfc-fixed-capacity-vie...
LeifCarrotson 8y ago
That's dynamic allocation on the stack, though. As the parent said, your microwave probably (maybe) doesn't do that. Move the declaration out of main and declare it statically. And, of course, don't copy large buffers into small ones.

by hannob 8y ago

wahern 8y ago

Rust recently had an integer overflow in str::repeat permitting a buffer overflow. It was a classic bug, the kind that gave C a bad reputation. And the error(s) in arithmetic occurred outside any unsafe block. If we want to be pedantic, all this talk of "fearless" wrt Rust is dangerous hyperbole. Once you move past juggling scalar values things get dicey, especially in C but also in so-called "safe" languages like Rust. And that, I think, was the previous poster's point--as you move away from dynamic allocation you tend to move toward using scalar (fixed-sized) objects. One of the original points of emphasis of Rust was to favor scalar values rather than pointers and even references. To a limited but useful extent you can mimic this in C. Rust examples that simply use Vec miss the point--1) the str::repeat bug overflowed a Vec, and 2) just because C doesn't come with a built-in Vec doesn't mean you can't write one or use one.

lixtra 8y ago
> Rust recently had an integer overflow in str::repeat permitting a buffer overflow. In case someone is interested of the details, like I was: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000810 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10008...
Aengeuad 8y ago
>And the error(s) in arithmetic occurred outside any unsafe block. This is completely misleading. The unsound check for integer overflow[0] was in 'safe' code but just because the code is not in an unsafe block does not absolve you of any potential bugs, and the subsequent writes to memory that were in an unsafe block clearly did not care about prior mistakes that were made. The PR that introduced the vulnerability[1] was due from switching a safe method to one that uses unsafe for performance reasons, I suggest checking out the commits for both the introduction of this bug as well as the commit that fixed it as they're both short and the actual bug only occurs on one short line. It's also worth noting that the vulnerability could have been found using a fuzzer[2] that did not exist (for Rust) at the time but that does now exist, and that integer overflows are checked for on debug builds (but not for release builds by default, again due to performance reasons) but that in this particular vulnerability it would have been extremely unlikely that any legitimate code would have triggered this integer overflow. The take away here isn't that 'even 'safe' languages get it wrong', but that unsafe operations are difficult to do correctly, and that's true in either C or Rust. There's further discussion[3] on this bug if anybody is interested. [0] https://github.com/rust-lang/rust/pull/54397 https://github.com/rust-lang/rust/pull/54397 [1] https://github.com/rust-lang/rust/pull/48657 https://github.com/rust-lang/rust/pull/48657 [2] https://medium.com/@shnatsel/how-ive-found-vulnerability-in-a-popular-rust-crate-and-you-can-too-3db081a67fb https://medium.com/@shnatsel/how-ive-found-vulnerability-in-... [3] https://internals.rust-lang.org/t/pre-rfc-fixed-capacity-view-of-vec/8413/35 https://internals.rust-lang.org/t/pre-rfc-fixed-capacity-vie...

LeifCarrotson 8y ago

That's dynamic allocation on the stack, though. As the parent said, your microwave probably (maybe) doesn't do that. Move the declaration out of main and declare it statically. And, of course, don't copy large buffers into small ones.