Cve-rs: Fast memory vulnerabilities, written in safe Rust

by npalli • 2 years ago

317 142 2 years ago

It's weird to see lifetime correlations expressed as

    &'a &'b

and not with

    where 'a: 'b

I suppose I don't understand enough of how the first is different from the second one, and how it impacts this issue.

dannymi• 2 years ago

It's just a reference to a reference. It has nothing to do with lifetime correlations.

Also, it's a lot less weird if you don't stop in the middle of the type. The entire type is for example

    &'a &'b u8

    &'a &'b ()

So the outer reference has lifetime 'a and the inner reference has lifetime 'b.

Georgelemental9• 2 years ago

It has nothing to do with lifetime correlations

Yes it does; there's an implied `'b: 'a` outlives relationship that's required for the type to be well-formed.

kbknapp• 2 years ago

In fact, I believe that's exactly where this bug lies. You're effectively able to trigger a case in which passing `&'a &'b` without providing any correlation (`where 'a: 'b`) that one would normally be required to provide makes the compiler behave as if those correlations were passed, albeit inferred incorrectly.

LegionMammal978• 2 years ago

The first one creates an implied bound, while the second is an explicit bound. The important thing about implied bounds is that they allow late binding of lifetimes to function pointers (or closures): that is, you can have a single function pointer type like "for<'a> fn(&'a str)" that can be called with any lifetime 'a. Here, the lifetime 'a is called "late-bound", since it can be different with each call.

In contrast, if a lifetime is subject to an explicit where bound, it must be "early-bound": each function pointer can must choose one particular value for that lifetime, that must be upheld for every call. For a practical example, you might have tried to declare a closure with a &T parameter, only to get lifetime errors when you call it twice. This is because the lifetime in the closure type is early-bound and must be the same for every call. (Sometimes the compiler figures out that a late-bound lifetime is desired, but the rules are very subtle. This is also why it's difficult to write a function that accepts a generic async closure.)

Late binding is necessary for certain kinds of variance, which is a big part of this issue. Function pointers are contravariant in their parameters, which means if you have a type like "fn(&'short str)", you can cast it to "fn(&'static str)", since a 'static reference will always be valid for 'short. They're also covariant in their return type, so that "fn() -> &'static str" can be cast into "fn() -> &'short str". But when performing these variance transformations with late-bound lifetimes, the compiler doesn't always take into account the implied bounds in the source type properly, which allows you to perform casts that aren't actually sound.

WirelessGigabit2• 2 years ago

Edit (since I cannot edit my comment after 2 hours): for the code to properly verify the lifetimes one needs to write

    where 'b: 'a

meaning 'b is at least as useful as 'a. So 'b can live the same time, or longer, but not less.

robinsonrc• 2 years ago

It’s good to see that at least Miri catches the issues. Hopefully the compiler can catch up with that!

vlovich1233• 2 years ago

Does polonius catch the issue?

throwawaymaths3• 2 years ago

If you need a compiler sidecar anyways, why not just have a simpler language where all the borrow checking is done in a sidecar?

dralley5• 2 years ago

You don't "need" a compiler sidecar unless you're specifically writing code to exploit obscure bugs. This is a 0.0001% case

steveklabnik8• 2 years ago

Miri is fantastic, but also isn't a "compiler sidecar," exactly. It is an interpreter. It's closer to a sanitizer than a compile-time check. It also means a huge, huge overhead to running your code, and in a performance-sensitive language that's a tough sell.

It's also only needed for when you dip into unsafe, which is not particularly often, and so imposing this on all code would be the wrong tradeoff.

dralley5• 2 years ago

Seems to rely on at least one known compiler bug (admittedly one open since 2015) https://github.com/rust-lang/rust/issues/25860

dgfitz2• 2 years ago

Looking at the syntax in that bug report makes me think I could never learn rust.

faitswulff• 2 years ago

You could also think of it as "look at all the weird syntax olympics you need to do in order to trigger a compiler edge case!"

the_mitsuhiko• 2 years ago

That is not syntax you would ever see.

mattigames• 2 years ago

That's like saying you could never learn JS beacuse the following valid JS snippet, when in real life you would never see such thing unless someone its trying to obfuscate the code:

    [,{a,'z':q|0}[`${a?.x??b}`]]

FpUser• 2 years ago

They've just written terse code with lots of single character identifiers. Not the style on would / should use for real life development of readable code.

secondcoming• 2 years ago

Once you conquer the headaches and eye-strain, it's not too bad.

wredue3• 2 years ago

One of my criticisms of Rust is that it’s a very RSI causing language. Very heavy on reaching awkward keys.

I mean, a read through the guide makes this very readable, but it doesn’t change that it looks like symbol soup and have lots of awkward repetitive strain to type it out.

oneshtein• 2 years ago

`&` is a reference.

`'a` is a label for a memory area, like goto labels in C but for data. You can read it as (memory) pool A. Roughly, when function entered, memory pool is created, then destroyed at exit.

`'static` is special label for static data (embedded constants).

`()` is nothing, like void in C.

`&()` is an reference to nothing (an address) like `void const *` in C.

`&&()` is an reference to reference to nothing, like `void const * const *` in C.

`& 'static & 'static ()` is like void `const * const *` to a built-in data in C.

`& 'a & 'b ()` tells compiler that second reference is stored in pool 'a, while data is stored in pool 'b. (First reference is in scope of current function.)

`_` is a special prefix for variables to instruct compiler to ignore warning about unused variable. Just `_` is a valid variable name too.

  static UNIT: &'static &'static () = &&();

  fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }

