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.