[Pkg-xfce-devel] Bug#639151: Bug#639151: Bug#639151: Bug#639151: Local privilege escalation

[Sebastian Krahmer]

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