[Pkg-xfce-devel] Bug#639151: Bug#639151: Bug#639151: Bug#639151: Local privilege escalation
Hi,
You probably dont take into account the chown() that happens in lightdm.
Just unlink the created ~/.dmrc or ~/.Xauthority files after creation and make a symlink
to /etc/passwd to chown it to yourself.
However I didnt dig deep enough into it to write an exploit as I dont have
a working lightdm setup. The correct behavior is to temporarily drop euid/fsuid
to that of the user if doing anything with his files.
The PAM issue that I was curious about was that a pam_start() etc is done
for the greeter-user (which I expect to be some "lightdm" user)?
I would expect all pam_ calls are only done for the user who is actually
about to login. The question that came up to me was whether pam_environment
from the user would have impact on uid-0 called programs/scripts since
you transfer the PAM env to the process env.
Sebastian
On Thu, Aug 25, 2011 at 05:54:23PM +0200, Yves-Alexis Perez wrote:
> 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
--
~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer at suse.de - SuSE Security Team
---
SUSE LINUX Products GmbH,
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg)
Maxfeldstra?e 5
90409 N?rnberg
Germany
Reply to: