"That bug is only triggered by an unrealistic corner case (username longer than 512MB)."

What makes you call that an "unrealistic" case? You're probably imagining some sort of world where a randomly distributed set of usernames are sent to this function drawn from the distribution of "real usernames that people use". Since 0 of them are longer than 512MB, you intuitively assume a 0 probability of exploit.

But in the security world, that's the wrong distribution. You have to assume a hostile, intelligent adversary. It isn't hard at all to construct a case of some web service allowing you to specify remote resources accessible with a username & password of your choosing (not corresponding to the username you're using to log in), an attacker specifying one of their own resources, reading the incoming headers to notice that you're using a vulnerable version of libcurl, and stuffing 512MB+exploit into the username field of your web app. If you don't add any other size restrictions between the attacker and the libcurl invocation, they may well pass it right in. (And your same intuition will lead you to not put any size restrictions there; "why would anybody have a multi-megabyte username?" You won't even have thought the question explicitly, you just won't put a length restriction on the field because it'll never even cross your mind.) By penetration standards, that doesn't even rise to the level of a challenge.

I think you missed the point of the post you are responding to. That person understands the value of the bug, and is just pointing out that Rust runs with unchecked math in production and would therefore be just as vulnerable in production. The benefit would come from it running with checked math in debug mode, but you, as the parent posted noted, would have to have a unit test or an integration test that realized this vulnerability to begin with and tried to exploit it.

The use of "unrealistic" was meant in the sense that you wouldn't think of it, not that you shouldn't guard against it once known.

> therefore be just as vulnerable in production.

I think there's two components here: yes, this might lead to a _logic bug_, but it should never lead to a _memory safety_ bug. That is, to get that CVE, you need both, and Rust will still protect you from one.

No, by default rust production builds run without memory safety turned on.

Edit: I believe I confused rust with another language.

What do you mean?

My point is that it is not an unrealistic case. In a security context, it is perfectly realistic.

I agree that the case is perfectly realistic.

> How does rust protect against such integer overflow caused by multiplication?

To me, the question was whether or not Rust would have been able to natively protect against this, considering it was a runtime issue?

To be fair, I would probably also run my security test suite against a debug binary too if I knew this kind of thing could be caught.

In Rust overflows generally will cause a panic. So "2 + 2" will return 4 or panic if you're on a 2-bit system (they provide .saturating_add() and .wrapping_add() to get code that will never panic)

Thus, you could have caused a denial of service by crashing a rust-based Curl, but the crash would have been modeled and just uncaught.

To be clear, Rust only panics from integer overflow when in debug mode. In release mode it will silently overflow just as happily as C.

To be extra extra extra clear:

1. Rust specifies that if overflow happens, it is a "program error", but it is well-defined as two's compliment overflow.

2. Rust specifies that in debug builds, overflow must be checked, and panic if it happens.

In the future, if overflow checking ever has acceptable overhead, this allows us to say that it must always be checked. But for now, you will get a well-formed result.

I'm not a Rust user (yet), but I'm a little surprised that with its emphasis on safety Rust doesn't maintain all debug safety checks in production by default. You could then do some profiling and turn off only those few (or one or none) that actually turned out to provide enough real-world, provable benefit to be worth turning off in this specific piece of code.

Since you would turn them off one at a time explicitly, rather than having a whole set of them disappear implicitly, you would probably also tend to have a policy of requiring a special test suite to really push the limits of any specific safety issue before you would allow yourself to turn that one off.

Obviously, if this occurred to me at first glance, it occurred to the designers, who decided to do it the other way after careful consideration, so I'm just asking why.

Basically, overflow doesn't lead to memory safety in isolation. That's the key of it. The worst that can happen is a logic errors, and we are not trying to stop all of those with the compiler :) Justifying a 20%-100% speed hit (that was cited in the thread) for every integer operation to save something that can't introduce memory safety is a cost we can't afford to pay.

If you want the full details, https://github.com/rust-lang/rfcs/blob/1f5d3a9512ba08390a222... is the RFC, and https://github.com/rust-lang/rfcs/pull/560 was the associated discussion, there is a lot of it.

EDIT: oh, one more thing that may have significance you may or may not have picked up: one reason why under/overflow in C and C++ is dangerous is that certain kinds are undefined behavior. It's well-defined in Rust. Just doing that alone helps, since the optimizer isn't gonna run off and do something unexpected.

Modern C compilers also allow to control the integer overflow behavior. For example, with gcc -ftrapv you can make the program to abort on overflow.

I think you can opt-in the checked arithmetic in release mode if you can stomach the performance cost.

Anyway, the buffer overflow itself is:

>If this happens, an undersized output buffer will be allocated, but the full result will be written, thus causing the memory behind the output buffer to be overwritten.

In Rust's case the output buffer would be returned into a dynamically sized type, probably a Vec<>. Attempts to put more data in the Vec than it can hold would either cause a runtime error or cause the Vec<> to reallocate (which could cause a performance issue, or maybe even a DoS if you could cause the system to allocate GBs of memory, but it wouldn't allow access to invalid memory).

So maybe something like:

    /* XXX potential multiplication overflow */
    let mut buf = Vec::with_capacity(insize * 4 / 3 + 4);

    while let Some(input) = get_input() {
        // Reallocs when capacity is exceeded
        buf.extend_from_slice(input);
    }

So even if the multiplication overflow is not caught it's by design impossible to have a buffer overrun in Rust.

By default rust doesn't allow out of bounds indexing (indexing and iteration are checked, although bounds checks are often optimized out), you have to explicitly write unsafe code to read off the end of an array or vector.

Can you elaborate on bounds checks being optimized out? Is it only in certain situations where compiler can prove that they are completely unnecessary? Otherwise, they can't be relied on, so what's the point of having them at all?

Yes, if the compiler can prove they're not needed, then it can remove the checks. But it has to prove it.

Reality is unrealistic.

https://medium.com/@blakeross/mr-fart-s-favorite-colors-3177...