Rust 1.58.1 released [LWN.net]

Rust 1.58.1 released

Posted Jan 21, 2022 16:57 UTC (Fri) by compenguy (guest, #25359)
Parent article: Rust 1.58.1 released

IIRC, this vulnerability affects pretty much all extant versions of rust, but is limited to code that uses std::fs::remove_dir_all (either directly or indirectly), as there's a race condition that could allow a malicious unprivileged user to coax a privileged program that calls remove_dir_all() on a directory chain where the attacker has access to use symlinks to delete locations that the attacker wouldn't otherwise have access to.

to post comments

Limited to code that uses std::fs::remove_dir_all

Posted Jan 21, 2022 17:59 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link] (3 responses)

This vulnerability is limited to only code that uses std::fs::remove_dir_all (directly or indirectly) *and* is run on a platform where an attacker can create a symlink. Do we have any idea how many programs this really affects? I'm sure this affects some applications, but I would expect it to be relatively few.

Limited to code that uses std::fs::remove_dir_all

Posted Jan 21, 2022 20:24 UTC (Fri) by yodermk (guest, #3803) [Link] (2 responses)

*and* the program is suid

Yeah some no doubt. But not most.

Limited to code that uses std::fs::remove_dir_all

Posted Jan 21, 2022 22:05 UTC (Fri) by plugwash (subscriber, #29694) [Link] (1 responses)

As I understand it, it applies to any cases where a program deletes a directory tree that a potentially malicious user can write to. Especially if the deletion is regularly scheduled or if the malicious user can trigger it somehow.

The difficult thing is auditing where that is or is not the case. With a vulnerability in a shared library you just patch it, deploy the patched library and move on, with a vulnerability in a static library you either rebuild/redeploy everything that depends on said static library or you spend a bunch of time trying to audit/risk assess each program, or you just ignore the issue.

Limited to code that uses std::fs::remove_dir_all

Posted Jan 23, 2022 8:53 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

In this particular case it's probably easier for entities to rule themselves out because they don't meet the preconditions to be attacked.

None of the systems I'm looking after at work run Rust, but even if they all did, none of them have hostile users who can make symlinks. Our hostile users (well, students, much the same thing) can write arbitrary files to disk, although they don't get to decide the filenames, in some of our applications, but they can't write symlinks.