Local privilege escalation

Debian Bug report logs - #639151
Local privilege escalation

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Local privilege escalation

Date: Wed, 24 Aug 2011 18:33:45 +0200

Package: lightdm
Severity: grave
Tags: security

Sebastian Kramer posted the following to oss-security:

---

From: Sebastian Krahmer <krahmer@suse.de>
To: oss-security@lists.openwall.com
Cc: robert.ancell@canonical.com
Subject: [oss-security] lightdm issues

Hi,

lightdm (0.9.2) which aims to be a xdm replacement seems to
fall into the same pitfalls like kdm and gdm recently. There is
a lot of uid 0 code creating and chown()ing files in user dirs such as
for ~/.dmrc and ~/.Xauthority. Probably more, depending on
how the permissions of cache and log directories are set up. For example
process_start() also creates and chown()s logfiles on users behalf.

There is also one thing that I dont understand about the lightdm
user itself and why pam sessions seem to be started for it inside
the greeter session code.

The xdmcp code seems to be OK so far, after a quick review.

---

Cheers,
        Moritz

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Message #10 received at 639151@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: Moritz Muehlenhoff <jmm@debian.org>, 639151@bugs.debian.org

Cc: robert.ancell@canonical.com

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

Date: Wed, 24 Aug 2011 18:56:09 +0200

On mer., 2011-08-24 at 18:33 +0200, Moritz Muehlenhoff wrote:
> Sebastian Kramer posted the following to oss-security:
> 
> ---
> 
> From: Sebastian Krahmer <krahmer@suse.de>
> To: oss-security@lists.openwall.com
> Cc: robert.ancell@canonical.com
> Subject: [oss-security] lightdm issues
> 
> Hi,
> 
> lightdm (0.9.2) which aims to be a xdm replacement seems to
> fall into the same pitfalls like kdm and gdm recently. There is
> a lot of uid 0 code creating and chown()ing files in user dirs such as
> for ~/.dmrc and ~/.Xauthority. Probably more, depending on
> how the permissions of cache and log directories are set up. For
> example
> process_start() also creates and chown()s logfiles on users behalf.
> 
> There is also one thing that I dont understand about the lightdm
> user itself and why pam sessions seem to be started for it inside
> the greeter session code.
> 
> The xdmcp code seems to be OK so far, after a quick review. 

Yup, I'm on oss-sec so I've seen this and am waiting for Robert answer.

I guess the proper way to do it would be to move all the user-related
work *after* the setuid() call and before exec()ing the session
wrapper. 
Not sure how gdm3/xdm/slim handle that but there might be inspiration
there too.

Regards,
-- 
Yves-Alexis

Message #15 received at 639151@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: 639151@bugs.debian.org

Cc: Moritz Muehlenhoff <jmm@debian.org>, robert.ancell@canonical.com

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

Date: Wed, 24 Aug 2011 20:55:12 +0200

[Message part 1 (text/plain, inline)]

On mer., 2011-08-24 at 18:56 +0200, Yves-Alexis Perez wrote:
> On mer., 2011-08-24 at 18:33 +0200, Moritz Muehlenhoff wrote:
> > Sebastian Kramer posted the following to oss-security:
> > 
> > ---
> > 
> > From: Sebastian Krahmer <krahmer@suse.de>
> > To: oss-security@lists.openwall.com
> > Cc: robert.ancell@canonical.com
> > Subject: [oss-security] lightdm issues
> > 
> > Hi,
> > 
> > lightdm (0.9.2) which aims to be a xdm replacement seems to
> > fall into the same pitfalls like kdm and gdm recently. There is
> > a lot of uid 0 code creating and chown()ing files in user dirs such as
> > for ~/.dmrc and ~/.Xauthority. Probably more, depending on
> > how the permissions of cache and log directories are set up. For
> > example
> > process_start() also creates and chown()s logfiles on users behalf.
> > 
> > There is also one thing that I dont understand about the lightdm
> > user itself and why pam sessions seem to be started for it inside
> > the greeter session code.
> > 
> > The xdmcp code seems to be OK so far, after a quick review. 
> 
> Yup, I'm on oss-sec so I've seen this and am waiting for Robert answer.
> 
> I guess the proper way to do it would be to move all the user-related
> work *after* the setuid() call and before exec()ing the session
> wrapper. 
> Not sure how gdm3/xdm/slim handle that but there might be inspiration
> there too.

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.

