Bug 614608 - (CVE-2010-2532) CVE-2010-2532 lxsession: does not lock the screen before suspending/hibernating/switching users
CVE-2010-2532 lxsession: does not lock the screen before suspending/hibernati...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
public=20100713,reported=20100713,sou...
: Security
Depends On: 614609
Blocks: CVE-2009-4996
  Show dependency treegraph
 
Reported: 2010-07-14 16:59 EDT by Vincent Danen
Modified: 2011-08-15 22:44 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2010-07-14 16:59:42 EDT
A bug report [1] for OpenSUSE indicates that lxsession-logout does not lock the screen before suspending, hibernating, or switching users.  A patch [2] was attached to the bug to correct the issue.

This issue would affect lxsession in Fedora.

[1] https://bugzilla.novell.com/show_bug.cgi?id=622083
[2] https://bugzillafiles.novell.org/attachment.cgi?id=375737
Comment 1 Vincent Danen 2010-07-14 17:00:49 EDT
Created lxsession tracking bugs for this issue

Affects: fedora-all [bug 614609]
Comment 2 Christoph Wickert 2010-07-14 18:40:45 EDT
I'm in contact with the SUSE maintainer already but I will not apply the patch if the SUSE people don't upstream it properly. I think blindly copying patches that are not upstreamed is against our policies, see https://fedoraproject.org/wiki/Staying_close_to_upstream_projects
Comment 3 Christoph Wickert 2010-07-14 18:42:20 EDT
P.S.: I don't consider this a vulnerability only because a person at SUSE does and I think that our security response shouldn't do ether.
Comment 4 Vincent Danen 2010-07-15 01:06:58 EDT
I didn't file the bug to necessarily force you to adopt SUSE's patch.  The patch was noted because it was noted in their bug (honestly, the bug would have been filed whether a patch existed or not).  I'm aware of the upstream policy and I don't know what SUSE has done to approach upstream regarding it.

The bug was filed to make the maintainer aware of the situation.

However, I'm not considering this a vulnerability because someone at SUSE thinks so.  I'm considering at a vulnerability because I'm of the frame of mind that if you are hibernating or suspending your system, it is reasonable to expect to be prompted for a password when you return to it.

Is that an unreasonable expectation?  Or do you have a different argument for why you don't think this is a security issue, aside from the fact that someone at SUSE does?

(I also use the term "security issue" a little loosely here... it's more of a privacy issue since it is something you need to get your hands on physically, but if nothing else I would certainly consider this a bug and worth investigating and dealing with upstream on, whether that is via SUSE or directly).
Comment 5 Christoph Wickert 2010-07-15 06:55:13 EDT
(In reply to comment #4)
> I don't know what SUSE has done to approach upstream regarding it.

I'm trying to figure that out. I told the SUSE maintainer to report the bug upstream but so far nothing has happened.

> I'm considering at a vulnerability because I'm of the frame of mind
> that if you are hibernating or suspending your system, it is reasonable to
> expect to be prompted for a password when you return to it.

What makes you think so? Only because it is that way in GNOME?

> Is that an unreasonable expectation?  Or do you have a different argument for
> why you don't think this is a security issue, aside from the fact that someone
> at SUSE does?

I'm NOT saying it is a privacy issue BECAUSE someone at SUSE thinks so, I'm saying if it is an issue, it is because of false assumptions. IMHO locking the display and suspenmding/hibernating a machine are 2 different things. If somebody has physical access to a machine, you will be in trouble anyway.

Note that we have the same in Xfce and upstream made it very clear that he has no intentions to change that behavior, see bug 587633 comment 3.

Anyway, waiting for SUSE to file a bug and a reaction from upstream.
Comment 6 Vincent Danen 2010-07-15 11:27:21 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > I don't know what SUSE has done to approach upstream regarding it.
> 
> I'm trying to figure that out. I told the SUSE maintainer to report the bug
> upstream but so far nothing has happened.
> 
> > I'm considering at a vulnerability because I'm of the frame of mind
> > that if you are hibernating or suspending your system, it is reasonable to
> > expect to be prompted for a password when you return to it.
> 
> What makes you think so? Only because it is that way in GNOME?

Not just GNOME, but most operating systems IIRC.  Not sure about Windows, but OS X does this, and I suspect KDE does this as well.
 
> > Is that an unreasonable expectation?  Or do you have a different argument for
> > why you don't think this is a security issue, aside from the fact that someone
> > at SUSE does?
> 
> I'm NOT saying it is a privacy issue BECAUSE someone at SUSE thinks so, I'm
> saying if it is an issue, it is because of false assumptions. IMHO locking the
> display and suspenmding/hibernating a machine are 2 different things. If
> somebody has physical access to a machine, you will be in trouble anyway.

I don't think it's necessarily a false assumption, just a reasonable one.

Of course you're in trouble if someone has physical access to a machine.  But again, this is more of a privacy thing than a security thing.
 
> Note that we have the same in Xfce and upstream made it very clear that he has
> no intentions to change that behavior, see bug 587633 comment 3.

That's fine; upstream XFCE is certainly entitled to their opinion on their own sofware.  This bug has nothing to do with XFCE.  Using the same argument, I can say that we _do_ have this support in GNOME.
 
> Anyway, waiting for SUSE to file a bug and a reaction from upstream.    

Thank you.

If nothing else, and upstream indicates this is expected/normal/desired behaviour, we have something to point to that indicates this is not a bug or deficiency of any kind.  Considering SUSE has requested a CVE for this issue, this bug would have been created anyway:

http://article.gmane.org/gmane.comp.security.oss.general/3197
Comment 7 Vincent Danen 2010-07-16 16:00:02 EDT
This issue has been assigned the name CVE-2010-2532.
Comment 8 Christoph Wickert 2010-07-16 18:16:57 EDT
(In reply to comment #6)

> I don't think it's necessarily a false assumption, just a reasonable one.

Honestly, I wouldn't expect it. It's reasonable because it's based on expectations which in turn are based on other operating systems or desktop environments. If we followed that logik, we could file plenty of bugs.

> Of course you're in trouble if someone has physical access to a machine.  But
> again, this is more of a privacy thing than a security thing.

Right, it's a privacy issue, not a security issue. Therefor it was wrong IMHO to request a CVE because it is not a vulnerability in the code.

> That's fine; upstream XFCE is certainly entitled to their opinion on their own
> sofware.  This bug has nothing to do with XFCE.  Using the same argument, I can
> say that we _do_ have this support in GNOME.

On the one hand Xfce is entitled to their opinion, but on the other hand LXDE is not and needs to do what the SUSE security team decides behind their backs?

I'm having serious problems with both the SUSE approach and their patch (as outlined in https://bugzilla.novell.com/show_bug.cgi?id=622083#c7)
Comment 9 Vincent Danen 2010-07-16 18:49:14 EDT
(In reply to comment #8)
> > I don't think it's necessarily a false assumption, just a reasonable one.
> 
> Honestly, I wouldn't expect it. It's reasonable because it's based on
> expectations which in turn are based on other operating systems or desktop
> environments. If we followed that logik, we could file plenty of bugs.

I'm not going to argue this.
 
> > Of course you're in trouble if someone has physical access to a machine.  But
> > again, this is more of a privacy thing than a security thing.
> 
> Right, it's a privacy issue, not a security issue. Therefor it was wrong IMHO
> to request a CVE because it is not a vulnerability in the code.

Yes, I said it was a privacy issue.  A CVE name was requested and assigned.  Not, I might add, by myself.  You can feel as strongly about this as you like, one way or the other, but it doesn't change the fact that SUSE requested a CVE, and it was given.  Now, if the LXDE upstream want to dispute this as being a concious design decision, then let's do that.  But complaining about a CVE being assigned isn't productive.

As an aside, it doesn't have to be a vulnerability in the code to obtain a CVE.. a deficient design or implementation (where the code is technically correct) is enough.
 
> > That's fine; upstream XFCE is certainly entitled to their opinion on their own
> > sofware.  This bug has nothing to do with XFCE.  Using the same argument, I can
> > say that we _do_ have this support in GNOME.
> 
> On the one hand Xfce is entitled to their opinion, but on the other hand LXDE
> is not and needs to do what the SUSE security team decides behind their backs?

Who said that?
 
> I'm having serious problems with both the SUSE approach and their patch (as
> outlined in https://bugzilla.novell.com/show_bug.cgi?id=622083#c7)    

I would agree.  They should have taken this to upstream first.  Unfortunately, that did not happen and now we have an issue (whether it is a bug, security, privacy, whatever, is still up for debate) and a CVE name.  That is enough to create the bug to track it.  What happens after that doesn't negate the need for the bug.

Of course, arbitrarily dismissing this is just as arrogant as the SUSE approach, is it not?  Have you brought this up with upstream yet?  Or are you still relying on SUSE to do it (and do you expect them to do it properly, since you're having serious problems with their approach)?  Not that I blame you on that point.
Comment 10 Vincent Danen 2011-06-14 13:30:22 EDT
This issue still seems to be unresolved, so I'm assuming it has not been fixed in Fedora at all as of yet:

http://sourceforge.net/tracker/?func=detail&aid=3030798&group_id=180858&atid=894869
Comment 11 Christoph Wickert 2011-06-14 16:38:01 EDT
Don't forget to file a bug against GNOME 2 and 3, it doesn't lock the display either.
Comment 12 Vincent Danen 2011-06-17 18:57:32 EDT
We're not talking about GNOME 2 and 3 here.  We're talking about this bug.  And _this_ issue is still unresolved, yes?
Comment 13 Christoph Wickert 2011-06-17 19:25:44 EDT
We are talking about this "issue" and in order to determine if it is an *issue* at all, I suggested a look at other desktops handle this. Both Xfce and GNOME don't lock the screen either.

Since you are member of the security response team I'd expect you to
1. first of all do a risk evaluation
2. then talk to upstream
3. file bugs upstream if necessary
4. file bugs for the packages in question and add a reference to the upstream bug reports.

If you are really concerned about security, you should file bugs for the other components as well. If you are just trying to get good numbers for statistics, I can't help it.

Sorry if I sound rude here, but I will not maintain something that a fix is not upstreamed if it fixes an issue that IHMO is no issue.

I will be happy to issue an update as soon as there is a patch available that is
a) upstreamed
b) makes locking configurable.
Comment 14 Christoph Wickert 2011-06-18 07:53:15 EDT
(In reply to comment #13)
> Both Xfce and GNOME don't lock the screen either.

BTW: In GNOME 3 this is way more severe as suspend has replaced shutdown.
Comment 15 jurek.bajor 2011-07-13 02:59:32 EDT
I think SUSE user made an unreasonable filing and request.

I do not think that this should be a permanent feature of LXDE experience.
I agree with Christoph's opinions here that this is about *customization*.

There is a possible solution there:
https://bugzilla.redhat.com/show_bug.cgi?id=714413#c9
with commentary.

JB

Note You need to log in before you can comment on or make changes to this bug.