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.

[kflansburg]

chronotope/chrono#578

[kflansburg]

Some sentiment in the community seems to be that chrono is unmaintained and projects should move to time 0.3. We will have to wait for all of our dependencies to make that change if it is to happen.

cargo tree --package time --invert

time v0.1.44
└── chrono v0.4.19 (/Users/kevin/moose/krator-rs/chrono)
    ├── k8s-openapi v0.13.0
    │   ├── krator v0.5.0 (/Users/kevin/moose/krator-rs/krator/krator)
    │   ├── kube v0.60.0
    │   │   ├── krator v0.5.0 (/Users/kevin/moose/krator-rs/krator/krator)
    │   │   └── kube-runtime v0.60.0
    │   │       └── krator v0.5.0 (/Users/kevin/moose/krator-rs/krator/krator)
    │   │       [dev-dependencies]
    │   │       └── krator-derive v0.4.0 (proc-macro) (/Users/kevin/moose/krator-rs/krator/krator-derive)
    │   │   [dev-dependencies]
    │   │   └── krator-derive v0.4.0 (proc-macro) (/Users/kevin/moose/krator-rs/krator/krator-derive)
    │   ├── kube-core v0.60.0
    │   │   └── kube v0.60.0 (*)
    │   └── kube-runtime v0.60.0 (*)
    │   [dev-dependencies]
    │   ├── krator v0.5.0 (/Users/kevin/moose/krator-rs/krator/krator)
    │   └── krator-derive v0.4.0 (proc-macro) (/Users/kevin/moose/krator-rs/krator/krator-derive)
    ├── kube v0.60.0 (*)
    ├── rcgen v0.8.13
    │   [dev-dependencies]
    │   └── krator-derive v0.4.0 (proc-macro) (/Users/kevin/moose/krator-rs/krator/krator-derive)
    ├── tracing-subscriber v0.2.20
    │   └── tracing-opentelemetry v0.11.0
    │       [dev-dependencies]
    │       └── krator v0.5.0 (/Users/kevin/moose/krator-rs/krator/krator)
    │   [dev-dependencies]
    │   └── krator v0.5.0 (/Users/kevin/moose/krator-rs/krator/krator)
    ├── x509-parser v0.10.0
    │   └── rcgen v0.8.13 (*)
    └── yasna v0.4.0
        └── rcgen v0.8.13 (*)

krator usage of chrono:

• kube: Looks like author is currently deciding whether to stick with Chrono or move to time 0.3. link
• k8s-openapi: author commented in same kube thread, and on chrono issue. Does not believe it will be practical to make the move due to popularity of chrono, and noted that chrono needs to patch is use of localtime_r as well, and not just update time.
• rcgen: Does not appear to be aware of the issue.
• x509-parser: Does not appear to be aware of the issue.
• yasna: Does not appear to be aware of the issue.

krator-derive usage of chrono:

• rcgen (dev-dependency)

chrono is also used by the Moose example, if we wish to remove it there:

• Moose example: This does not appear to be used and can be removed.
• tracing-subscriber: There is an issue tracking this. It looks like users can disable chrono by manipulating crate features, but it is not yet possible to replace the functionality with time.

I believe that krator is unaffected. I forked chrono and removed its use of localtime_r, and all dependent call sights, and krator compiled without issue. See fork. It is possible that there is still a usage in the time crate, but I believe the fact that we are not using localized time functionality makes it unlikely.

cc krustlet/krustlet#688

[kflansburg]

Confirmed that we do not make use of localtime_r in time either, see fork.

Its possible that I missed usage behind other features / architectures. Tested on stable-aarch64-apple-darwin with default features for chrono and time.