After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 749847 - (CVE-2015-3213) bypassing locked session without password by crashing Gnome-Shell [CVE-2015-3213]
(CVE-2015-3213)
bypassing locked session without password by crashing Gnome-Shell [CVE-2015-3...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.8.x
Other Linux
: Normal major
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2015-05-25 15:34 UTC by ben
Modified: 2015-06-02 16:31 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8


Attachments
stack trace from core file (87.17 KB, text/plain)
2015-05-27 19:59 UTC, Ray Strode [halfline]
Details

Description ben 2015-05-25 15:34:01 UTC
I gained access to locked session without password.

How to reproduce: 

Login to your desktop with whatever user.
Lock the session.
Left click and hold the upward arrows that are displayed, and quickly move the mouse slightly up (don't let it to go fully up). Release the mouse.
Repeat this procedure several more times, quickly.

This will result in a screen freeze for about 30 seconds.

Than you'll be granted full access to the session without entering the password.

It happened on both RHEL 7 and CentOS 7.

when entering the session in the RHEL, there is an error about a problem in the gnome-shell-3.8.4-31.el7 package, and in its details its saying that gnome-shell was crashed due to SIGSEGV
Comment 1 Ray Strode [halfline] 2015-05-26 12:34:54 UTC
Hi Ben,

I'm having trouble reproducing the crash. Can you tell me a few more things:

1) about how many times do you need to do it for the crash to happen?
2) do you wait for the arrows animation to be on screen before starting?
3) if you open a terminal and run abrt-cli list do you see a crash that mentions gnome-shell?
4) if so, can you go to the directory mentioned in that entry and grab the file sosreport.tar.xz and upload it here?
Comment 2 ben 2015-05-26 17:17:39 UTC
Hi Ray,

1) Not many, about 2-4 times.
2) Yes I see the arrows and than "grab" them.
3) Yes I see gnome-shell crashes in abrt-cli
4) File is here: http://www.filedropper.com/sosreporttar
Comment 3 Ray Strode [halfline] 2015-05-26 20:07:58 UTC
Hey Ben,

Thanks for the quick turnaround, it's very helpful.

From that same directory there are two other files:

1) coredump
2) core_backtrace

can you post those as well?
Comment 4 Ray Strode [halfline] 2015-05-26 20:12:32 UTC
it may be a gnome-desktop idle monitor crasher
Comment 5 ben 2015-05-26 20:54:23 UTC
Hi Ray,

Both files are here: http://www.filedropper.com/coredumpcorebacktrace

Thanks!
Comment 6 Ray Strode [halfline] 2015-05-27 19:59:04 UTC
Created attachment 304102 [details]
stack trace from core file
Comment 7 Ray Strode [halfline] 2015-05-27 20:06:26 UTC
might be fixed by 

https://git.gnome.org/browse/clutter/commit/?h=clutter-1.18&id=97724939c8de004d7fa230f3ff64862d957f93a9

Ben, are you using a physical mouse or a touch device?
Comment 8 ben 2015-05-28 11:47:49 UTC
The RHEL is a VM which I'm using with a physical wireless mouse.

Now, thanks a lot for the fix, but how exactly do I use it?
Comment 9 Ray Strode [halfline] 2015-05-28 13:28:43 UTC
Hi,

I don't actually know that comment 7 is a fix, it's just a possibility. The backtrace is "after the fact", showing heap corruption, so it doesn't pinpoint the cause.  I also can't reproduce, despite spending some time trying.

I've built packages here with the above fix:

https://people.gnome.org/~halfline/0f66bc5e62efc067e35d7d4f3b22b137/clutter-1.14.4-9.test.1/

Mind giving them a try?

Also, what virtual machine software are you using? what platform is the host? Does the host have a touch screen?
Comment 10 ben 2015-05-31 17:36:26 UTC
Ray it worked!! :-)

After installing the patched RPM I tried to reproduce the problem. I did get a 15 seconds freeze, but after that it went back to show the arrows animation and I couldn't get access to the session.

If you still want to know, I am using ESXi 5.5 on a white box server, managing it via the desktop vSphere client, and accessing the VMs via the console window in the vSphere client.

So big thanks to you for all your help, it is really appreciated :-)
Ben
Comment 11 ben 2015-05-31 17:37:52 UTC
And there was no touch screen involved at any point.
Comment 12 Ray Strode [halfline] 2015-06-01 14:28:06 UTC
Hi Ben,

Thanks for testing. This seems like a fairly serious issue and your help has been indispensable.

The reason I kept asking if there was somehow a touch device involved, is because the crasher that was fixed happens in touch event handling code, which left me a little puzzled at first.  Upon looking at the code closer, though, I see an explanation:

    case CLUTTER_MOTION:•
...
    /* Follow same code path as a touch event update */•
•
    case CLUTTER_TOUCH_UPDATE:•

The lack of a "break;" statement between the two case statements, means the problematic code is expected to run for normal mouse motion events as well.

This issue is already fixed in recent upstream versions of clutter, but I'm going to file a downstream bug report at bugzilla.redhat.com to track the issue in Red Hat Enterprise Linux 7.
Comment 13 Ray Strode [halfline] 2015-06-01 14:43:33 UTC
I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1226965 to track this issue downstream.
Comment 14 ben 2015-06-01 16:27:42 UTC
Thanks a lot again Ray, it was a really good experience working with you :)
Comment 15 Ray Strode [halfline] 2015-06-02 16:30:30 UTC
This bug has been assigned CVE-2015-3213 .

Opening bug up at the request of the Red Hat Security Response team
Comment 16 Ray Strode [halfline] 2015-06-02 16:31:17 UTC
Since this bug is already fixed in a stable version of clutter, closing