Bug 1061148 - Security Alert! You can gain user control once you wake up from hibernation! GDM Fails!
Summary: Security Alert! You can gain user control once you wake up from hibernation! ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 20
Hardware: i386
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: fst_owner=kushal
: 1062933 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-04 12:55 UTC by Ali Akcaagac
Modified: 2014-11-06 08:58 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-01 07:00:14 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ali Akcaagac 2014-02-04 12:55:10 UTC
I found a serious security issue which is reproducible everytime here with Fedora 20.

Open gnome-terminal and make it fullscreen (F11)

tar xfjv some big file (say 1gb or something like that).

Under heavy harddrive load go and lock your screen under GNOME.

You get into the "Shield" of GDM (or gnome shell) where you can enter your password, make volume higher or lower and so on.

Now close the lid of your notebook so everything goes into hibernation.

Open your lid of your notebook and press "power" to get the machine out of hibernation again.

Voila you are inside your gnome-session. No password required, you can do whatever you want.

Now imagine you leave your notebook for a coffee break or going to the toilet. Someone could come up and grab your work from your notebook.

Comment 1 Vincent Danen 2014-02-11 21:31:49 UTC
*** Bug 1062933 has been marked as a duplicate of this bug. ***

Comment 2 Vincent Danen 2014-02-11 21:46:43 UTC
Hi, I've tried to duplicate this and am unable to.  Is there something you're doing that you did not document above?  Using GNOME3 with GDM, and creating a tarball of my home directory to stimulate the necessary harddrive churn, it most definitely requires me to provide a password when I wake it up.

This is with gdm-3.10.0.1-1.fc20.x86_64.  Which version do you have installed?

Comment 3 Ali Akcaagac 2014-02-11 22:58:15 UTC
rpm -qa | grep -i "^gdm"
gdm-libs-3.10.0.1-1.fc20.i686
gdm-3.10.0.1-1.fc20.i686

rpm -qa | grep -i "^gnome-shell"
gnome-shell-3.10.3-4.fc20.i686

Ok I will try to re-explain this again.

I have a normal Fedora 20 installation which I installed with netinstall. I updated it with all the packages that came out meanwhile. So this is a brand new fresh installed Fedora 20 (no fedup no yum --releasever). Installation happened on a USB Stick. So the system boots and operates from USB Stick.

I was logged in my user account had google-chrome open and gnome-terminal running in fullscreen. The gnome-terminal operated on a large *.tar.bz2 file (I am not sure anymore whether it was packaging it or unpackaging it). After a while of being off from keyboard, the system locked me and the screen was blank.

I came back to the system and pressed "ESC" (which in former times brought up the password entry) but this didn't happen so I moved the mouse around. The big clock and the shield kind of windows popped up and I entered my password. For some unknown reasons it didn't accept my password. I thought I entered it wrong but later on I realized that I had english keyboard layout available rather than the german one. I must by accident have switched it.

Problem was, I wasn't able to log into the shell anymore and switched by pressing CTRL+ALT+F2 to console. Sadly console was not available. Somehow the "load" of the system or maybe the gfx card driver itself caused some issues. I was locked so I switched back to Xorg by pressing CTRL+ALT+F1. Sadly the entire lock screen was corrupt with graphical artifacts.

I was stuck in an ugly scenario because I was not able to unmount my system properly and was worried to cause a data loss by this issue and I didn't want to hardreset or poweroff the system.

My idea was to close the lid of my notebook and have the system hibernate. I had an expectation that after coming back from hibernation that the graphical issues will go away. So I closed the lid and waited for a few seconds.

Luckely this worked and the notebook turned into hibernation. I waited a couple of seconds and then opened the lid again. The hibernation still caused some blinking LEDs. The system woke up

AND NOW

What happened now was this. I saw the shield for a part of a second. Shield got away on its own without even entering anything. No password nothing!

I found myself in the gnome-shell within my account and was able to interrupt the tar.bz2 process by pressing CTRL+C. I unmounted my mounted device (an external storage).

What I saw during that period was that the screen flickered a couple of times. Trying to go black but came back instantly. I had the impression during that, that the "shield" wanted to lock the system again because it knew (I came from hibernation, I must lock the screen) but failed. Later on I noted a notification below telling me that "locking failed". Why it failed I don't know.

Luckely I had a backup of my installation and now caught attention of this issue. After I made sure that all my external storages are turned off correctly I thought myself that I should investigate a bit more.

I closed the lid from the notebook over again and restated... Same issue!

I rebooted the machine and started the same again. This time without anything running in the background. Lid close. Lid open. Shell! Bypassing Shield.

I also realized - because I was using Fedora 20 for a couple of days now, that every now and then the shield does the same thing.

Once the screen comes out of "blanking" to the shield mode (with clock and password) that it shows the desktop of the user for a part of a second before it shields and asks for the password. So even without any heavy operation in the background this issue appears.

Now whenever I cause some noise on the machine I am always able to see my desktop. I see it long enough to press CTRL+C or click around with the mouse on some running programs to get its focus. Once this happens the shilding fails and you bypass the password entering process.

My final sentence.

I belive this is NOT gdm related because gdm forces you to log out. Once you log out them XOrg seems to be closed and shut down and then reloaded for gdm purposes. Once you enter your password inside gdm it closes Xorg again and then loads the gnome-session. I belive (and I am not really sure but this isn't important anyways) this to be some sort of Console -> XOrg -> gdm -> password -> boom it goes to Console -> XOrg -> gnome-session -> gnome-shell.

Comment 4 Ali Akcaagac 2014-02-12 18:28:19 UTC
I just ran into the same issue today. Just came back from dinner and tried to unshield gnome-shell. Same issue with not being able to enter password. This time I was prepared because I read a bunch of other bugreports (quite similar). I paid attention to a yellow label telling me that the system is booting, rather than telling me wrong password. So it was no keyboard layout issue as I believed it to be a few days ago. I tried switching to console again and voila -> corrupt graphics. Switchd back to XOrg and still had corrupt graphics.... hibernation + wakeup brought me inside gnome-shell without the requirement of password.

Maybe these bugs are related in some ways but triggered differently on different machines (Speed of the machine, Harddrives, Memory, Race Conditions) etc. Who knows.

https://bugzilla.redhat.com/show_bug.cgi?id=1043212

Comment 5 Ali Akcaagac 2014-05-10 07:52:10 UTC
This hasn't occoured anymore. My guessing: It has been fixed with the upcoming releases of either systemd, mutter, clutter or gnome-shell. Can we close this ?

Comment 6 kushaldas@gmail.com 2014-11-01 07:00:14 UTC
Closing this bug. Please reopen if it happens again.


Note You need to log in before you can comment on or make changes to this bug.