Private screen data compromised on wake from suspend

[KloudKoder]

Operating System: Solus 3.999

Budgie version: Budgie 10.4

The issue encountered

When waking from sleep, the video memory is restored prior to login, so without entering a password, I can see all the information that was on the screen prior to sleep. This constitutes a security vulnerability of unknown significance. All that needs to be done to fix it is to ensure that this screen isn't displayed until after login. Surely that must be possible even if this is a driver bug.

Steps to reproduce the issue

Lock the screen. Wait for the machine to enter a low-power state. Press a key to wake. Depending on whether or not an external monitor is connected, and exactly how long it takes to come back up, you may or may not see this issue. I'm using Intel video chips and can reproduce this easily.

...

[endorfina]

It does appear every time on wake as a half a second flicker for me.

[KloudKoder]

It's really random, unfortunately. Sometimes it doesn't occur at all, sometimes it shows the private screen for long enough to capture on video, and once it even allowed me to bring up the system menu before showing the password dialog!

[fossfreedom]

https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/1280300

See comment #19

So if anyone knows another way to resolve this is a years old issue that cannot be resolved with X based desktops.

On Fri, 20 Apr 2018, 18:46 KloudKoder, notifications@github.com wrote:

It's really random, unfortunately. Sometimes it doesn't occur at all, sometimes it shows the private screen for long enough to capture on video, and once it even allowed me to bring up the system menu before showing the password dialog!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/budgie-desktop/budgie-desktop/issues/1374#issuecomment-383171954, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8zkDoBkwK5t9lgI1CdeBBPIFnh2bTuks5tqh8JgaJpZM4TNA4H .

[KloudKoder]

This issue is so awful that even a mitigation rather than a solution would help. For example, automatically minimizing all windows before attempting to lock the screen prior to suspend. Muting the mic would also help, as it seems like it survives lock as well. I've since discovered that sometimes, when the lid is closed, it doesn't even attempt to lock at all, so as a further precaution, users should make sure that lock has engaged before leaving a laptop unattended.

[KloudKoder]

This has gotten even worse. Upon wake, the screen sits there for up to 10 seconds while the UI is hard frozen, explosing all visual information for the world to see. Perhaps we could set brightness to 0% just before sleep, then restore it only after the password dialog has been painted? (On some machines, 0% is more like 10%, but frankly any lousy workaround would be an improvement at this point.)

[KloudKoder]

I found a workaround: first lock the screen manually before suspending. This still needs to be fixed, though, because it's a security lapse just waiting to happen.

[KloudKoder]

Recently this problem seems to have gotten worse in the sense that shutting the lid doesn't even lock the screen at all, like half the time. So until this is fixed, I definitely recommend the above workaround.

[lallenfrancisl]

https://bugzilla.gnome.org/show_bug.cgi?id=753678

It seems like a gnome issue

[bwat47]

Based on the last comment in that gnome bugzilla issue, I found a workaround that doesn't completely resolve this issue, but does seem to improve things:

Basically, I force the screen off prior to suspend using a systemd sleep hook:

Create the file /usr/lib/systemd/system-sleep/resumepre.sh

With the contents:

!/bin/sh

case $1 in pre) /usr/bin/xset -display :0 dpms force off ;; esac

Make the file executable:

chmod 755 /usr/lib/systemd/system-sleep/resumepre.sh

With this I still see a flash of the desktop on resume, but it seems significantly briefer than it was prior to applying this workaround.

It does at least seem to completely fix the issue that I mentioned in #1304 where the screen turns off after resuming. I now always see the lock screen (instead of the lock screen and then a black screen) after resume

[bwat47]

I noticed that once every few resumes it was still giving me the black screen, so I added another script to ensure that the screen has time to turn off before it goes into suspend:

/usr/lib/systemd/system-sleep/sleep.sh

#!/bin/sh
case $1 in
  pre)
    /bin/sleep 2
  ;;
esac

Systemd doesn't suspend the system until all of the 'pre' scripts in this directory have finished running, so this delays suspend by 2 seconds, ensuring that the other script can fully shut off the screen before suspend.

Now the black screen on resume issue seems to be reliably fixed on my system.

As a bonus, adding this second script also seems to fix this issue where the desktop is briefly displayed on resume. Tested quite a few suspend/resume cycles, and I'm no longer seeing the contents of my desktop being displayed before the lock screen!

[KloudKoder]

Briiliant! As you've discovered, I think the solution to this is likely the solution to #1304 . Or "a" solution, rather. The bug probably has various manifestations, depending on what incompetent part of the stack is intervening in entering and exiting sleep on any given platform. Still, I'm thankful for this reasonable workaround.

[KloudKoder]

I have a feeling that all these are related by improper or incomplete entry/exit to/from idle or sleep (S1 or S3):

https://github.com/pop-os/pop/issues/463 solus-project/budgie-desktop#1374 solus-project/budgie-desktop#1082 https://github.com/pop-os/pop/issues/466

bwat47's workarounds in the first 2 appear to be effective for me, although it's hard to be sure because these bugs don't occur every time, and might literally depend on the temperature.

Secondly, here's what to do if you come back to a messed up screen or a crazy mouse pointer. Just to be on the safe side, save everything before you test this:

Push Ctrl+Alt+F11
Wait until the screen settles down, usually to black or some weird error message
Push Ctrl+Alt+F2
Wait til the desktop restores
If still abnormal try this all again

These key combos seem to be hardwired into GNOME. I actually discovered the first one by accident, and didn't know to get out of it. Unfortunately, there's no way to turn them off under the keyboard settings, so it's an accident waiting to happen (and who would guess that Alt+F2 is the way to undo it?!). But now, these "features" are you friends because they protect you from the disaster that is bad sleep/wake behavior.

One final hunch is that all this points back to quality problems with the Intel video driver. This is a compelling theory based on a lot of reading, but I have no proof. Indeed, on every single boot, my login screen goes crazy with video problems, likely due to the same underlying bug.

[bwat47]

I can't say I've ever seen those mouse cursor issues (or video issues on boot) in my case (using intel hd 620)

In my case, with gnome-shell I can't re-create any issues on resume from suspend, the lock screen is always the first thing that I see.

With any DE that uses either gnome-screensaver or MATE-screensaver though, I can re-create seeing the contents of my desktop on resume. My theory with those desktops/lock screens was that it was a simple case where it doesn't even attempt to lock the screen synchronously before suspending, and the sleep workaround just gave it enough time to engage the lock screen before the system actually suspended.

Gnome-shell I believe at least attempts to lock the screen synchronously before suspending (and on both of my laptops it seems to work properly with gnome), so I'm not sure exactly what causes people to see this issue with gnome.

[KloudKoder]

I suspect it comes down to one's particular hardware configuration and the order in which stuff is put to sleep. Depending on the outcomes of this race condition, and perhaps the memory layout, the video driver may, or may not, be able to corrupt the sleep/resume process. The last time I checked on the Intel video driver, it hadn't been updated in years, and indeed this problem has existed for years. It's also hard to debug because we can't just valgrind it, as we could do with a desktop app. By the way, can your "sleep 2" hack work on boot? If so, what additional script would be necessary to create? When I boot to cryptsetup to unlock my drive, everything is randomly flashing with video garbage until I enter my password.

[desyncr]

For anyone looking for a quick workaround look this comment: https://bugzilla.gnome.org/show_bug.cgi?id=753678#c54. Worked for me.

[sdh0618]

I noticed that once every few resumes it was still giving me the black screen, so I added another script to ensure that the screen has time to turn off before it goes into suspend:

/usr/lib/systemd/system-sleep/sleep.sh

#!/bin/sh
case $1 in
  pre)
    /bin/sleep 2
  ;;
esac

Systemd doesn't suspend the system until all of the 'pre' scripts in this directory have finished running, so this delays suspend by 2 seconds, ensuring that the other script can fully shut off the screen before suspend.

Now the black screen on resume issue seems to be reliably fixed on my system.

As a bonus, adding this second script also seems to fix this issue where the desktop is briefly displayed on resume. Tested quite a few suspend/resume cycles, and I'm no longer seeing the contents of my desktop being displayed before the lock screen!

This only seems to work for me when I run "systemctl suspend". I still have the same issue when I suspend by close the laptop lid or click the suspend bottom from the DE.

[Dehalion]

I have the same issue. What is the best try for a workaround?

[emash]

Still open. Maybe alternative, some other app to install etc?