Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 3 May 2014 03:10:35 -0400 (EDT)
Subject: Re: Ubuntu 14.04: security problem in the lock screen

Hash: SHA1

Issues #1, #2, and #3 are clearly within the scope of CVE, and have
their CVE IDs below. The common theme is "the user intended to lock
the screen, the UI indicates that the screen is successfully locked,
the user physically leaves, but this locking can then be bypassed by a
physically present attacker."

Two of the other bugs referenced within pages for #1, #2, and #3 are


Quite possibly, these should also have CVE IDs, but there are
potentially valid counterarguments. First, at a high level, neither of
these matches the "common theme" described above.

For 1308572/comments/6, one counterargument is that a user isn't
entitled to expect that screen locking will continue to work
flawlessly if he decides to kill arbitrary processes that are, more or
less, related to screen/display functionality. Also, the risk is very
low in the sense that, before a user physically left, it would usually
be obvious that the screen was not successfully locked. However, there
is conceivably a scenario in which killing compiz is a supported (or,
at least, reasonable) user activity, and the user must leave
immediately after a screen-locking attempt without waiting even a few

For 49579, there are many ways to summarize the long discussion: here
is one of them. A typical end user may expect that automatic screen
locking succeeds regardless of what the user had been doing (e.g., if
the user was in the middle of a menu operation). A developer may
expect that automatic screen locking succeeds in cases where the
implementation is achievable in a reasonable amount of time. There are
(at least) three possible conclusions:

  1. The end user wins. This is a vulnerability regardless of what
     documentation exists, because it is unreasonable to expect an end
     user to learn about the failure conditions.

  2. This is a vulnerability if the documentation is not "good
     enough." For example, if the only documentation is bug 49579
     itself, maybe that's not enough.

  3. The developer wins. This is never a vulnerability. Yes, it would
     be nice for automatic screen locking to succeed in more cases,
     but this is not a high-value security feature for all users, and
     it's OK for development to use a "reasonable effort" approach
     rather than a "must cover every possible case at all costs"

> Issue #1 (Before 14.04 came out):
> Marco Agnese discovered that Unity 7.2.0 incorrectly handled entry activation on
> the lock screen, resulting in the lock screen crashing and the session becoming
> unlocked.
> Reference:

Use CVE-2014-3202.

> Issue #2:
> Giovanni Mellini discovered that Unity 7.2.0 could display the Dash in certain
> conditions when the screen was locked. A local attacker could possibly use
> this issue to run commands, and unlock the current session.
> Reference:

Use CVE-2014-3203.

> Issue #3:
> Frederic Bardy discovered that Unity 7.2.0 incorrectly filtered keyboard
> shortcuts when the screen was locked. A local attacker could possibly use
> this issue to run commands, and unlock the current session.
> Reference:

Use CVE-2014-3204.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.