Let's say that `&'a` is from a function `a()`, while `&'b` is from a function `b()`, which called from the function `a()`.

The trick here is that we relabel reference from pool `'b`, from an inner function, to pool `'a` from outer function, so when program will exit from function `b()`, compiler will destroy memory pool `'b`, but will keep reference to data inside until end of the function `a()`.

This should not be allowed.

dralley5• 2 years ago

You should treat this the same as you would something like the Obfuscated C competition. Just because it's supposed to compile and run properly doesn't mean it's good code.

GaggiX• 2 years ago

I thought it was just using the totally safe transmute, this one: https://blog.yossarian.net/2021/03/16/totally_safe_transmute...

But I guess there is another trick.

Georgelemental9• 2 years ago

As noted on that GitHub page, fixing the bug will become possible once rustc adopts a new trait solver: https://blog.rust-lang.org/inside-rust/2023/07/17/trait-syst...

Maken• 2 years ago

Everything is always a new solver away.

meindnoch• 2 years ago

Is it going to be even slower than the current one?

nialv73• 2 years ago

Can you quote the relevant part? Because IIUC lifetime checks have nothing to do with the trait solver.

There's a new borrow checker however, but that's not going to fix this either

nicklecompte6• 2 years ago

My biggest concern with Rust is the sloppiness around the distinction between a "compiler bug" and a "hole in the type system." This is more of a specification bug even though Rust doesn't have a formal specification: the problem is the design of the language itself, not that a Rust programmer wrote the wrong thing in the source code: https://counterexamples.org/nearly-universal.html?highlight=...

ggreg84• 2 years ago

My biggest concern with Rust is the sloppiness around the distinction between a "compiler bug" and a "hole in the type system."

That bug is marked as I-unsound, which means that it introduces a hole in the type system.

And so are all other similar bugs, i.e., your concern seems to be unfounded, since you can actually click on the I-unsound label, and view all current bugs of this kind (and past closed ones as well!).

underdeserver• 2 years ago

Looking over the code, it relies entirely on that single bug.

On the one hand that's encouraging - you really need to want to trigger it, it doesn't look like a bug that's likely to get accidentally written. Even then, it required a bunch of anti-optimization barriers and stuff to actually be exploitable.

On the other hand, one compiler bug and safe, well, isn't

I still like Rust.

Karellen• 2 years ago

GLWTS(Good Luck With That Shit) Public License
The author has absolutely no fucking clue what the code in this project does. It might just fucking work or not, there is no third option.

lol

omoikane• 2 years ago

Sounds like an updated version of WTFPL

https://en.wikipedia.org/wiki/WTFPL

adastra22• 2 years ago

What’s your shell prompt config that you screenshotted in the README?

xal• 2 years ago

looks like https://starship.rs/

hpb42• 2 years ago

Oh, cool. They implemented a `download_more_ram()` function![0]

Does it crash safely as well? I did not test it, I more than 640 KB of ram.

- [0] https://github.com/Speykious/cve-rs/blob/d51f52dd64f148a086e...

foolswisdom• 2 years ago

What a wonderful license! https://github.com/Speykious/cve-rs/blob/main/LICENSE

poly_morphis• 2 years ago

I could get behind that type of short, clear legalese.

yjftsjthsd-h• 2 years ago

0. You just DO WHATEVER THE FUCK YOU WANT TO as long as you NEVER LEAVE A FUCKING TRACE TO TRACK THE AUTHOR of the original product to blame for or held responsible.

A thing of beauty^_^ I've seen a lot of licenses that require attribution[0], so a license that explicitly demands that you not credit the author is a lovely twist:)

[0] Read: Nearly all of them; even permissive BSD-like licenses usually(?) require that much.

saagarjha2• 2 years ago

Are you the safest because you're Rust? Or are you Rust because you are the safest?

datadeft4• 2 years ago

The real question is: what is the chance that somebody runs into this while implementing something common.

vacuity• 2 years ago

It's not about frequency; it's about the possibility that just one of these unsoundness bugs gets through to production and screws things up. The whole point of memory safety languages is that, unless you (or a dependency author) dives into the dark arts of whatever language you're working in, you are guaranteed to not encounter use-after-free or null-pointer-dereference. Practically, maybe such a bug gets patched quickly, and no one exploits it as a vulnerability. In hindsight, then, it wasn't so bad. But you don't want to be the one who is called at 2 AM because an impossible segfault happened and wrecked the database.

fweimer2• 2 years ago

Without compiler bugs, on stock Linux, you can achieve the same thing via /proc/self/mem. Rust makes this very easy because you can get the raw address from safe code, so no guessing is required which memory location to patch.

For the compiler bug, as someone who never strayed into those regions of Rust programming, it's not clear to me how likely it is that someone would write such code by accident and introduce a memory safety issue into their program. I browsed the Github issues, but couldn't find an indicator how people encountered this in the first place.

jcmoyer• 2 years ago

Without compiler bugs, on stock Linux, you can achieve the same thing via /proc/self/mem.

The documentation addresses this case specifically: https://doc.rust-lang.org/stable/std/os/unix/io/index.html#p...

"Rust’s safety guarantees only cover what the program itself can do, and not what entities outside the program can do to it. /proc/self/mem is considered to be such an external entity..."

fweimer2• 2 years ago

The /proc/self/mem thing shouldn't be a problem because you won't run into it accidentally. What I'm wondering if this compiler bug is in the same category, or if a Rust programmer is somewhat likely to run into this bug by accident (or other I-unsound compiler bugs) if their approach is more or less “tweak things until they typecheck and pass the borrow checker”.

Cve-rs: Fast memory vulnerabilities, written in safe Rust

Related Stories