Add advisory for segfault in openssl-probe due to environment setters

[mmastrac]

We tracked down a crash to an interaction with environment setters in openssl-probe and environment access in another thread. CVE scoring was cloned from a previous environment soundness issue (https://nvd.nist.gov/vuln/detail/CVE-2020-26235).

Filed issue with more details: alexcrichton/openssl-probe#30

This is not really a sensitive issue, so it could probably be delayed a bit to give the crate a chance to update.

Open Questions

• Release 0.2.0 of openssl-probe and mark < 0.2.0 as vulnerable?

Major crate status

• native-tls (117M dl) - completed in sfackler/rust-native-tls@a35127a, released
• rustls-native-certs (105M dl)- not vulnerable, version bumped
• minreq (2M) - completed in neonmoe/minreq@4bc16db

Unfixed or partially fixed

• git2-rs (41M) - unfixed
• curl-rust (24M) - unfixed
• mongodb (5M) - unfixed, but migrated to new, unsafe APIs (still at risk of crash) -- RUST-2144 Remove use of deprecated openssl_probe method mongodb/mongo-rust-driver#1294 (comment)
• pingora-core - unfixed

[eric-seppanen]

If including a link to the source code, maybe it should be a link to a specific revision of that file, to guarantee readers months from now will see the version of the code you wanted them to see. (In the future that file may not even exist.)

[mmastrac]

@eric-seppanen, thanks for the feedback -- I updated the advisory with a specific commit link. I've also added the path to the function and a "patched" version.

@alexcrichton, please let me know if there is anything I missed here. Thanks for the quick turnaround on the new release.

[alexcrichton]

👍

[alexcrichton]

On second thought for the < 0.1.6 bit here (and the line above) - technically this isn't correct where init_ssl_cert_env_vars is still just as unsafe as it was before on 0.1.6+. I'm not sure how that interacts with tooling and this advisory though. Technically though just because someone updates to 0.1.6 doesn't really "fix" things, it's actually so long as these funtions are used then a "fix" is still necessary. In other words the true fix for this advisory isn't actually in openssl-probe, it's in all users of openssl-probe and fixing is more broadly scoped than just updating the openssl-probe crate

[mmastrac]

That's a good point -- I believe that a deprecation warning probably means that the API consumer is aware and these functions are no longer "affected" but we may need someone else to weigh in.

[mmastrac]

I took one more pass to clarify the role of the Rust platform locks around environment access.

[eric-seppanen]

Imagine I depend on reqwest, which transitively depends on openssl-probe 0.1.5. I see the advisory, which appears to recommend updating to 0.1.6. I run cargo update -p openssl-probe and am satisfied that the problem is solved. But it's not!

I will never see this deprecation warning, because it only appears when compiling dependencies, and warnings in dependencies are normally suppressed.

I think don't think < 0.1.6 should go in the advisory, because it will lead to the wrong outcome for most projects.

[tarcieri]

Imagine I depend on reqwest, which transitively depends on openssl-probe

Sounds like this advisory has large potential to be very noisy, which is something to consider. We've had a lot of backlash in the past from similarly noisy advisories.

[mmastrac]

@eric-seppanen native-tls did use it, it's been fixed. rustls-native-certs wasn't affected but was bumped. All relevant crate owners above were brought into the thread.

[mmastrac]

(if we end up releasing a 0.2.0 with the affected functions behind a bigger wall, we'll have to do that dance again)

[eric-seppanen]

In this advisory we're faced with two bad choices:

1. Set the advisory to say "< 0.1.6"; downstream workspaces can bump openssl-probe to 0.1.6 in Cargo.lock and tooling (cargo audit or cargo deny) says the problem is gone. But nothing was fixed! The deprecation warning will be hidden if it's in a dependency, so these projects are still using dangerous code. This advisory didn't really have the desired effect.
2. Set the advisory to say "0.1.x"; which is an advisory that can never be cleared (only manually ignored) because that covers all released versions. This advisory had a stronger effect but is annoying because every downstream project that has automated rustsec checks has to take actions beyond updating a dependency. This will also annoy maintainers of dependent crates that are "fixed" (not calling the dangerous functions), because automated rustsec checks can't tell the difference.

Which leads us to a new option:

3. Release 0.2.0 with the safe-but-maybe-unsound function names removed, and have the advisory apply to all versions "< 0.2.0". For automated advisory tooling, this is the best outcome: downstream projects can resolve the advisory by bumping dependencies until 0.1.x is gone from Cargo.lock. This assumes that the major dependent crates cooperate by replacing 0.1.6 with 0.2.0. If they don't then this is a pointless exercise.

Is it worth it, considering the ecosystem churn caused by 0.1.x and 0.2.0 coexisting for a period? That's harder to answer.

[eric-seppanen]

Apologies for being long-winded. I was trying to respond to

native-tls did use it, it's been fixed

Great! Unfortunately, nothing in this advisory says "update to native-tls 0.2.13". This advisory tells projects to bump openssl-probe to 0.1.6, which for the vast majority of workspaces will not fix anything.

[tarcieri]

I think the advisory definitely needs to be actionable. We published a similar advisory for chrono (RUSTSEC-2020-0159) which wasn't actionable and got a considerable amount of blowback, to the point that we ended up withdrawing it.

It would be good to coordinate with major notable downstream dependencies (there are at least 7 with more than a million downloads) to ensure that when we publish the advisory, users of those crates simply need to cargo update

[mmastrac]

As a heads-up, I think this particular advisory is going to be too much for me to manage with my limited bandwidth and the conflicting requirements. The process is certainly frustrating as an outsider, so I'm going to have to leave it in your capable hands.

I'm happy that the underlying problems have been fixed and the fixes have circulated, but I'm going to abandon this PR and walk away from the process. Consider the advisory-in-progress as licensed CC0 as needed for whatever has to happen going forward. Appreciate the quick work from everyone involved.