Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 2, 2022 22:26 UTC (Fri) by riking (subscriber, #95706)
In reply to: Memory Safe Languages in Android 13 (Google security blog) by atnot
Parent article: Memory Safe Languages in Android 13 (Google security blog)

Easy way to create a "Race condition" (as distinct from a "Data race") in Rust:

- Create a multi-producer, single consumer channel.
- Create two threads with different identities.
- Each thread sends its identity over the channel after it starts.
- Read the first value received from the channel and do something important with it.

The two threads race to be the first to deliver their value. An identical situation in Java is also easy to accomplish.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 12:02 UTC (Mon) by hmh (subscriber, #3838) [Link] (4 responses)

This is not even a bug when the processing order of the messages for the two threads doesn't matter to program correctness -- and it better not matter in any such design. But yeah, it is definitely undefined which thread will get its message processed first. Note that it might not even be racy, but rather system-dependent (where it *always* works out the same way in a given system, but it might change in a future version).

However, what _atnot_ described is known as "TOCTOU", and it is an extremely common race condition that is behind a lot of security vulnerabilities involving filesystems, for example. In this case, the program would be racing whatever else might be trying to manipulate that same filesystem resource. And it is extremely easy to screw this up in Rust just like it is in Java, C++, C, and most likely just about every other general purpose language.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 12:22 UTC (Mon) by khim (subscriber, #9252) [Link] (3 responses)

> And it is extremely easy to screw this up in Rust just like it is in Java, C++, C, and most likely just about every other general purpose language.

No. It's possible to do in Rust, but it's not easy (let alone “extremely easy”). If both producer and consumer are in your program then Rust's type system would, usually, stop you (read here about how it does that).

Of course if you would add communication to external systems (use Unix pipes or network for communication between pieces of one program, for example) then all bets are off, but I wouldn't characterise such design as “extremely easy”. Rather I would characterise it as “elaborately created footgun”.

Yes, they are possible, but you have to work to create them.

P.S. And yes, people often complain bitterly about that property of Rust when they invent clever footguns and Rust says it doesn't want to accept these. Just look on how some people avoid race conditions. And weep.

P.S. Actually read the whole thread. Because guy there treats race condition precisely and exactly like other here treat UB: I tested, it worked in C#, why compiler couple make it work for me in Rust? O_PONIES, O_PONIES, and more O_PONIES.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 16:07 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

> > And it is extremely easy to screw this up in Rust just like it is in Java, C++, C, and most likely just about every other general purpose language.

> No. It's possible to do in Rust, but it's not easy (let alone “extremely easy”). If both producer and consumer are in your program then Rust's type system would, usually, stop you (read here about how it does that).

Please. Stop. Engage. Brain. Before. Opening. Mouth.

You clearly don't understand what TOCTOU is (or, more likely, you forgot that was what we were discussing).

The problem is not preventing your program screwing it up. The problem is preventing an *external* *hostile* program taking advantage. If there is an easy way to prevent Rust from screwing *that* up, I'm sure many people will be all ears ... (Other than how I did it years ago in Fortran, files were configured NR&1W, everybody could open the file read-only, but to change it, you had to open it r/w, and then run the entire transaction from scratch.) Just because the Rust compiler blocks two threads in the same program messing up, doesn't mean it'll stop an unrelated trojan barging in on the party ...

Cheers,
Wol

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 17:22 UTC (Mon) by khim (subscriber, #9252) [Link]

> You clearly don't understand what TOCTOU is (or, more likely, you forgot that was what we were discussing).

TOCTOU may happen inside of one program, too. In fact if we are talking about things like Linux kernel then most TOCTOUs which caused security problems, happened inside of kernel, not outside of it.

> Other than how I did it years ago in Fortran, files were configured NR&1W, everybody could open the file read-only, but to change it, you had to open it r/w, and then run the entire transaction from scratch.

Today we have Rwlocks for that and you can [try to] upgrade reader lock to writer lock. But yes, Rust ensures more-or-less what you describe. Just on language level.

Yes, of course, by itself it's not a protection against external actors, but it greatly simplifies code which have to deal with external actors, too.

Memory Safe Languages in Android 13 (Google security blog)

Posted Dec 5, 2022 18:13 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I mostly find TOCTOU to be an API problem with not covering some use case that *appears* to be supported by a sequence of APIs but is actually wanted to be a single operation. *Most* of the time you can ignore things, but when you can't, it's usually pretty deep down where the operation needs to be addressed (e.g., "overwrite file if contents are different" or "delete if current user owns the file").