RUSTSEC-2020-0071: Potential segfault in the time crate

[github-actions]

Potential segfault in the time crate

Details
Package	time
Version	0.1.44
URL	time-rs/time#293
Date	2020-11-18
Patched versions	>=0.2.23
Unaffected versions	=0.2.0,=0.2.1,=0.2.2,=0.2.3,=0.2.4,=0.2.5,=0.2.6

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.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3. series.

Workarounds

No workarounds are known.

References

time-rs/time#293

See advisory page for additional details.

[jedel1043]

Uhhhh time v0.1.45 still appears in our Cargo.lock. Reopening this.

[Razican]

This appears in our Cargo.lock as a transitive dependency, since chrono depends on it and zip too.

In theory, we shouldn't use it in chrono, since we have deactivated the oldtime feature. In any case, as soon as chrono 0.5 gets released, this should disappear.

The zip case is a bit more cumbersome. We use zip 0.5 as a transitive dependency, but zip 0.6 no longer depends on time 0.1, and it depends on time 0.3, which is not affected.

We have 3 dependencies that depend on zip 0.5:

• cached-path: We use the 0.5 version, because icu_datagen depends on it.
• zip-extensions: non-maintained crate, cached-path 0.5 depends on it.
• icu_datagen: This is the main issue. This was solved by fix: RUSTSEC-2020-0071 unicode-org/icu4x#3150, but a new release has not been published in crates.io yet.

Maybe @Manishearth has some information about a potential future release with this fix :)

[Manishearth]

So datagen should only be a build time dep for y'all, and AIUI the vulnerable APIs are not used by the tree (it's a rather tricky bug to trigger).

We're not really planning on doing a patch release for datagen, ICU4X 1.3 should be out within a month or so. You can just wait it out, or perhaps get zip/cached-path to publish backports.

We're open to doing a patch release for this but we'd really rather not.

[Razican]

So datagen should only be a build time dep for y'all, and AIUI the vulnerable APIs are not used by the tree (it's a rather tricky bug to trigger).

We're not really planning on doing a patch release for datagen, ICU4X 1.3 should be out within a month or so. You can just wait it out, or perhaps get zip/cached-path to publish backports.

We're open to doing a patch release for this but we'd really rather not.

No need for a patch release, we can wait for 1.3 :)

[jedel1043]

Time 0.1 no longer appears in our Cargo.lock :)