Bugzilla Bug 122951

Compile tests for coreutils are world editable but run by root, allowing for
local privilege escalation during test phase of emerge.  While exposure is
limited, I think the implications are serious.  Will attach example exploit.

Created an attachment (id=79866) [edit]
Automated exploit of privilege escalation vulnerability

This perl script is designed to automatically exploit the coreutils emerge
operation (assuming it's run with FEATURES="maketest") and present an
unprivileged user with a root shell.

WARNING: THIS SCRIPT *WILL* DAMAGE YOUR SYSTEM'S SECURITY AND MAY WREAK HAVOC.

i dont get it

portage marks $WORKDIR as 700

how are non-root users supposed to get into that ?

(In reply to comment #2)
> i dont get it
> 
> portage marks $WORKDIR as 700
> 
> how are non-root users supposed to get into that ?
> 

Perhaps this?

coreutils-5.93.ebuild, line 98: chmod a+rx "${WORKDIR}"

base-system, please comment

that would do it

simply adding a `chmod -R go-w ${WORKDIR}` should fix it

adjusting severity.

fixed in cvs now

In fact this doesn't need a GLSA...

The idea being, this happens only when you emerge the thing. Now, next time
people upgrade coreutils, the vulnerability won't be there. There is no point
in forcing people to do that (now safe) upgrade now. Those that have already a
"vulnerable" coreutils installed are not vulnerable to anything now that it has
been installed... And will be safe next time they upgrade.

We call this the "python-updater" precedent.
If everyone agrees we'll open this bug and close it without GLSA.

Joshua, many thanks for bringing this to our attention.

Sounds reasonable, I agree.

Makes sense, I agree.

(In reply to comment #8)
> Joshua, many thanks for bringing this to our attention.

Glad to be of service.  Thanks to all devs for working on this.

Some follow-up thoughts:

In the unlikely event that someone reemerges coreutils before resyncing (e.g.
change in USE flags, or revdep-rebuild?), their system will still be
vulnerable.  In not saying this warrants a GLSA, but I think it's something to
keep in mind.

While I believe that the current fix to this bug is sufficient, I find it
disconcerting that there were world-writable directories in the first place,
especially since these didn't occur when I played with compiling the unpatched
source straight from GNU.  This raises a few questions in my mind: What makes
the tests' directories world-writable, and could whatever that is still
introduce a race condition or another vulnerability, either now or in the
future?  Are there other similar packages with the same or similar
vulnerabilities?

Finally, it looks the current fix for this bug makes bug 122149 obsolete.

> While I believe that the current fix to this bug is sufficient, I find it
> disconcerting that there were world-writable directories in the first place,
> especially since these didn't occur when I played with compiling the unpatched
> source straight from GNU.

that's because you probably extracted the tarball as a non-root user ... the
permissions arent fully restored as a non-root user, just as root

look at the output of `tar vvvtf coreutils-5.94.tar.bz2`

OK then, closing and opening.