Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1314287667.1902.16.camel@scapa>
Date: Thu, 25 Aug 2011 17:54:23 +0200
From: Yves-Alexis Perez <corsac@...ian.org>
To: 639151@...s.debian.org
Cc: Moritz Muehlenhoff <jmm@...ian.org>, robert.ancell@...onical.com, 
	Sebastian Krahmer
	 <krahmer@...e.de>, oss-security@...ts.openwall.com
Subject: Re: [Pkg-xfce-devel] Bug#639151: Bug#639151: Bug#639151: Local
 privilege escalation

On mer., 2011-08-24 at 20:55 +0200, Yves-Alexis Perez wrote:
> And, out of curiosity, how would you achieve privilege escalation? You
> should be able to erase/rewrite arbitrary files, including /etc/shadow,
> but you don't really have control on what's written there. 

In gdm (CVE-2011-0727 I guess) the issue was that a g_file_copy() was
run as root from files under user control (.dmrc and the avatar), to a
cache dir with write permissions (afaict). So it was easy to put
whatever stuff you need in the original file and make a symlink
to /etc/shadow in the destination folder so the g_file_copy() would
erase that:

                 res = g_file_copy (src_file,
                                    dst_file,
                                    G_FILE_COPY_OVERWRITE |
                                    G_FILE_COPY_NOFOLLOW_SYMLINKS,
                                    NULL,
                                    NULL,
                                    NULL,
                                    &error);


I'm not too sure what G_FILE_COPY_OVERWRITE means, if it truncate()s and
write over of if it unlink()s and start fresh (digging in glib to find
out). Apparenlty in the fallback case (not sure if it's the case here)
it ends up doing a g_file_replace()).

In any case, in lightdm case, for .Xauthority file it uses
g_file_replace() which creates a temporary file and then rename over the
new file, so in the worst case you overwrite a system file with
xauthority data.

Same thing for .dmrc, you can overwrite system files but with dmrc data
which look like 

[Desktop]
Session=xfce
Lang=fr_FR.UTF-8

so it doesn't look easy to gain root access with that.

LightDM maintains a cache for dmrc files in /var/cache/lightdm but the
folder is created 0700 so it doesn't look like one can put symlinks
there and have it use a user-controled .dmrc.

All in all, I'm not too sure there's a privilege escalation for
Xauthority/.dmrc files (but if one exists, I'm interested in how to do
it, by curiosity). But you still damage pretty much any arbitrary file,
which is still an easy DoS.

Regards,
-- 
Yves-Alexis

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.