The ebuild for milter-regex takes ownership of its socket directory: fowners milter:milter /var/run/milter-regex The init script then trusts the contents of that directory, start-stop-daemon --start --exec /usr/bin/milter-regex -- \ -u "${USER}" -p "${SOCKET}" -c "${CONFIG}" EXIT=$? [ $? == 0 ] && chmod a+rw "${SOCKET}" The idea there is that the call to chmod is safe, since $SOCKET should be created by the daemon. However, there is a split second between the call to start-stop-daemon and the call to chmod where the "milter" use can modify $SOCKET. If he replaces $SOCKET with a symlink, then the call to chmod makes the target of that symlink world-writable. I am able to exploit this: I have a dummy text file (mode 644) at /home/mjo/root. If I run, while true; do ln -sf /home/mjo/foo.txt /var/run/milter-regex/milter-regex.sock; done; as the "milter" user and then start the milter-regex service, it starts successfully and I find that /home/mjo/foo.txt is now mode 666.
(In reply to Michael Orlitzky from comment #0) > > I have a dummy text file (mode 644) at /home/mjo/root. Oops, that should be /home/mjo/foo.txt.
Unrestricting and reassigning to security@ per bug #705894
unrestricting per bug 705894
I'm scratching my head, because I am not calling fowners or start-stop-daemon directly: → cd /var/db/repos/gentoo/mail-filter/milter-regex → grep -r start-stop-daemon * || echo 'Not found' Not found → grep -r fowners * || echo 'Not found' Not found > If I run [...] as the "milter" user and then start the > milter-regex service, it starts successfully and I find > that /home/mjo/foo.txt is now mode 666. As defined by acct-user/milter-regex, the milter-regex's home directory is /dev/null and its shell is /sbin/nologin. If you can run any command as milter-regex other than starting out with root privileges, something is quite wrong.
What you're missing is that I filed this bug 3.5 years ago but it was only made public today =P
Hehe, I missed that indeed. So, close this bug or what?
security@ decides when to close it, but it's been fixed and the tree is clean of the vulnerable versions, so nothing for us to do
Fixed since https://gitweb.gentoo.org/repo/gentoo.git/commit/mail-filter/milter-regex?id=a199b66a6767c285587d9a22e06a42078e8a5684 (September 2018). Closing.