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 ~ krah...@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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