Regards,
-- 
Yves-Alexis

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 639151@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: 639151@bugs.debian.org

Cc: Moritz Muehlenhoff <jmm@debian.org>, robert.ancell@canonical.com, Sebastian Krahmer <krahmer@suse.de>, oss-security@lists.openwall.com

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

Date: Thu, 25 Aug 2011 17:54:23 +0200

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 639151@bugs.debian.org (full text, mbox, reply):

From: Sebastian Krahmer <krahmer@suse.de>

To: Yves-Alexis Perez <corsac@debian.org>

Cc: 639151@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>, robert.ancell@canonical.com, oss-security@lists.openwall.com

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

Date: Fri, 26 Aug 2011 10:43:55 +0200

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@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

Message #32 received at 639151@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: Sebastian Krahmer <krahmer@suse.de>

Cc: 639151@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>, robert.ancell@canonical.com, oss-security@lists.openwall.com

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

Date: Fri, 26 Aug 2011 10:58:26 +0200

[Message part 1 (text/plain, inline)]

On ven., 2011-08-26 at 10:43 +0200, Sebastian Krahmer wrote:
> 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.

The chown will be applied to the symlink, not the target. I've tried to
make .Xauthority a symlink to a root-owned file and the destination was
indeed destroyed, but it's still root-owned.

> 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.

Yeah, I'm currently cooking patches doing that, though they'll need
review before apply.
> 
> 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)?

Yes
> 
> 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.

Yeah, that looks fishy, though I have no idea how it's exactly cooked
that way, we'll have to wait for an answer from Robert.

Regards,
-- 
Yves-Alexis

[signature.asc (application/pgp-signature, inline)]

Message #37 received at 639151@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: oss-security@lists.openwall.com

Cc: Sebastian Krahmer <krahmer@suse.de>, 639151@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>, robert.ancell@canonical.com

Subject: Re: [oss-security] Re: [Pkg-xfce-devel] Bug#639151: Bug#639151: Bug#639151: Local privilege escalation

Date: Fri, 26 Aug 2011 11:07:20 +0200

[Message part 1 (text/plain, inline)]

On ven., 2011-08-26 at 10:58 +0200, Yves-Alexis Perez wrote:
> > 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.
> 
> Yeah, I'm currently cooking patches doing that, though they'll need
> review before apply. 

Would something like:

diff --git a/src/dmrc.c b/src/dmrc.c
index bff1da8..9f38faf 100644
--- a/src/dmrc.c
+++ b/src/dmrc.c
@@ -80,11 +80,25 @@ dmrc_save (GKeyFile *dmrc_file, const gchar *username)
     /* Update the users .dmrc */
     if (user)
     {
+      /* write the file as the user itself */
+      pid_t pid;
+      pid = fork();
+
+      if (pid == 0)
+      {
+        if (setuid (user_get_uid(user)) < 0)
+        {
+          g_warning("Error changing uid for %s: %s", username, g_strerror(errno));
+          _exit(EXIT_FAILURE);
+        }
         path = g_build_filename (user_get_home_directory (user), ".dmrc", NULL);
         g_file_set_contents (path, data, length, NULL);
-        if (getuid () == 0 && chown (path, user_get_uid (user), user_get_gid (user)) < 0)
-            g_warning ("Error setting ownership on %s: %s", path, strerror (errno));
         g_free (path);
+        _exit(EXIT_SUCCESS);
+
+      }
+      if (pid > 0)
+        wait(NULL);
     }
 
     /* Update the .dmrc cache */

