Integration with Siderophile

[tarcieri]

Siderophile is a utility for locating unsafe hotspots in Rust programs and fuzzing them:

• Blog post: https://blog.trailofbits.com/2019/07/01/siderophile-expose-your-crates-unsafety/
• GitHub: https://github.com/trailofbits/siderophile

One of the things it does is a call graph analysis, somewhat similar to the ones performed by tools like cargo-geiger and RustPräzi (see also: rustsec/advisory-db#68).

The RustSec Advisory DB already contains metadata about the paths to impacted functions in an advisory as they relate to versions. It would be nice to use Siderophile to compute the call graph across --all-features of the parent crate, then use it to (perhaps optionally) test whether or not impacted/functions exist in the call graph.

Case study: memoffset

The following is a real-world RustSec case story where this sort of call graph analysis may have been helpful.

RUSTSEC-2019-0011 filed against the memoffset crate was an interesting vulnerability for several reasons:

• High severity: memory exposure and potential RCE. Furthermore, its initial severity was underestimated, and the impacted versions also retroactively expanded.
• Low exploitability: whether or not a particular project is impacted or not depended entirely on how the parent dependency which depends on memoffset was using it. This means that a low number of users received an important advisory about a high severity vulnerability, but for many others it was a false positive.
• Unclear resolutions: memoffset is used by many high-profile ecosystem crates including crossbeam. At the time we published the advisory there was no upgrade path available for many users, so they got an alert, but it was not actionable.

This combination of factors is exactly the sort of situation where it would be nice to eliminate false positives via call graph analysis. For users who were truly impacted by this advisory, it was RCE and they should absolutely be notified, but for most users it was just noise, and without a call graph analysis tool it was completely unclear which of these buckets a particular program fit into.

Eliminating false positives is something that must be done correctly: we don't want to fail to alert impacted users just to spare non-impacted users from annoying false positives. However, I think this sort of call graph analysis can be done precisely to where that is the case.