Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent functions info in affected #940

Open
another-rex opened this issue Aug 14, 2023 · 1 comment
Open

Inconsistent functions info in affected #940

another-rex opened this issue Aug 14, 2023 · 1 comment

Comments

@another-rex
Copy link

another-rex commented Aug 14, 2023

I am trying to use RUSTSEC advisory's affected functions info to determine whether code using a "vulnerable" dependency is actually affected or not for the https://github.com/google/osv-scanner tool. (google/osv-scanner#452)

Essentially #21, but using a more naive approach by relying on the compiler optimizing out uncalled functions, which seems to work pretty well in practice. However this requires the functions field to be pretty strict for it to be useful and avoid false negatives/positives.

The definition for the functions field is:

# The path syntax is `cratename::path::to::function`, without any
# parameters or additional information, ...

But I found some (invalid?) "functions" info that doesn't match the above description:

  • RUSTSEC-2019-0037 lists a trait implementation instead of the function
  • RUSTSEC-2021-0073 also lists a trait impl, and this time with a generic type as well
  • Multiple advisories lists macros in the functions field as well (Add affected field macros #664)
  • RUSTSEC-2020-0070 lists multiple structs instead of functions

I understand specifying the exact trait impl is accurate than just the function without any parameters, it would be very useful if these can be moved to separate fields so that functions only has functions in it, to reduce the amount of false negatives in tooling consuming this data.


Just for reference here are some of the functions symbols that LLVM emits after being demanged, which is what most call analysis tools will be taking in and have to change to match against the RUSTSEC affected info:

<prost_types::Timestamp as core::convert::From<std::time::SystemTime>>::from // RUSTSEC-2021-0073
smallvec::SmallVec<A>::insert_many // RUSTSEC-2021-0003
<libflate::gzip::MultiDecoder<R> as std::io::Read>::read // RUSTSEC-2019-0010
libflate::huffman::EncoderBuilder::new
@tarcieri
Copy link
Member

We currently have no lint for this information in rustsec-admin.

I'm hoping Painter can potentially be a source of truth for it: rustfoundation/painter#7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants