Is CVE-2020-8794 a logical issue?

Question

From: https://www.qualys.com/2020/02/24/cve-2020-8794/lpe-rce-opensmtpd-default-install.txt

LPE and RCE in OpenSMTPD's default install (CVE-2020-8794)

AFAIK I can read from this longer post, that it is based on an "out-of-bounds read".

The Big Question: If this code was written in Rust and not in C, would Rust prevent the "out-of-bounds read"?

Thanks.

Answer 1

Most likely Rust would have prevented this.

This

line = line + 4;

is not something we would do in Rust. We rarely use raw pointers directly, preferring more convenient and safer 0-cost wrappers such as slices. In fact raw-pointer arithmetic is so rare, we don't even have operators for it (only methods). Slices are guaranteed to point to valid memory, and are aware of their size, so assuming the developers would have used a &[u8] for line, this would likely become in Rust:

line = &line[4..];

but the indexing operator does bound checks by default, panicking if the indices are out of bounds. This would prevent the invalid read that follows in the rest of the C code.

---

Of course this is assuming the developers would have only used safe Rust. If they had deemed this branch important enough to deserve some extra optimizations using which could require unsafe (eg. calling get_unchecked after they had noticed (or assumed!?) that the compiler could not optimize a bound check), the same kinds of problems would exist in Rust as in C.

Rust is only safe by default.