Re: hardlinks to setuid binaries
Taylor R Campbell <[email protected]> Fri, 25 Mar 2022 23:00:35 +0000
| Newsgroups | gmane.os.netbsd.devel.security |
|---|---|
| Message-ID | <[email protected]> |
> Date: Fri, 25 Mar 2022 18:29:15 -0400 > From: Jan Schaumann <[email protected]> > > Robert Elz <[email protected]> wrote: > > > | Now the sysadmin updates the sudo package, fixing the > > | vulnerability, but your ~/.sudo remains vulnerable. > > > > It depends how the update is done. unlink old, install new, > > will have that effect, but chmod 0 old, unlink old, install > > new does not, nor does cp new old (in all cases, with > > needed chown, chmod, etc, done after the binary update as well). > > I don't think I've seen a whole lot of updates perform > these steps, and would guess that the overwhelming > majority of systems or package managers simply unlink. tar and rsync both write to a temporary file and then rename it to the permanent pathname, so upgrades done with them are vulnerable to this kind of downgrade-suid attack. > I'm not arguing that there aren't many other ways > people can prevent the problem from arising. I'm > saying that few people will use these ways, and it > might be worth considering helping those who don't > rather than say "too bad, you're doing it wrong". I agree. If I understand correctly, the problem is that these methods of update don't revoke suid power (or sgid power) of the file when we realize it's dangerous -- and simply replacing the link isn't enough to revoke the file's suid power. Maybe pkg_delete, and any tool to update base, should clear the suid/sgid bits first? (Of course, if you clear the suid/sgid bit on /usr/bin/su and something goes wrong with the update, you might be in bad shape...) A heavier hammer, not requiring changes to pkg_delete or anything, would be to prohibit creating hard links to files with suid/sgid bits, and to prohibit setting the suid/sgid bits on files with >1 link. But we'd have to think through the consequences -- e.g., that would rule out having a /rescue/su built with crunchgen like the rest of rescue (but that's not something we do at the moment anyway). What else might rely on multiple links to a suid/sgid file?