I've seen this question come up in several forms, I often get pointed at cargo audit and multiple competing products. I've seen a range of clippy lints for safety practices and so on.
But I'm up against people that are used to seeing more specific security detections, such as scans for use std::process::Command; Command.new(userinput), and it would really help if I could say something other than "no"
I'm wondering what cheap and dirty capabilities may exist to, for example, clippy lint that the above a banned function? Have I missed any opportunity for this sort of thing to be detected in my searching?
I don't understand how that's "more specific". Clippy lints are also specific. There is a myriad of ways to cause security issues; no tool can realistically anticipate detecting all of them.
Clippy's infrastructure is general enough that you could reasonably easily write up a lint against Command::new(user_input), I think. Ultimately, if you are looking for a list of such lints, there's no way other than implementing them one-by-one if they don't exist.
Until then, maybe rg 'Command::new\([^"]' -g 'src/**/*.rs'?
I may have used the wrong word in saying "more specific", but you appear to agreeing it's not that I'm simply unaware of an existing repo of such lints, so a few custom lints might be the answer to work on. Thanks!
If this would be an option for you, clippy has a lint called disallowed-methods you could use to completely forbid use of Command::new. You can view all lints under this page.
To add a method you would like to forbid or warn about, you can create a clippy.toml file with the following content:
disallowed-methods = [
{ path: "std::process::Command::new", reason: "Spawning of untrusted new commands is considered a security risk" },
]
This way, cargo clippy will warn you every time you use the specified method.
Clippy has options to forbid the use of certain functions/types/macros. They are found under disallowed_*. The webpage lists all clippy lint and you can check if there are others that match your need.
semgrep has some preliminary Rust support: https://semgrep.dev/p/rust
The ruleset seems to be quite small right now, but you can define rules for your repositories or contribute some upstream.
Unfortunately, clippy can be bypassed. A malicious crate can even attack the machine that runs clippy. Crates with build.rs or proc-macro crates can run arbitrary commands at build time.
You will also need to ban #[no_mangle] and #[link], because they allow replacing any function anywhere, giving ability to run arbitrary unsafe code in non-obvious ways.
If you need your dependencies to be secure, you'll need to review their code. Check out cargo-crev and cargo-vet.
Automated scanners are just a box-ticking exercise that leads to hundreds of notifications about "critical" ReDoS "vulnerabilities", but won't stop an actual attack (the attackers can run the scanner too to make sure it's undetected).
@jonasbb@leob Thanks, I've started using some disallowed_types right now, it looks like a pretty good solution.
@kornel If someone wants to write bad or vulnerable code they will, I don't see that as avoidable. I've seen a tonne of web apps that called exec() directly on user input not because someone wanted to be malcious, but because a web developer didn't know better. Several free utilities work well in this space.
I'm completely salty about the reDoS "vulnerability" situation, but that's caused by something Rust already supports (cargo audit, detecting announced CVE's).