Improved security section in rustdoc for current_exe

[sourcefrog]

A few improvements to the security section of the docs about current_exe

0. The explanatory link https://vulners.com/securityvulns/SECURITYVULNS:DOC:22183 is broken not directly very helpful in understanding the risk.
1. It basically previously says to never trust the result, which is IMO too pessimistic to be helpful. It's worth understanding the behavior but if you have a use case to re-exec the current program, which is not uncommon, this is a reasonable way to do it.
2. The particular risk is about setuid/setgid processes that shouldn't fully trust the user that spawned them.
3. IMO the most important risk with this function is that the invoker can control argv and PATH, so I made this more explicit. (Many unixes, including Linux, don't rely on them in the implementation, but some do.)
4. The previous text about TOCTOU and races is IMO not really coherent: if an attacker can write to the location where you're going to re-exec, they can fundamentally control what program is executed. They don't need to race with your execution of current_exe, and there is no up-front check.
5. Briefly explain the pattern of CVE-2009-1894: on Linux, depending on system configuration, an attacker who can create hardlinks to the executable can potentially control /proc/self/exe. On modern Linux this should normally require permission to write to the executable.

I did some web research for "argv0 vulnerability" and similar terms and didn't find anything else we should be documenting here. (There are issues about argc=0 but those should be prevented by memory safety in Rust.)

I found what the link seemed to be pointing to in https://vulners.com/cve/CVE-2009-1894, which talks about confusing a setuid program by creating a hardlink to its exe. I think this is in very particular circumstances something people should still be concerned about: a setuid program on a machine with fs.protected_hardlinks = 0. I don't think this justifies warning people not to use the function at all.

cc @mgeisler

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

cc @rust-lang/security

[mgeisler]

I like this: I don't think the Rust standard library is the right place to educate people about specific attacks. So keeping the documentation short and simply reminding people to not blindly trust the output seems good.

View changes since this review

[tgross35]

Since you've already taken a look,
r? @cuviper

[sourcefrog]

See also #150824 improving other parts of this function's rustdoc.

[tbu-]

0. The explanatory link is broken.

The link seems to be okay, it just redirects to https://vulners.com/securityvulns/SECURITYVULNS:DOC:22183, which seems to be a vulnerability related to /proc/self/exe.

[sourcefrog]

0. The explanatory link is broken.

The link seems to be okay, it just redirects to https://vulners.com/securityvulns/SECURITYVULNS:DOC:22183, which seems to be a vulnerability related to /proc/self/exe.

Huh, I'm sure it was consistently erroring the other day, but you're right, now it's back.

Anyhow, that particular page, just a list of related vulnerability notices, doesn't seem especially useful to someone trying to understand how to use this Rust function.

We could link to https://blog.cr0.org/2009/07/old-school-local-root-vulnerability-in.html which gives a better explanation. However this seems a bit in the weeds for Rust stdlib, and also possibly not likely to succeed on modern Linux, which should normally(?) prevent creation of untrusted hardlinks to setuid programs.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[sourcefrog]

rebased

@cuviper, @tbu-, what do you think, could we merge it?