-
-
Notifications
You must be signed in to change notification settings - Fork 271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The call to localtime_r
may be unsound
#293
Comments
First off: thanks! It's a nice find. What would be an appropriate fix for this? Mainly for myself: this is the sole location this function is called. |
I don't think there is any quick solution, we may have to reimplement |
Ping @ymtvx, who created the original implementation. I'm not terribly familiar with these C APIs. What output are you expecting from the snippet provided? |
@jhpratt Oh, I realized that I paste wrong code and it has been updated. POC code will crash. |
In addition, I found that when using |
So what is actually causing the segfault? Just trying to determine the true root cause so that I can figure out what action to take. I've never used lldb before, so all I see is the basic segfault message when running. |
To be more specific, Rust's libstd avoids this problem by locking |
Rust libstd has a similar, long open issue, for its own calls to Like In the linked issue, it is contemplated using the libstd internal ENV lock around calls to |
So instead of worrying about concurrent env modification, you could read the env variable on startup and cache it, and avoid any calls to real getenv. If you want to be fancy you could intercept setenv and update the cached value in a thread safe way. |
@hlavaatch That would add an up-front cost for everyone, which isn't desirable. It would also prevent the user from changing the TZ while the program is running. With regard to intercepting setenv, what do you mean? This crate has no control over what users write. |
I have created a draft security advisory on GitHub for this, and have requested a CVE. If granted, I will then file an advisory over at RustSec/advisory-db. Time 0.2.23 was released earlier today, which avoids the issue entirely by not attempting to determine the local offset on Unix-like operating systems. |
A security advisory has been published on GitHub. This issue has been assigned CVE-2020-26235. |
Closing this issue as the unsoundness does not exist on the most recent release. In addition, a security advisory has been issued on this repository, a CVE has been issued, and a rustsec advisory has been issued. I don't think there's much more I can do at this point. |
Couldn't we implement |
@osa1 There is presumably some way to work around this, yes. Feel free to put together a pull request if you have sufficient knowledge — the previous code was just commented out, not removed completely. The problem is more the call to |
What do you mean by this? |
Note to anyone else finding this. It is marked "closed", but as of 2020-12-18, all the local-offset methods are still unusable on the main branch on unix platforms, as they always return Err. |
Version 0.4 had a transitive dependency on a version of the 'time' crate that was triggering security alerts (see [1]). It's not a terribly critical problem and I'm pretty sure unlikely to cause us any vulnerabilities or other problems in practice, but the new gpiocdev trims its dependencies to avoid the problem entirely and is hence nicely a bit lighter-weight, so updating seems like a win-win. [1] time-rs/time#293
There is a long-standing problem (time-rs/time#293) that has not yet been solved by time-rs Switch to chrono as it seemed to solve the problem (chronotope/chrono#677)
There is a long-standing problem (time-rs/time#293) that has not yet been solved by time-rs Switch to chrono as it seemed to solve the problem (chronotope/chrono#677)
…ystem There is a long-standing problem (time-rs/time#293) that has not yet been solved by time-rs Switch to chrono as it seemed to solve the problem (chronotope/chrono#677)
There is a long-standing problem (time-rs/time#293) that has not yet been solved by time-rs Switch to chrono as it seemed to solve the problem (chronotope/chrono#677)
Version 0.4 had a transitive dependency on a version of the 'time' crate that was triggering security alerts (see [1]). It's not a terribly critical problem and I'm pretty sure unlikely to cause us any vulnerabilities or other problems in practice, but the new gpiocdev trims its dependencies to avoid the problem entirely and is hence nicely a bit lighter-weight, so updating seems like a win-win. [1] time-rs/time#293
because
getenv
andsetenv
are not thread-safe,localtime_r
in time may data race withstd::env::set_var
in libstd.I described this problem in chrono issue, and time is also affected.
Edit from @jhpratt:
Chrono users please see this comment.
The text was updated successfully, but these errors were encountered: