Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 603242 - <mail-filter/milter-regex-2.2: root privilege escalation via init script race condition
Summary: <mail-filter/milter-regex-2.2: root privilege escalation via init script race...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Auditing (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-20 19:29 UTC by Michael Orlitzky
Modified: 2020-05-21 22:52 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Orlitzky gentoo-dev 2016-12-20 19:29:58 UTC
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.
Comment 1 Michael Orlitzky gentoo-dev 2016-12-20 19:38:51 UTC
(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.
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:16:23 UTC
Unrestricting and reassigning to security@ per bug #705894
Comment 3 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2020-04-03 23:18:23 UTC
unrestricting per bug 705894
Comment 4 Ralph Seichter 2020-04-03 23:31:51 UTC
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.
Comment 5 Michael Orlitzky gentoo-dev 2020-04-03 23:34:11 UTC
What you're missing is that I filed this bug 3.5 years ago but it was only made public today =P
Comment 6 Ralph Seichter 2020-04-03 23:36:37 UTC
Hehe, I missed that indeed. So, close this bug or what?
Comment 7 Michael Orlitzky gentoo-dev 2020-04-03 23:38:05 UTC
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