If you set POSTGREY_TYPE="unix" in the conf.d file for postgrey, then the socket it uses is located at, POSTGREY_SOCKET="/var/spool/postfix/private/postgrey" However, that directory will be owned by the "postfix" user, and not by root. The init script for postgrey trusts the contents of that directory: # HACK -- start a subshell and corrects perms on the socket... if [ "x${POSTGREY_TYPE}" = "xunix" ]; then rm -f ${POSTGREY_SOCKET} ( while ! test -S ${POSTGREY_SOCKET}; \ do sleep 1; \ done; \ chmod a+rw,a-x ${POSTGREY_SOCKET} ) & fi It's not a big window, but there is one, between the "-S" test and the call to chmod that creates a race condition. The "postfix" user can replace the "postgrey" socket with a symlink to any file on the system, and the call to chmod will make the target of the symlink world-writable. I was able to exploit that by brute force (a while-loop that overwrites the postgrey socket with a symlink) but not reliably. A more reliable attack is to create a symlink that points to another socket, so that the "-S" test succeeds and you don't need to time it just right. For example, as the postfix user in /var/spool/postfix/private, rm -f postgrey; \ while [ ! -S postgrey ]; do : ; done; \ ln -sf /var/run/ntpd.sock ./postgrey; will (reliably) cause the init script to make your ntpd socket world-writable.
Coming up on a third birthday... is anyone still maintaining postgrey?
Unrestricting and reassigning to security@ per bug #705894
unrestricting per bug 705894
@stefan, are you there? Any thoughts on this?
Ping
