The call to localtime_r may be unsound

[quininer]

I found that getenv and setenv in libc are not thread-safe [1], and most impl of localtime_r in libc directly call getenv [2]. This means that localtime_r may have data race with setenv.

In order to ensure soundness of setenv, libstd add a lock to it [1], but this means that using getenv without libstd will be unsound.

This problem is not easy to reproduce on glibc, because glibc's localtime_r caches timezone. but using musl can easily reproduce it.

1. libstd: Add thread unsafety warnings around setenv() and unsetenv() rust-lang/rust#24741
2. https://github.com/aosp-mirror/platform_bionic/blob/master/libc/tzcode/localtime.c#L1321 and https://git.musl-libc.org/cgit/musl/tree/src/time/__tz.c#n127

POC: https://gist.github.com/quininer/2063c31b0bc1753989122e782b182bea

[dekellum]

Rust libstd has a similar, long open issue, for its own calls to getaddrinfo: rust-lang/rust#27970

[quodlibetor]

Thank you for this!

From reading the associated issues, it seems like touching the environment is the thing that glibc actually considers to be non-thread-safe, is that right? In particular rust-lang/rust#27970 (comment) in particular, it seems like libc wants modifying the environment to be illegal in a multithreaded environment:

functions that modify the environment are all marked with const:env and regarded as unsafe. Being unsafe, the latter are not to be called when multiple threads are running or asynchronous signals are enabled, and so the environment can be considered effectively constant in these contexts, which makes the former safe.

I agree that the solution in the rust stdlib getaddrinfo issue (being able to take the env lock) would help.

I'm trying to think of a good solution here, and it's hard because none of the underlying libraries (libc or stdlib) provide us with the necessary tools. In particular, even if the stdlib provided us with access to the env lock, any other code that interacts with libc directly could inadvertently call setenv and leave us in the same situation. That would qualify as going outside of the safety properties rust is supposed to provide, though.

[Arnavion]

For anyone landing here from CVE-2020-26235 that states:

In Rust time crate from version 0.2.7 and before version 0.2.23, unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. [...] The issue was introduced in version 0.2.7 and fixed in version 0.2.23.

... the CVE text is misleading and the issue affects time 0.1 as used by chrono too. See time-rs/time#293 (comment) for details.

Edit: But also, note that the time 0.1 dependency doesn't actually matter because the call of locatime_r happens directly by chrono, not through time. See #602 (comment)