Re: Re: gnome-shell lockscreen bypass with printscreen key

[Daniel Kahn Gillmor <dkg () fifthhorseman net>]

On 10/02/2014 12:33 PM, cve-assign () mitre org wrote:
> > https://bugzilla.gnome.org/show_bug.cgi?id=737456
>
> Clearly, something is wrong, but the CVE ID or IDs need to apply to a
> specific aspect of the problem.
>
> Our understanding from
> https://bugzilla.gnome.org/show_bug.cgi?id=737456#c10 is that "the
> prtsc key is not disabled when the screen is locked" is intentional
> behavior. Thus, that's not the root cause. 

I think i agree with this analysis.  I only discovered this problem
because i was trying to take a screenshot of the lockscreen to report a
different (non-security) bug in the lockscreen.

I did not expect to be able to use the printscreen key combination to do
that, but the fact that i could do so was useful.

However, the screencapture (video) feature *is* disabled during
lockscreen for precisely the reasons i expected printscreen to be
disabled.  I'm not sure what to make of that pair of decisions.

> It might be reasonable to
> argue that, as a consequence, anyone with physical access to that key
> is implicitly allowed to consume memory and disk space. In many
> environments, anyone with physical access to that key also happens to
> be able to turn off the computer.

Turning off the computer is a very different attack from filling up
someone's home directory.  You recover from a turned-off computer by
turning it back on.  If your home directory is full, you have to figure
out what is taking up the storage space, which is not something all
users are familiar with.

If your home directory uses metered storage (i.e. you pay by the MiB) or
is backed up to a service that is itself metered, then filling up the
home directory is actually a direct financial cost to the end user in a
way that turning off the computer does not.

> There could be a CVE assignment for
> https://bugzilla.gnome.org/show_bug.cgi?id=737456#c20 - "for that
> short period of time those windows are not only shown (which is a bad
> enough privacy issue on it's own), but also accept input (which makes
> the already-bad issue even worse)." However, the bug discussion
> doesn't suggest that there's a reasonable way to solve this within
> gnome-shell itself. In other words, gnome-shell doesn't have any
> direct or immediate ability to control the screen when it's not
> running.

I see how this is difficult to assign as a specific problem.
Alternately, one can argue that *any* crashing bug in a program designed
to lock the screen is by definition a security flaw.  If gnome-shell
wants to provide lock-screen capability, then any crashing bug in
gnome-shell that can be triggered while the screen is locked is a
security vulnerability.

Any crash in xscreensaver, for example, is a security flaw.

> Possibly we're left with the following, which is unusual for a CVE but
> still valid: "PrtSc is an unauthenticated request that's available to
> untrusted parties. It's also a very expensive request. The combination
> of this PrtSc behavior and the existence of the oom-killer allows
> authentication bypass for command execution. Therefore, PrtSc must be
> rate limited, and the lack of rate limiting is a vulnerability."
> Unless there's a better alternative, the CVE ID will be assigned for
> that vulnerability characterization.


The above sounds about right to me.  another way to look at it is:

 * gnome-shell is supposed to lock the screen.
 * when it is doing this, it must not crash.
 * gnome-shell has a short-term memory leak via prtsc
 * prtsc can be triggered while locked.
 * the short-term memory leak is bad enough to cause a crash.
 * when locked, gnome-shell *must* police its own internal resource
usage to avoid crashing.
 * rate-limiting is one way of policing this resource usage.

However, this still leaves gnome-shell users vulnerable to the next
gnome-shell crash while locked.  it's fixing one crashing problem, but
not fixing the larger problem that a screenlocking program effectively
fails open when it fails.

Is there a way to make a screenlocking program that is designed to fail
closed instead?

fwiw, https://bugzilla.gnome.org/show_bug.cgi?id=737456#c5 raises an
interesting alternate approach to resolving the underlying problem:

    Not sure what crazy side effects that might have if any but ...
    Jasper can we simply unmap all windows when we lock and map them on
    unlock?

I don't know enough about X11 to know if this proposal is sufficient to
protect the user from command execution after a gnome-shell crash, or
what the side effects would be.

        --dkg

Attachment: signature.asc
Description: OpenPGP digital signature