RUSTSEC-2020-0159: Potential segfault in localtime_r invocations

[github-actions]

Potential segfault in localtime_r invocations

Details
Package	chrono
Version	0.4.19
URL	chronotope/chrono#499
Date	2020-11-10

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.

[djmitche]

I don't think this is a serious issue for us since (a) we don't do much with local time and (b) we're not operating on untrusted data or with any privilege escalation. Also we're not at 1.0 yet :)

But, when there's a workaround or fix available, let's adopt it.

[dbr]

Agreed, doesn't seem particularly relevant to TC

chronotope/chrono#499 (comment)

To give some idea about how vulnerable your chrono-using program is, note that the issue happens specifically when two things happen simultaneously:

1. Something in your program changes the process environment. This could be via std::env::set_var, or directly with libc, or something that isn't even a Rust thread.
2. Something in your program program calls chrono::Local::now()

chronotope/chrono#499 (comment) is also interesting - essentially this seems to basically be a problem in libc

Most interestingly I learned that chrono, despite seeming quite a core Rust crate, was only maintained by a single person. Hopefully that situation is helped by all this noise around this bug

[djmitche]

I had a look through that issue -- yeah, this does seem a very tough one to solve. I wish the security audit wouldn't make all the PRs fail because of it!

[djmitche]

I think this is no longer an issue, but was never really an issue for TC.