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 attachment 79866 [details] 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.
