Stream: wg-secure-code

Topic: another CVE in old stdlib

Shnatsel (Feb 24 2019 at 20:00, on Zulip): - this is yet another case of a standard library bug that should have gotten a CVE, but didn't. I've notified the security team and they replied (again) that they don't support old Rusts, and do not intend to do anything about it. So I've applied for a CVE myself.
It affects 1.18.0 onwards and was fixed just recently, in 1.30.0. The same attack vector causes a stack overflow on 1.17.0.

Alex Gaynor (Feb 24 2019 at 20:02, on Zulip):

Seems like a good arguments for getting these into rustsec. Where did we land on that @Tony Arcieri ?

Tony Arcieri (Feb 24 2019 at 21:57, on Zulip):

derp guess I haven't been keeping up here

Tony Arcieri (Feb 24 2019 at 21:57, on Zulip):

uhh I think we're mostly at consensus that it's a reasonable enough idea, and you cataloguing the known ones in a GH issue and... that's it

Tony Arcieri (Feb 24 2019 at 21:58, on Zulip):

next steps are how to represent them, whether we should distinguish e.g. std vs rustc vs (core? alloc?)

Tony Arcieri (Feb 24 2019 at 21:58, on Zulip):

and what the schema should be

Shnatsel (Feb 24 2019 at 22:13, on Zulip):

Fortunately a binary scanner is dead simple because rustc already encodes its version and LLVM version in everything it builds. UNfortunately, there is no way to tell if a particular function is used or not in an optimized binary, so we'll be showing false positives most of the time, by design. Also, linux distros cherry-pick fixes to earlier versions sometimes, further confusing everything.

Last update: Jan 23 2020 at 20:40UTC