[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Oct 2014 16:08:15 -0400 (EDT)
From: cve-assign@...re.org
To: dkg@...thhorseman.net
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: gnome-shell lockscreen bypass with printscreen key
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> another way to look at it is
OK, we'll incorporate your suggestion and assign CVE-2014-7300 for:
"PrtSc is an unauthenticated request that's available to untrusted
parties. A series of requests can consume a large amount of memory.
The combination of this PrtSc behavior and the existence of the
oom-killer allows authentication bypass for command execution.
Therefore, the product must limit the aggregate memory consumption of
all active requests, and the lack of this limit is a vulnerability."
[ the rest of this message has no more CVE assignments ]
> https://bugzilla.gnome.org/show_bug.cgi?id=737456#c34
> We agreed on IRC that the best compromise here is to simply only allow
> screenshots to be saved to the clipboard while the screen is locked.
> That way taking screenshots is not impossible but someone with access
> to the machine can't simply abuse it to fill the disk.
It appears that discussion of this might still be ongoing (e.g., "Can
an unauthenticated person inject anything else into the clipboard
while the screen is locked?" "Yes." etc.). However, a second CVE ID
probably isn't needed. A decision to store PrtSc data in memory,
rather than on disk, is a solution for the original issue (the
ultimate cause of the excessive memory consumption is that the system
can't write PrtSc data to disk as fast as a person can request more
PrtSc data). This new solution happens to address a second issue: a
system administrator might want to ensure that an unauthenticated
person, after going to a locked screen, can't write even one PrtSc
worth of data to disk. This seems to be essentially a policy change,
not a fix for behavior that everyone always would've considered wrong.
> 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.
This seems unrelated to the question of CVE assignments, but one
possibility is that triggering of a video from the locked screen might
be much less acceptable to customers. For example, there might be high
support costs or other expenses whenever a legitimate user presses
Control+Shift+Alt+R once to start a screencast recording, is somehow
distracted (arguably easier when they can't see the screen), and lets
the recording continue for a very long time.
> Turning off the computer is a very different attack from filling up
> someone's home directory.
Right. However, unauthenticated triggering of the oom-killer isn't, by
itself, typically worse than unauthenticated powering off. In the
former case, the user loses data in one process; in the latter, the
user loses data in all processes. In other words, unauthenticated
memory exhaustion wasn't the essence of the original issue. The issue
required the "special" nature of screen-locking processes, i.e., the
unusually severe impact when a process dies.
> Is there a way to make a screenlocking program that is designed to fail
> closed
Alan Coopersmith commented on this separately. All we can add is there
currently isn't a CVE ID for the fail-open behavior of the screen-lock
functionality in gnome-shell. The design wasn't intended to be a
fail-closed design. Also, selecting a fail-closed design would've
required additional research that apparently has never been completed.
We normally don't have CVE IDs of the form "this product doesn't
properly address unsolved research problems."
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJULwEHAAoJEKllVAevmvmsEh4H/3qGYDbpTco65QgJmdW2j1LF
N35V5arMZuWqKqBf6MTQaV2eKiAkRE9PQGrHQ0+K+WL9nfrzRhrf2PvTpeDZ7Tn7
huHYWfxT+pAWzsp8VwjorMvwcryZtwea9+3ma7Cxu0+dkZ10KUJjWvk7llb3fegm
R+npuTYyKYXq+9gs1gYcphUQZwcTiyTgd911/DqEi2MO4lRMHgzAXdrYpejlTEF5
3RbidrQLWt2jhBs3z5mn4xwSU6/eB9jxO6uLzFEbOJvMfDbrKR9SIzfMfQdOH9KO
0bpUml0g/ZoorNAVUpFoNsnXvxkjxFJVyibN+zmSBLSxYFM+vqX2lDinI6tVU5o=
=kOFp
-----END PGP SIGNATURE-----
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.
