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.

[ionut-arm]

Hi!

Is anyone currently looking at this issue? I'd be interested to get a fix for this in (and also for CVE-2020-26235, by replacing chrono with a recent version of time) and hopefully a release afterwards, as cargo audit has been pestering us. Does this sound sensible?

[chifflier]

This issue is really annoying ...

• chrono does not seems really maintained
• we moved from time to chrono in 559f707 mainly because time broke compatibility in an upgrade and could not parse timezones anymore - I have not tested since
• x509-parser does not depend at all on time, since chrono has the feature disabled (see 59d3f59)

I do not fully get if x509-parser is affected or not by this advisory (it does not call localtime_r directly, but I'm not sure there is no indirect path), but for sure cargo-audit is noisy about that :/

[ionut-arm]

We have a similar problem - we don't know if anything in our call stack even touches localtime_r. Something like this would've been helpful.

[tomleavy]

Are there any alternatives to chrono, because I am having a problem where I can't use the crate due to cargo-audit complaining. Security team won't allow it.

[chifflier]

Are there any alternatives to chrono, because I am having a problem where I can't use the crate due to cargo-audit complaining. Security team won't allow it.

I'm removing chrono in the upcoming commits, at least for master. I'll see if a backport is possible (not sure, this would break the API) or if a new major release is required.

[chifflier]

Just adding a note, version 0.13.0 has been released and does not depend on chrono anymore (now it uses time).