do the job (untested, it's more like a RFC right now).

Regards,
-- 
Yves-Alexis

[signature.asc (application/pgp-signature, inline)]

Message #42 received at 639151@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: 639151@bugs.debian.org

Cc: Sebastian Krahmer <krahmer@suse.de>, Moritz Muehlenhoff <jmm@debian.org>, robert.ancell@canonical.com

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

Date: Fri, 26 Aug 2011 13:24:42 +0200

[Message part 1 (text/plain, inline)]

(droppping oss-sec in order to not be too noisy)

On ven., 2011-08-26 at 10:58 +0200, Yves-Alexis Perez wrote:
> > 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.
> 
> The chown will be applied to the symlink, not the target. I've tried to
> make .Xauthority a symlink to a root-owned file and the destination was
> indeed destroyed, but it's still root-owned. 

Ok that's wrong, chown() is supposed to dereference symlinks, so I'm not
sure why the target file wasn't chown()ed in my case.

I've tried replacing .dmrc by a symlink to a root-owned file and, in
that case:

* the target file disappeared
* the symlink disappeared
* a new .dmrc file was written, belonging to my user

so the net result is that you can simply erase any root-owned file in
that case (but not overwrite it with arbitrary content, afaict).

Regards,
-- 
Yves-Alexis

[signature.asc (application/pgp-signature, inline)]

Message #47 received at 639151@bugs.debian.org (full text, mbox, reply):

From: Solar Designer <solar@openwall.com>

To: Yves-Alexis Perez <corsac@debian.org>

Cc: oss-security@lists.openwall.com, Sebastian Krahmer <krahmer@suse.de>, 639151@bugs.debian.org, Moritz Muehlenhoff <jmm@debian.org>, robert.ancell@canonical.com

Subject: Re: [oss-security] [Pkg-xfce-devel] Bug#639151: Bug#639151: Bug#639151: Local privilege escalation

Date: Fri, 26 Aug 2011 21:14:30 +0400

Hi,

I haven't been watching this discussion closely, but here are some
comments that might be of help:

On Fri, Aug 26, 2011 at 11:07:20AM +0200, Yves-Alexis Perez wrote:
> Would something like:
> 
> diff --git a/src/dmrc.c b/src/dmrc.c
> index bff1da8..9f38faf 100644
> --- a/src/dmrc.c
> +++ b/src/dmrc.c
> @@ -80,11 +80,25 @@ dmrc_save (GKeyFile *dmrc_file, const gchar *username)
>      /* Update the users .dmrc */
>      if (user)
>      {
> +      /* write the file as the user itself */
> +      pid_t pid;
> +      pid = fork();
> +
> +      if (pid == 0)
> +      {
> +        if (setuid (user_get_uid(user)) < 0)
> +        {
> +          g_warning("Error changing uid for %s: %s", username, g_strerror(errno));
> +          _exit(EXIT_FAILURE);
> +        }

You also need to switch gid and groups, and you do not have to fork() if
you only switch euid/egid/groups or fsuid/fsgid/groups.  The latter may
be less portable, but at least on Linux it affects only the current
thread in a multi-threaded process.  Probably this difference is
irrelevant in your case, though.

Here's an example:

http://git.altlinux.org/people/ldv/packages/?p=pam.git;a=commitdiff;h=pam_modutil_priv

A tricky part is what to do when you have partially switched credentials
and one of the syscalls fails (e.g., you've switched the gid but not yet
the uid).  The code referenced above (Linux-PAM commit) tries to restore
the old credentials, but ignores possible failure to do so.  A better
action might be to terminate the current process on failure to restore
old credentials.

>          path = g_build_filename (user_get_home_directory (user), ".dmrc", NULL);
>          g_file_set_contents (path, data, length, NULL);
> -        if (getuid () == 0 && chown (path, user_get_uid (user), user_get_gid (user)) < 0)
> -            g_warning ("Error setting ownership on %s: %s", path, strerror (errno));
>          g_free (path);
> +        _exit(EXIT_SUCCESS);
> +
> +      }
> +      if (pid > 0)
> +        wait(NULL);
>      }

You're lucky that you don't seem to need to pass the result of
g_file_set_contents() back to the parent process.  If you were reading
rather than writing a file, you'd have difficulty using the fork()
approach.  However, in your case fork() may actually be fine (but you do
need to drop gid and groups as well).

I hope this helps.

Alexander

Message #52 received at 639151@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: Robert Ancell <robert.ancell@gmail.com>

Cc: lightdm@lists.freedesktop.org, 639151@bugs.debian.org

Subject: Re: [LightDM] Version 0.9.5 released

Date: Thu, 08 Sep 2011 07:54:44 +0200

[Message part 1 (text/plain, inline)]

On jeu., 2011-09-08 at 10:13 +1000, Robert Ancell wrote:
> On 7 September 2011 17:30, Yves-Alexis Perez <corsac@debian.org> wrote:
> > On mer., 2011-09-07 at 16:49 +1000, Robert Ancell wrote:
> >> Lot's of good stuff...
> >
> > Any news on #834079 ?
> 
> I was going to put that in this release, but I think it might take a
> little refactoring to fit in well.  So send me angry email if it's not
> in 0.9.6... :)  (And if 0.9.6 isn't released by the end of next week).

Ok, thanks. Feel free to ask for review on oss-sec list if needed.

Regards,
-- 
Yves-Alexis

[signature.asc (application/pgp-signature, inline)]

Message #57 received at 639151-close@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: 639151-close@bugs.debian.org

Subject: Bug#639151: fixed in lightdm 0.9.6-1

Date: Thu, 15 Sep 2011 10:03:12 +0000

Source: lightdm
Source-Version: 0.9.6-1

We believe that the bug you reported is fixed in the latest version of
lightdm, which is due to be installed in the Debian FTP archive:

liblightdm-gobject-1-0_0.9.6-1_amd64.deb
  to main/l/lightdm/liblightdm-gobject-1-0_0.9.6-1_amd64.deb
liblightdm-gobject-dev_0.9.6-1_amd64.deb
  to main/l/lightdm/liblightdm-gobject-dev_0.9.6-1_amd64.deb
liblightdm-qt-1-0_0.9.6-1_amd64.deb
  to main/l/lightdm/liblightdm-qt-1-0_0.9.6-1_amd64.deb
liblightdm-qt-dev_0.9.6-1_amd64.deb
  to main/l/lightdm/liblightdm-qt-dev_0.9.6-1_amd64.deb
lightdm-gtk-greeter_0.9.6-1_amd64.deb
  to main/l/lightdm/lightdm-gtk-greeter_0.9.6-1_amd64.deb
lightdm-qt-greeter_0.9.6-1_amd64.deb
  to main/l/lightdm/lightdm-qt-greeter_0.9.6-1_amd64.deb
lightdm-vala_0.9.6-1_amd64.deb
  to main/l/lightdm/lightdm-vala_0.9.6-1_amd64.deb
lightdm_0.9.6-1.debian.tar.gz
  to main/l/lightdm/lightdm_0.9.6-1.debian.tar.gz
lightdm_0.9.6-1.dsc
  to main/l/lightdm/lightdm_0.9.6-1.dsc
lightdm_0.9.6-1_amd64.deb
  to main/l/lightdm/lightdm_0.9.6-1_amd64.deb
lightdm_0.9.6.orig.tar.gz
  to main/l/lightdm/lightdm_0.9.6.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 639151@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Yves-Alexis Perez <corsac@debian.org> (supplier of updated lightdm package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Thu, 15 Sep 2011 11:36:21 +0200
Source: lightdm
Binary: lightdm lightdm-gtk-greeter lightdm-qt-greeter lightdm-vala liblightdm-gobject-1-0 liblightdm-qt-1-0 liblightdm-gobject-dev liblightdm-qt-dev
Architecture: source amd64
Version: 0.9.6-1
Distribution: unstable
Urgency: low
Maintainer: Debian Xfce Maintainers <pkg-xfce-devel@lists.alioth.debian.org>
Changed-By: Yves-Alexis Perez <corsac@debian.org>
Description: 
 liblightdm-gobject-1-0 - simple display manager (gobject library)
 liblightdm-gobject-dev - simple display manager (gobject development files)
 liblightdm-qt-1-0 - simple display manager (Qt library)
 liblightdm-qt-dev - simple display manager (Qt development files)
 lightdm    - simple display manager
 lightdm-gtk-greeter - simple display manager (GTK+ greeter)
 lightdm-qt-greeter - simple display manager (Qt greeter)
 lightdm-vala - simple display manager (Vala files)
Closes: 639151
Changes: 
 lightdm (0.9.6-1) unstable; urgency=low
 .
   * New upstream release:
     - don't write user files as root to prevent symlinks attacks
       [CVE-2011-3349]                                           closes: #639151
   * debian/patches:
     - 01_set-default-path, 02_default-config, 03_quit-plymouth,
       04_default-gtk-greeter-config refreshed.
     - 05_always-export-XAUTHORITY dropped, included upstream.
     - 05_dont-add-pkglibexecdir-path added, don't add /usr/lib/lightdm/lightdm
       to the PATH, it's ugly.
   * debian/rules:
     - don't install gdmflexiserver script for now until the PATH issue is
       solved.
   * debian/lightdm.install
     - install lightdm-set-default and dm-tool there.
   * debian/lightdm-{gtk,qt}-greeter.{config,templates,postinst,prerm}:
     - provide a way to select the current greeter through debconf. Other
       packages providing a greeter use the same templates/config to register
       themselves in debconf.
   * debian/control:
     - add suggests on accountsservice.
Checksums-Sha1: 
 77c68e52808f2d8648904486dddcaa6cb1b6c0e9 2338 lightdm_0.9.6-1.dsc
 1debe4e00244f93a08faac5b3c4fffbc5f2cafdc 623109 lightdm_0.9.6.orig.tar.gz
 a15621b81341f44dda7ba8ab72ab4d8c1b572c70 31512 lightdm_0.9.6-1.debian.tar.gz
 1ca7999ce4b3f5833c1ca512e271e2a0fdccd82c 113648 lightdm_0.9.6-1_amd64.deb
 9d2a4bfbc8dae90c811657f20dbe25a209b388f0 27312 lightdm-gtk-greeter_0.9.6-1_amd64.deb
 9e4d31a3c5e498b2636b6f250aa1ad164916ce7f 21630 lightdm-qt-greeter_0.9.6-1_amd64.deb
 d0dcf0b70c2d4377530f20353c0604537b1548b5 4044 lightdm-vala_0.9.6-1_amd64.deb
 d3d3bd4d30d2b630d8d2fdf6f9cc76a1667bb82b 28272 liblightdm-gobject-1-0_0.9.6-1_amd64.deb
 4658e49264f46a343b07bf35aa4fc26befb34d15 50496 liblightdm-qt-1-0_0.9.6-1_amd64.deb
 3de1d119fbf87ef383fccb5edc156bcafd48c394 52564 liblightdm-gobject-dev_0.9.6-1_amd64.deb
 73f5f85785487b5df02d34888a23ffd74dbd17a7 62290 liblightdm-qt-dev_0.9.6-1_amd64.deb
Checksums-Sha256: 
 c0ce0aa80475acd4461a7f8f6ffb99afa5374d6dc8e66d83334045e2aefcae69 2338 lightdm_0.9.6-1.dsc
 660c4bd8fd113cb7273beb6a8f2c18e659b676deda499bfb5a09c73fb079fb8d 623109 lightdm_0.9.6.orig.tar.gz
 1cc4b48246fb0b014ae96ec7e3fc84018f5b0c27fdc7b148026846e8411e6c50 31512 lightdm_0.9.6-1.debian.tar.gz
 b3856f0432edc48de3aa743da6793a933375ea3be1d92898573ed70d6296fc0c 113648 lightdm_0.9.6-1_amd64.deb
 0d22d6ee55a6210c39e67206232f131bc0dfcf86c7ff7738f51104f6587d15f1 27312 lightdm-gtk-greeter_0.9.6-1_amd64.deb
 cf8642d2ad13f6cea6d448d7ca9a4a50d54ff8db57ade3562c444e0dc2cd4cd2 21630 lightdm-qt-greeter_0.9.6-1_amd64.deb
 d214ababacf2e79fbd6b5402e5126b1c79adc13cfe6981cbfcb08cf2afa3abee 4044 lightdm-vala_0.9.6-1_amd64.deb
 e7f4bb881589e3944dc0b0b5df9afe52e9b6ee8d6012257f0b0cd74f12fe8244 28272 liblightdm-gobject-1-0_0.9.6-1_amd64.deb
 15587188185891fde13986900498cd61ffa6656a2052b9ec6f0195fe9aff0d38 50496 liblightdm-qt-1-0_0.9.6-1_amd64.deb
 ee3408e5c58e7ee28f99a26334d8b871f378cfa901770a290cc8c31f1b9a4f7e 52564 liblightdm-gobject-dev_0.9.6-1_amd64.deb
 3579b32fd15f3b069e00b2630fde5e7a3a7764b222f9f2f9a52034e479314846 62290 liblightdm-qt-dev_0.9.6-1_amd64.deb
Files: 
 a5b238a5c40140b847b0dc848141666e 2338 x11 optional lightdm_0.9.6-1.dsc
 088cb083185e39f9a5be846aab270e3c 623109 x11 optional lightdm_0.9.6.orig.tar.gz
 89547715255fdfe6cb595c5c987cb829 31512 x11 optional lightdm_0.9.6-1.debian.tar.gz
 56fb86e075114b570b9c3f15be8a7e10 113648 x11 optional lightdm_0.9.6-1_amd64.deb
 f23dfd47c231a628dfd0921cf9feee63 27312 x11 optional lightdm-gtk-greeter_0.9.6-1_amd64.deb
 be0f22afcd844dd31faf48fd903a8a74 21630 x11 optional lightdm-qt-greeter_0.9.6-1_amd64.deb
 071edaecacb3621b7b256cac929618ff 4044 x11 optional lightdm-vala_0.9.6-1_amd64.deb
 64ae5e0c486664668e72fa38fe6ec031 28272 libdevel optional liblightdm-gobject-1-0_0.9.6-1_amd64.deb
 d53f5593bfa83e2e21c8351c44282b8a 50496 libdevel optional liblightdm-qt-1-0_0.9.6-1_amd64.deb
 325c9d5572f13e9eb1d571197fdbde92 52564 libdevel optional liblightdm-gobject-dev_0.9.6-1_amd64.deb
 83e36b2a79927d1ba2d327f857df6191 62290 libdevel optional liblightdm-qt-dev_0.9.6-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCgAGBQJOcckUAAoJEDBVD3hx7wuoXokQAJoeUcxbrrRc4fLXfYQHfMEf
a2K8Wy8CXYusisHJRIXpT1Zu91pABgfHxH6r1xxeS4RLMfgcHRtIP4ct+rDZWa5C
TxzXuoL3X6v9nCyrCuvkK6XCB82jz0GunXtrXGvgJ44CxVUFtjLwzwWdClXR7snn
O0XqW/LMC27zyNitFpgZUfAx02okjr/XRmUb0ieyIzZjYRUkXcTstkRB0SfGSYlS
YHLpcCjUKxnuo+Fo++dUt+WgOtZjapqrIXXUB5ESZ+pbfocKRglMczefUDTBqkTs
K8hdGCptp8RgNh7L2KNLENsJSoiHoZXJs22hpFHH7SMaxJLQ+OA/9hDD0MsdG9ta
CswXbt7u+aOOmuijEqRqYBpgSmNB5Q+qTPkTLrtiptYMcisjydN8Fj49ZuUJYYYK
atU9kW2Kpu4JXG2GTJuzGWoBdqd0utigjjLEMGGB+WgFZpYcfoc85/fc2Zo0QLkP
y5ThWHJYNNJHUaBQD5Mr2ph8mZfBKdBUQUiD4le8D0cPgYKDLV4KmRrNwocAEmlQ
tvwDPISg71cuHm6uoZkl1WGOetNaKkfunNDrv7+KvWNzL+yUXYhZeZmdRmtdRhQT
b8isQMovEX+ejxKT/+JeqfkHKigah4RkHfnxgLzY2K1WL8edzAqZTf76Ypou5rMH
Yo7zDta3kKU23edEfyW8
=wpSM
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.