| Summary: | <app-misc/uptimed-0.4.6-r1: root privilege escalation via "chown -R" in pkg_postinst | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Michael Orlitzky <mjo> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | conikost, kfm, polynomial-c, security-audit |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/26820 | ||
| Whiteboard: | B1 [glsa+] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 864943 | ||
| Bug Blocks: | |||
commit 8029ba6c8920e379ea1f5f71afc297bfd30925b3 Author: Lars Wendler <polynomial-c@gentoo.org> Date: Sat Apr 20 22:31:38 2019 app-misc/uptimed: Attempt to fix privilege escalation in pkg_postinst Bug: https://bugs.gentoo.org/630810 Package-Manager: Portage-2.3.64, Repoman-2.3.12 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Unfortunately this suffers from the same problem:
- chown -R uptimed:uptimed /var/spool/${PN}
+ local spooldir="/var/spool/${PN}"
+ if [[ -d "${spooldir}" ]] ; then
+ einfo "Fixing permissions in ${spooldir}"
+ find ${spooldir} -type f -print0 \
+ | xargs --null chown uptimed:uptimed || die
+ fi
In fact, symlinks will work now too (not just hard links). What is it supposed to fix? Maybe I can suggest a better way.
(In reply to Michael Orlitzky from comment #2) > Unfortunately this suffers from the same problem: > > - chown -R uptimed:uptimed /var/spool/${PN} > + local spooldir="/var/spool/${PN}" > + if [[ -d "${spooldir}" ]] ; then > + einfo "Fixing permissions in ${spooldir}" > + find ${spooldir} -type f -print0 \ > + | xargs --null chown uptimed:uptimed || die > + fi > > In fact, symlinks will work now too (not just hard links). What is it > supposed to fix? Maybe I can suggest a better way. I don't see how this suffers from the same problem. There's now a test if spooldir is a directory (and no symlink), and the find call only operates on files. (In reply to Lars Wendler (Polynomial-C) from comment #3) > > I don't see how this suffers from the same problem. There's now a test if > spooldir is a directory (and no symlink), and the find call only operates on > files. The directory was never the problem, it's a file *in* the directory. The same thing works: sudo su -s /bin/sh -c 'ln /etc/passwd /var/spool/uptimed/x' uptimed The uptimed user creates a link called "x" in /var/spool/uptimed pointing to a file of his choosing. The call to chown then gives him ownership of that file. (In reply to Michael Orlitzky from comment #4) > (In reply to Lars Wendler (Polynomial-C) from comment #3) > > > > I don't see how this suffers from the same problem. There's now a test if > > spooldir is a directory (and no symlink), and the find call only operates on > > files. > > The directory was never the problem, it's a file *in* the directory. The > same thing works: > > sudo su -s /bin/sh -c 'ln /etc/passwd /var/spool/uptimed/x' uptimed > > The uptimed user creates a link called "x" in /var/spool/uptimed pointing to > a file of his choosing. The call to chown then gives him ownership of that > file. But the chown does not act on the symlink because find only hands over files to xargs and that calls chown without -R parameter... (In reply to Lars Wendler (Polynomial-C) from comment #5) > > But the chown does not act on the symlink because find only hands over files > to xargs and that calls chown without -R parameter... Contrary to all common sense, chown follows symlinks and hardlinks by default. Sorry, you're right. Hardlinks are the real issue. Dunno how to not make chown act on them... There are a lot of half-fixes that you can pile on:
* Use the -user, -group, and -perm flags to "find" so that you only find
files that need fixing.
* Add --no-dereference to chown to keep it from following symlinks (there's
a race condition in the implementation, but it's as small as you can make
it).
* Use the --from flag with chown to ensure that an attacker can't swap one
file for a link with a different owner/group.
* If you're fixing something during an upgrade, you can check the
REPLACING_VERSIONS variable to ensure that you don't mess with things
during a fresh install.
Ultimately the right answer depends on what you're trying to fix though.
commit 559aeb8ce8d3fe7c6c5f8618f93995252d1683fd Author: Lars Wendler <polynomial-c@gentoo.org> Date: Wed Apr 24 14:20:02 2019 app-misc/uptimed: Another attempt to fix privilege escalation Bug: https://bugs.gentoo.org/630810 Package-Manager: Portage-2.3.64, Repoman-2.3.12 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> I'm using find ${spooldir} -type f -links 1 now which should neither hand over symlinks nor hardlinks to xargs. >
> I'm using
>
> find ${spooldir} -type f -links 1
>
> now which should neither hand over symlinks nor hardlinks to xargs.
If the uptimed user creates 1,000,000 empty files in that directory, he will have several minutes between the "find" call and the "chown" call to replace the last one with a link.
Unrestricting and reassigning to security@ per bug #705894 unrestricting per bug 705894 (In reply to Michael Orlitzky from comment #10) > > > > I'm using > > > > find ${spooldir} -type f -links 1 > > > > now which should neither hand over symlinks nor hardlinks to xargs. > > If the uptimed user creates 1,000,000 empty files in that directory, he will > have several minutes between the "find" call and the "chown" call to replace > the last one with a link. Can we ask the user to make the changes, if necessary, instead? (In reply to Sam James (sec padawan) from comment #13) > > Can we ask the user to make the changes, if necessary, instead? What problem is this pkg_postinst() intended to fix? If the permissions are perpetually wrong, then there's a bug somewhere else, and asking the user to fix them repeatedly is just punting the problem to him or her. We should fix the thing that creates files with the wrong permissions. If the permissions were wrong once and have never been wrong since, we can probably just delete this code now since the bug is so old. (For future reference, though, there are suggestions on my pkg_postinst article for how to minimize the risk of a one-time fix.) On a fresh install, and without that `find` in pkg_postinst, /var/spool/uptimed is correctly owned by uptimed, so we should be able to just get rid of that code. PR incoming. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=106d5ab4c5c1ec11f14e74dfb0ebcc4b72197b53 commit 106d5ab4c5c1ec11f14e74dfb0ebcc4b72197b53 Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2022-08-11 04:15:20 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-08-11 18:22:43 +0000 app-misc/uptimed: drop ownership changes in pkg_postinst Bug: https://bugs.gentoo.org/630810 Signed-off-by: John Helmert III <ajak@gentoo.org> app-misc/uptimed/uptimed-0.4.6-r1.ebuild | 45 ++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) Please stabilize when ready. 0.4.6-r1 is stable. I will shortly drop 0.4.6. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5865dc98aaebfb7ef663189b3f1cda20f8fb6bac commit 5865dc98aaebfb7ef663189b3f1cda20f8fb6bac Author: Conrad Kostecki <conikost@gentoo.org> AuthorDate: 2022-08-12 09:31:41 +0000 Commit: Conrad Kostecki <conikost@gentoo.org> CommitDate: 2022-08-12 09:31:49 +0000 app-misc/uptimed: drop 0.4.6 Bug: https://bugs.gentoo.org/630810 Signed-off-by: Conrad Kostecki <conikost@gentoo.org> app-misc/uptimed/uptimed-0.4.6.ebuild | 54 ----------------------------------- 1 file changed, 54 deletions(-) Thanks! CVE requested GLSA request filed The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/glsa.git/commit/?id=e41b043f23f11bc4b5fda291e24c2b334fb28552 commit e41b043f23f11bc4b5fda291e24c2b334fb28552 Author: GLSAMaker <glsamaker@gentoo.org> AuthorDate: 2023-05-03 10:03:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-05-03 10:05:28 +0000 [ GLSA 202305-14 ] uptimed: Root Privilege Escalation Bug: https://bugs.gentoo.org/630810 Signed-off-by: GLSAMaker <glsamaker@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> glsa-202305-14.xml | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) |
The uptimed ebuilds call chown recursively on the live root filesystem in pkg_postinst: pkg_postinst() { einfo "Fixing permissions in /var/spool/${PN}" chown -R uptimed:uptimed /var/spool/${PN} ... The uptimed user can place a hard link in /var/spool/uptimed pointing to a sensitive root-owned file, and the next time that uptimed is emerged, that file will be given to the uptimed user. For example, 1. emerge uptimed 2. sudo su -s /bin/sh -c 'ln /etc/passwd /var/spool/uptimed/x' uptimed 3. emerge uptimed 4. the file /etc/passwd is owned by uptimed:uptimed