flate2-rs unsound due to calls to `getenv` allowing safe data race

[xerxes12354]

rust-lang/flate2-rs#272

Closed without being addressed leaving security vulnerability. Unsound.

[thomcc]

This is honestly a bug in the stdlib that setenv is exposed in safe code.

Work is underway to potentially fix this in the stdlib, although it's tricky to find a way without breakage. In the meantime though, I'm kind of with Alex here that going "looking for FFI crates where this could be a problem" isn't exactly helpful 🤷

[tarcieri]

Based on a quick look I agree. We don't tend to track transitive unsoundness and would rather track a vuln against std for this.

If we don't already have one for this (I don't see one) I'd suggest filing a soundness vuln against std. But even that seems tricky as I don't see a canonical upstream tracking issue for this. This is the closest I've seen so far:

rust-lang/rust#27970
https://github.com/rust-lang/rust/pull/24741/files

It seems like set_var is a huge footgun and perhaps unfixable in its current form, but there's not much consensus about what to do about it.

[xerxes12354]

You cannot create soundness bug using only Rust with this, flate2-rs allows this to occur by unsoundly exposing an unsafe API.

[thomcc]

Again, the bug here is in the stdlib exposing the setenv API as safe in the first place. I suspect the logic you're using is the one that was used at a time, but it's flawed: Rust doesn't exist in a vacuum. For years, C code has held that setenv is unsafe to use in the context of multiple threads, but that getenv is safe (this fact is even documented as part of POSIX). This API is too pervasively used to imagine that realistically Rust can assume safety given that the only users of it are from within Rust.

Note that in many cases, there's no viable solution here for C bindings. In some cases you can cut out the functionality or make it an unsafe fn, in others you can patch the original C library, but even that isn't always viable¹.

IMO, Rust should change the behavior of the std::env::set* functions to only impact the environment as viewed by std::env::var* (and by other rust-visible things like std::process), although possibly this should only take effect after the first thread is spawned.

Also, in practice, this isn't a problem 99% of the time, which is why despite the same issue being present in libstd, it still hasn't been fixed yet. Don't get me wrong: it should be fixed, but... realistically, nobody who isn't setting out to try and trigger this sort of bug will hit it. You have to aggressively perform set_var in a loop from a different thread than the reader, and that just isn't common behavior.

Again, this isn't to say that things are fine without a fix here, but just to say waiting on a fix from stdlib is probably fine, rather than either arguing every C library binding needs to do something about a stdlib soundness hole.

---

¹ And even if patching is viable (e.g. in -sys crates that bundle/vendor) it is honestly kinda dodgy. Personally, I would really rather random -sys crates I use not be applying various custom patches to the underlying C libs they're binding to, especially for something unlikely to cause issues like this.

[jhpratt]

nobody who isn't setting out to try and trigger this sort of bug will hit it.

While I initially said the same thing, it turns out this isn't true. Here's a user saying that the bug (in time & chrono) was discovered in real-world usage.

Personally, I made the decision to eliminate the unsound behavior, though I am reconsidering that decision.

[leo60228]

You cannot create soundness bug using only Rust with this, flate2-rs allows this to occur by unsoundly exposing an unsafe API.

I'm not sure how relevant this is, but wouldn't this implementation of setenv be perfectly POSIX-compliant?

#[no_mangle]
pub unsafe extern "C" fn setenv(key: *const c_char, value: *const c_char, overwrite: c_int) -> c_int {
    if get_running_threads() > 1 {
        unreachable_unchecked()
    } else {
        real_setenv(key, value, overwrite)
    }
}

[tarcieri]

I'm not sure how get_running_threads is intended to be implemented, but regardless that has an inherent race / TOCTTOU in that threads can be created after you invoke it.

Also in what way is the existence of more than one thread "unreachable"? If there's more than one thread, that appears to have undefined behavior.

From what I can tell the only way to soundly implement this sort of thing is acquiring the OS-specific environment lock:

• https://github.com/rust-lang/rust/blob/074f63648bd2368d5ca19aed02b5763a144e5d05/library/std/src/sys/unix/os.rs#L489-L493
• https://github.com/rust-lang/rust/blob/074f63648bd2368d5ca19aed02b5763a144e5d05/library/std/src/sys/unix/os.rs#L531-L554

...and since that isn't directly exposed, the only way to do so is by (vicariously) invoking e.g. std::src:sys::unix::os::{getenv, setenv}

[leo60228]

I was using Rust syntax as an example. My point was that, to my knowledge, calling setenv in the presence of multiple threads is UB according to POSIX.

[tarcieri]

FYI, I opened a rust-internals thread asking if it would make sense to expose functions for obtaining ENV_LOCK in Unix environments:

https://internals.rust-lang.org/t/synchronized-ffi-access-to-posix-environment-variable-functions/15475

[tarcieri]

I was using Rust syntax as an example. My point was that, to my knowledge, calling setenv in the presence of multiple threads is UB according to POSIX.

Yes, notably setenv(3) is marked as MT-Unsafe by glibc: https://www.gnu.org/software/libc/manual/html_node/Environment-Access.html

[tarcieri]

Also, I've changed my mind from my earlier position. I think it would make sense to go ahead and file an advisory for this.

AFAIK there's no change to std possible which will make the existing implementation of flate2 sound in and of itself, only new APIs which flate2 can possibly consume in the future, and given that, we should probably file an advisory.

[thomcc]

AFAIK there's no change to std possible which will make the existing implementation of flate2 sound in and of itself

This isn't true. Here are some of the possible changes that would fix

1. Well, making env::set_var an unsafe function. Which it should be, given that adding locks isn't really/always sufficient to make a MT-Unsafe function safe.
2. Making it so that env::set_var changes are only visible to Rust, possibly deferring this until a second thread has been spawned

The ship has probably sailed for 1, but last I checked, 2 was still being discussed. There are likely others still as well.

[RalfJung]

regardless that has an inherent race / TOCTTOU in that threads can be created after you invoke it.

I don't think it has: if there are no other threads right now, then that means there are also no threads that could be spawning new threads that would make this a race.

[tarcieri]

@thomcc I don't see how 1 helps. The problem is one of synchronization, and in that regard it already has locks and provides a safe API.

The problem is one of unsoundness if there is another caller which isn't participating in that synchronization. Slapping unsafe on it isn't a solution if there's no sound way to use it.

I don't think it has: if there are no other threads right now, then that means there are also no threads that could be spawning new threads that would make this a race.

Aah, indeed...