I thought I'd split this advisory off into its own topic because it continues to be a particularly interesting case study
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
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
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
there are definitely a few existing tools that could potentially be tapped for that purpose
but in the meantime the exploitability jumped a few times as it was further scrutinized... to memory exposure and then RCE
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.
I just recommended
--ignore to a few people
good thing I shipped that last week :grimacing:
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
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
now this is "just" waiting on https://github.com/crossbeam-rs/crossbeam/issues/401
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.
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
OTOH, the "uninit drop" soundness hole in memoffset is fixed by adding an extra check
so if code just compiles after adding that check, it already didnt exploit the hole before (on that platform, with the same features)
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)
@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
via call graph analysis
@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.