krator
krator copied to clipboard
RUSTSEC-2020-0071: Potential segfault in the time crate
Potential segfault in the time crate
| Details | |
|---|---|
| Package | time |
| Version | 0.1.44 |
| URL | https://github.com/time-rs/time/issues/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_attime::UtcOffset::try_local_offset_attime::UtcOffset::current_local_offsettime::UtcOffset::try_current_local_offsettime::OffsetDateTime::now_localtime::OffsetDateTime::try_now_local
The affected functions in time 0.1 (all versions) are:
atat_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.
https://github.com/chronotope/chrono/pull/578
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 totime0.3. link - [ ]
k8s-openapi: author commented in samekubethread, and onchronoissue. Does not believe it will be practical to make the move due to popularity ofchrono, and noted thatchrononeeds to patch is use oflocaltime_ras well, and not just updatetime. - [ ]
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 disablechronoby manipulating crate features, but it is not yet possible to replace the functionality withtime.
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 https://github.com/krustlet/krustlet/issues/688
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.