PR #268 added a security advisory related to plutonium, a crate that hides unsafe usage.

However, the security advisory does not report a security issue with the crate, or any defect with its intended functionality, but makes a value judgement about whether the crate's intended behavior is good.

Security advisories are not for "crates we don't like", they're for conveying information about defects in intended behavior.

Hi, The bigint library(https://github.com/paritytech/bigint) is a copy of very old code(written pre-1.0 in 2014) and contains a bunch of UB, including uninitialized memory, pointers out of bounds etc.

Even the simplest example triggers UB in miri: https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=5f059a27e245cad9f9e49be2b68678c8 (Sadly it seems that there's a bunch of cryptographic libraries depending on this https://crates.io/crates/bigint/reverse_dependencies )

Now that cargo-audit v0.9 is out with support for informational advisories, it would be good to start filing advisories for unmaintained crates.

Previous discussion around this topic:

• https://github.com/RustSec/advisory-db/issues/134
• https://internals.rust-lang.org/t/tracking-unmaintained-crates-using-rustsec/10884

Note that for users of older versions of cargo-audit which lack support for informational advisories, these advisories will appear as hard errors. There's not much we can do about that except have people upgrade to a newer cargo-audit release which does.

I'd propose including the version of the last crate release so that in the event unmaintained crates are maintained again and see new releases, we can filter those releases from these advisories automatically. So if the last release of a crate were 0.1.2, add:

unaffected_versions = ["> 0.1.2"]

Ideally we can also add a list of alternative maintained crates to consider so these advisories are actionable. We can always update this list retroactively in the event someone has a new alternative to recommend.

Here are some unmaintained crates that have come up in discussion and some suggested alternatives to recommend:

• [x] chan: recommend crossbeam-channel
• [x] libusb: recommend rusb
• [x] rust-crypto: recommend ring, RustCrypto (org), sodiumoxide
• [x] term: recommend termcolor

As of May 21st, 2022, https://github.com/dotenv-rs/dotenv 's latest version is 0.15.0, which was published on October 22nd, 2019. And the latest commit is 3c1a77bc95821777e5ceb996c5e0b082f2a3ea38, which was pushed on Jun 27th, 2020. On Dec 24th, 2021, someone asked the project status on Current maintenance state · Issue #74 · dotenv-rs/dotenv but there's no response from the maintainers. I'm not sure how long "prolonged period" refers to, but this crate is a candidate for an "unmaintained" crate, I think. At least we should monitor how things are going there.

Based on the discussion on #276, as well as on the "Security advisories for April 2020: rustqlite, os_str_bytes, flatbuffers" Reddit thread, it sounds like there are a number of people who do want to know about "unsound" crates (i.e. crates which present an unsound API in safe Rust), but do not in and of themselves contain a security vulnerability.

I think the best path forward here is to track these crates using informational advisories, similar to the ones we use for unmaintained crates. It'd be good to provide a precise technical definition of what is considered "unsound" (I'll defer to someone like @RalfJung for that), but in short: crates which provide APIs which do not uphold the invariants of safe Rust, or use unsafe in a way that does not uphold the invariants expected in correct unsafe code. Such crates don't contain a vulnerability in and of themselves (or else they would deserve security advisories), but can be misused by other crates in order to create code containing e.g. a concrete memory safety vulnerability.

We have both existing vulnerabilities in the database which fit this categorization, and some open requests to file them:

• #290: Add advisory for bigint
• #293: Advisory for rio
• #299: SmallVec < 0.6.13 is unsound

Now granted some of these are debatable as to whether or not they should be classed as a security vulnerability (e.g. #293). That said, it seems to me this information is worth collecting and this will likely keep coming up.

Informational advisories are surfaced as warnings by cargo audit (and cargo deny), and are therefore kept out-of-band of security vulnerabilities (they can be escalated to a hard failure via the user opting in).

Given the, I propose adding a new "unsound" categorization for informational advisories to the following enum:

https://docs.rs/rustsec/0.20.0/rustsec/advisory/informational/enum.Informational.html

After that, we can review existing advisories which would fit within this categorization, and proceed filing advisories for the above three crates (bigint, rio, smallvec)

97,514,713 downloads all time, ~200k a day which ~80k old < 1 versions

@saethlin raised this earlier too - https://github.com/rustsec/advisory-db/issues/1194 but more general discussion

I'm framing this issue on itoa crate issue -

I have some doubts that raising advisory would be too noisy as of right now as a transitive dep but just making the issue

plus @Nilstrieb @RalfJung @5225225 and @dtolnay as you've been across this as well ..

Should we raise informational = "notice" on itoa < 1.0.0 ... at some stage ?

To get the rest of the deps bump as there is actionable fix ?

Also maybe not now but e.g. after perhaps csv - it's largest user/s has/ve bumped up ?

csv (~50k downloads a day) is the most important user stuck on 0.4.8 issue open here: https://github.com/BurntSushi/rust-csv/issues/271

As itoa is not going to get backport and plenty people still using the old https://github.com/dtolnay/itoa/issues/36

Interestingly enough @RalfJung commented: https://github.com/BurntSushi/rust-csv/issues/271#issuecomment-1216789276

Status update on that: latest rustc nightly mitigates that UB by making mem::uninitiailized actually initialize the memory, which makes it slower. That means users of itoa 0.4 will see a performance degradation.

Other users of old num-format, serde_prometheus, lopdf, yarte_helpers, itoap, varisat-dimacs, json_in_type, plenty others

It would be nice if someone does outreach to these other crates

Ralf was quick - https://github.com/bcmyers/num-format/issues/29 - however num-format seems unmaintained

A panic safety issue has been pointed out in gnzlbg/slice_deque#90 four months ago, a fix was offered in gnzlbg/slice_deque#91 three months ago but has still not been merged, the crate has last received a new commit two years ago and the maintainer seems inactive.

Tracked at gnzlbg/slice_deque#94

The V3 advisory format uses Markdown with TOML frontmatter. It was originally proposed in #240 and implemented (with some changes from the original proposal) in RustSec/rustsec-crate#167.

The new format allows us to see renderings of Markdown-formatted descriptions in PRs and when viewing advisories on GitHub. Barring any unforeseen circumstances, this will be the final stable advisory format, and will unlock releasing 1.0 versions of the various RustSec crates.

In #240, we suggested attempting a migration today, October 1st, 2020 (i.e beginning of Q3), which this issue is for tracking.

Example advisory:

https://raw.githubusercontent.com/RustSec/rustsec-crate/master/tests/support/example_advisory_v3.md

Rendered:

[advisory]
id = "RUSTSEC-2001-2101"
package = "base"
date = "2001-02-03"
url = "https://www.youtube.com/watch?v=jQE66WA2s-A"
categories = ["code-execution", "privilege-escalation"]
keywords = ["how", "are", "you", "gentlemen"]
aliases = ["CVE-2001-2101"]
cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"

[versions]
patched = [">= 1.2.3"]
unaffected = ["0.1.2"]

[affected]
arch = ["x86"]
os = ["windows"]
functions = { "base::belongs::All" = ["< 1.2.3"] }

All your base are belong to us

You have no chance to survive. Make your time.

RustPräzi is a crater-like tool which builds a call graph across all of the crates published to crates.io:

https://internals.rust-lang.org/t/prototype-dev-tool-rustprazi-a-tool-to-build-an-entire-call-graph-of-crates-io/8912

It would be interesting to use this tool, perhaps in conjunction with crates-audit, to generate a list of impacted crates based on this call graph.

To do that we'd need to collect structured information about vulnerable functions in advisories. Looking at our existing advisories, that information is often already there, but buried in an unstructured prose description, e.g.:

https://rustsec.org/advisories/RUSTSEC-2018-0003

If an iterator passed to SmallVec::insert_many panicked in Iterator::next, destructors were run during unwinding while the vector was in an inconsistent state, possibly causing a double free (a destructor running on two copies of the same value).

I think it'd be good to come up with a structured format for this sort of information that can be fed into tools like RustPräzi to determine impacted users of vulnerable crates.

@Shnatsel wanted to discuss this https://github.com/rustsec/advisory-db/pull/1079#issuecomment-945198609 and I feel like now is a pretty good time because arrow-rs has had this issue open about a soundness bug for a month now without a fix or an advisory: https://github.com/apache/arrow-rs/issues/777 and I think I just found one or two more soundness defects.

So what should be done? Notify the crate author(s) and give them some number of days to patch before issuing an advisory? Do we track time from when an issue is opened identifying the problem as a soundness issue, or from when we tell them that this has prompted a RustSec advisory?

Add an advisory for https://github.com/apache/arrow-rs/issues/772 and https://github.com/apache/arrow-rs/issues/773

@jorgecarleitao I'd appreciate if you could take a look.

https://crates.io/crates/poisoning-rustc

malicious build.rs that could switch rustc to any program you want (not the file write this comment, it is build.rs) This build file works in Linux system which install rustc with rustup. similar on Windows system, but I had performed dd if=/dev/null through that garbage partition in my computer. Thus I do not port the script to windows. for crates with this script, all the crate depends it would be infected, and who use a infected crate would get involved. Since we operate rustc on the disk, only an update of rustc could cure the infected rust compiler.

Hopefully not a necessary warning (thus reporting it here and not to cratesio as malware) and "non-maliciously malicious" (attempts to replace rustc with a "you've been pwnd" warning, but no more), but it seems beneficial to have another tracking layer in the audit database, similar to how plutonium has the "explicitly only exists to obfuscate unsafety" warning. May save someone where the crate gets added accidentally (perhaps as a decoy for more subtle malintent[^1]) but runs cargo audit between the lockfile update and

It's probably a better idea to just do a subtle malware, but having the noisy "non-malicious" malware go off when adding a crate could get a response of "well haha, I've been got," removing the attack vector dependency, critically thus also removing record/source of actual malware and making it harder to track down the infection vector if/when the impact becomes apparent.

cc @Neutron3529; it'd maybe be a good idea to yank the crate to help mitigate a small amount of risk. It doesn't eliminate it of course since someone could just use an exact dependency to sidestep the yank IIRC, but it's an additional minor deterrent and protection around accidents.

On mobile, can't format this into proper advisory PR, thus the issue with info for someone else (or me later) to file.

GHSA-28r9-pq4c-wp3c: personnummer - vulnerable to Improper Input Validation.

@Johannestegner do we have the permission to re-publish as-is as CC-BY0 since GHSA is CC-BY4 ? Thanks

CVE-2022-41874: tauri - Tauri Filesystem Scope can be Partially Bypassed CVE-2022-39215: tauri - readDir Endpoint Scope can be Bypassed With Symbolic Links