Stream: wg-secure-code

Topic: RUSTSEC-2019-0011: memoffset


Tony Arcieri (Jul 23 2019 at 05:26, on Zulip):

I thought I'd split this advisory off into its own topic because it continues to be a particularly interesting case study

Tony Arcieri (Jul 23 2019 at 05:27, on Zulip):

it's one of those cases where the initial severity was underestimated, but the practical exploitability was low... and a lot of people deemed it noise

Tony Arcieri (Jul 23 2019 at 05:27, on Zulip):

based on the number of people who pinged me about it, it was quite noisy, and there was not a particularly clear path forward for a lot of crates which rely on it as a dependency

Tony Arcieri (Jul 23 2019 at 05:29, on Zulip):

I got some pings about adding some kind of exploitability metrics that can be filtered by, but I wonder if this advisory is a good use case for a more fine-grained static analysis of if particular applications are actually impacted

Tony Arcieri (Jul 23 2019 at 05:30, on Zulip):

there are definitely a few existing tools that could potentially be tapped for that purpose

Tony Arcieri (Jul 23 2019 at 05:31, on Zulip):

but in the meantime the exploitability jumped a few times as it was further scrutinized... to memory exposure and then RCE

Thom Chiovoloni (Jul 23 2019 at 05:33, on Zulip):

in the code at my workplace we ended up ignoring it because there's no path to update (crossbeam-deque is required by tokio, and uses memoffset 0.2 or something). this is far enough removed that i have no clue if the code in question is actually vulnerable, since almost certainly that depends on how it's being used in crossbeam-deque/tokio.

Tony Arcieri (Jul 23 2019 at 05:34, on Zulip):

I just recommended --ignore to a few people

Tony Arcieri (Jul 23 2019 at 05:35, on Zulip):

good thing I shipped that last week :grimacing:

Thom Chiovoloni (Jul 23 2019 at 05:46, on Zulip):

It's unfortunate. Some digging shows that the use in crossbeam is at least probably not vulnerable to RCE (which would be my largest concern), since it isn't used on a field with a custom deref coersion. still though, it's hard to evaluate an issue like this used in transitive dependencies

RalfJ (Jul 23 2019 at 09:20, on Zulip):

yeah, I bumped the version in crossbeam without having to change anything, so there was no deref coercion involved at least in latest git crossbeam

RalfJ (Jul 23 2019 at 09:20, on Zulip):

now this is "just" waiting on https://github.com/crossbeam-rs/crossbeam/issues/401

RalfJ (Jul 23 2019 at 09:22, on Zulip):

I guess the more general question is: unsafe can be "sealed" behind an sbatraction; if an API is unsound (like memoffset) but a project only uses it transitively through another crate that does not "exploit" the unsafety... how should that be handled? We can have an advisory for the unsound crate, and people should bump if they depend on it directly, but there is little they can do about transitive dependencies and in many cases there actually is no harm done by using the old version.

Shnatsel (Jul 23 2019 at 17:27, on Zulip):

in many cases there actually is no harm done by using the old version

Exploitability analysis is ridiculously hard. It's usually easier to just get rid of the potentially problematic thing than to analyze if it's exploitable or not.
There are tons of cautionary tales about people looking at a known-broken system but deeming it not exploitable, and then someone else coming along and exploiting the hell out of it. See e.g. the case of M$ and MD5

RalfJ (Jul 23 2019 at 19:48, on Zulip):

fair

RalfJ (Jul 23 2019 at 19:49, on Zulip):

OTOH, the "uninit drop" soundness hole in memoffset is fixed by adding an extra check

RalfJ (Jul 23 2019 at 19:49, on Zulip):

so if code just compiles after adding that check, it already didnt exploit the hole before (on that platform, with the same features)

RalfJ (Jul 23 2019 at 19:50, on Zulip):

and looking at https://github.com/crossbeam-rs/crossbeam/issues/401 I feel a bit bad, in particular breaking people's CI until crossbeam can make a new release seems a bit over-the-top (I had no idea people run cargo audit on CI)

Tony Arcieri (Jul 23 2019 at 20:09, on Zulip):

@Shnatsel the one bit of automated exploitability analysis we could potentially do is checking if any of the affected codepaths are actually used by the app in question

Tony Arcieri (Jul 23 2019 at 20:10, on Zulip):

via call graph analysis

Shnatsel (Jul 23 2019 at 20:19, on Zulip):

@RalfJ people only run it on CI because there is no proper security update mechanism in Cargo. CI is not the right way to deal with this. But that's a story for another time.

Tony Arcieri (Jul 24 2019 at 15:19, on Zulip):

https://github.com/tokio-rs/tokio/issues/1345

Last update: Nov 11 2019 at 22:45UTC