Comments (15)
Hmm ... hard question.
Pros for listing public affected paths are that these are easy to consume for most users.
Problems are that whoever writes the advisory has to build a call graph or data flow graph to see where they are being used (as you said), so there is more potential for wrong hard-coded information in the advisory.
Pros for listing just the offending (maybe private, maybe public) functionality is that it is easy to do for the advisory creator, it is easiest to check for correctness and it keeps the advisories short (this might be an important practical argument). In theory, once we have the directly affected paths, we can just auto-expand to all affected paths in the module. Of course, the danger is that people take a quick manual look at the advisory, see they're not using anything of what is listed under affected_paths
directly and wrongly assume they're safe. Maybe a simple fix of this would be to rename the attribute to root_cause_paths
. Also, another argument for listing what is directly affected might be Rust's re-export feature, or if reflection will be further developed, one can no longer assume it is impossible to get access to private paths. Thus it seems that the root_cause_paths
solution is also more future proof.
I also discussed this with @jhejderup, and like you, we see pros and cons for both approaches, but in the end, would only mention the root cause paths. Main arguments are that it is easy for the advisory creator, it keeps the advisories short, it does not include parts that can be auto-generated (transitive uses), and it seems to be more future-proof.
from advisory-db.
Both syntaxes will work, although we can document the first one.
from advisory-db.
An alternative to listing both under [affected_paths]
is having advisory reporters continue to document the most relevant user-facing functions in the advisory description, which is what they're doing already organically.
from advisory-db.
@vks right now the path parser doesn't support parameters, so it'd be crate::Type::method
.
I'm not sure it's worth the effort to disambiguate in the case there are methods with the same name in multiple traits impl'd on the same type: it's fairly uncommon, and even if it were to happen that there's a vulnerability in a method with the same name impl'd in multiple traits, where the code in question happens to be using the not-vulnerable method of a different trait, the worst case is a false positive in the taint analysis, which is the state of affairs for everything today.
from advisory-db.
I think we should just collect a canonical path starting with the crate name, and sans any parameters as an optional attribute of the advisory.
Using the advisory from the above description as an example:
affected_functions = ["smallvec::SmallVec::insert_many"]
from advisory-db.
Sorry to chime in on this after it's been merged.
One problem with the current design is that it does not allow for the specification of a version.
Why could this be important?
Some security bugs affect quite a broad change of versions of a crate, and as such, the vulnerability might itself be subject to refactoring, renames, etc. So just specifying a name in affected_functions
is perhaps overly simplistic.
Example
v1 introduce vulnerable function f1
v2 rename f1
to f2
v3 introduce new function f1
, which is not vulnerable
v4 fix vulnerability in f2
Just naming all affected_functions f1
and f2
is not a great solution, because f1
would be considered vulnerable from v2 to v3, even though we know it isn't.
What would the change proposal be?
For each function, add a range of affected versions.
affected_functions = [ ["f1","<2"], ["f2",">2 <4"]]
What are the consequences of the proposed change?
- It makes the declaration of this array more complicated.
- It increases precision and resolves possible ambiguities. I don't know how often this would occur in practice.
Another question would be whether we would want to restrict this to functions, only. Couldn't a data structure have a vulnerability, too?
from advisory-db.
Haha, no worries.
Modifying the existing affected_functions
might be tricky, but we can just abandon it, especially as this is a good reason:
Another question would be whether we would want to restrict this to functions, only. Couldn't a data structure have a vulnerability, too?
I definitely agree with this. There have been a few advisories filed which don't pertain to a function, but e.g. C FFI-related memory corruption (e.g. RUSTSEC-2018-0011
).
How about this:
- Deprecate and remove
affected_functions
. We can delete the existing ones. - Add a new attribute called
affected_paths
. How about using a TOML table where the keys areVersionReq
s? e.g.
[affected_paths]
">= 1.0.0, < 1.2.3" = ["mycrate::foo::bar"]
"1.2.3" = ["mycrate::foo::baz"]
Or (these are two different TOML syntaxes for the same thing):
affected_paths."1.2.3" = [
"mycrate::foo::bar",
"mycrate::foo::baz",
"mycrate::foo::quux",
]
from advisory-db.
That sounds good!
Personally, I would prefer the first affected_paths syntax you have given.
from advisory-db.
We need to decide and document whether affected_paths
should list public functions so that humans could cross-reference them with their codebase, or private functions that are the root cause of the issue because that's what enables the most precise machine analysis.
from advisory-db.
It could potentially list both. Curious what @Inventitech thinks
from advisory-db.
Listing both would probably result in conflicting information, too much room for human error, and increased burden for filing advisories.
from advisory-db.
We tried using the new syntax in #89, which provides a pretty good real-world example:
[affected_paths]
">= 0.4.0, <= 0.10.0" = ["safe_transmute::guarded_transmute_vec_permissive"]
"= 0.10.0" = ["safe_transmute::guarded_transmute_to_bytes_vec"]
This now has me wondering if instead of a map from paths to VersionReq
s, it should be the other way around:
[affected_paths]
"safe_transmute::guarded_transmute_vec_permissive" = [">= 0.4.0, <= 0.10.0"]
"safe_transmute::guarded_transmute_to_bytes_vec" = ["= 0.10.0"]
(although ironically this seems to be breaking GitHub's TOML parser?)
Perhaps we should use an array of tables instead?
[[affected_path]]
name = "safe_transmute::guarded_transmute_vec_permissive"
versions = [">= 0.4.0, <= 0.10.0"]
[[affected_path]]
name = "safe_transmute::guarded_transmute_to_bytes_vec"
versions = ["= 0.10.0"]
from advisory-db.
This now has me wondering if instead of a map from paths to
VersionReq
s, it should be the other way around:
IMHO, it should (see my post #68 (comment)). Anyway, this is only a minor change.
Your other suggestion seems a bit more verbose than needs-be, by repeating [[affected_path]].
from advisory-db.
@Inventitech another way of writing the same thing is:
affected_paths = [
{ name = "safe_transmute::guarded_transmute_vec_permissive", versions = [">= 0.4.0, <= 0.10.0"] }
]
Your version is pretty close to that, aside from using nested arrays instead of an array of tables.
The reason for the more verbose form is the less verbose form seems to freak out TOML parsers (see the other version in my GitHub comment).
from advisory-db.
@tarcieri How would you specify implemented methods of a trait? crate::<Type as Trait>::method
?
from advisory-db.
Related Issues (20)
- serde-yaml is unmaintained
- retain_mut is deprecated HOT 3
- cargo-asm might be unmaintained HOT 1
- openslide is unmaintained
- All crates inside byron/google-apis-rs are now unmaintained (google-drive3, google-youtube3, etc.) HOT 1
- isahc might be unmaintained
- zip crate (unmaintained? Change of ownership?) HOT 5
- CI failed to detect leftover placeholder link
- UB fixed in smallvec >= 1.13.2
- Memory corruption fixed in smallvec 2.0.0-alpha-6 HOT 1
- Clarify RUSTSEC-2020-0071 to mention that time was *setting* environment variables HOT 3
- ppv-lite86 appears unsound HOT 2
- adler is archived HOT 14
- opentelemetry-jaeger is removed from the github project
- opentelemetry_api is removed from the github project HOT 1
- servo-fontconfig is unmaintained
- flate2 has been creating a slice of uninitialized memory HOT 5
- proc-macro-error is unmaintained
- async-priority-channel is unmaintained, and broken
- `winapi` is (now actually) unmaintained HOT 22
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from advisory-db.