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_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.
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 totime
0.3. link - [ ]
k8s-openapi
: author commented in samekube
thread, and onchrono
issue. Does not believe it will be practical to make the move due to popularity ofchrono
, and noted thatchrono
needs to patch is use oflocaltime_r
as 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 disablechrono
by 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
.