mate-screensaver screen lock can be bypassed by power cycling monitor [$110]

[fizzfaldt]

Expected behaviour

Lock Screen
Turn off monitor (either by power management putting it to sleep, or by pressing power button)
Turn monitor on
Start typing
Expect to see lock screen on monitor

Actual behaviour

Lock Screen
Turn off monitor
Turn monitor on
Start typing
Expect to see lock screen on monitor

Steps to reproduce the behaviour

adddate() {
   while IFS= read -r line; do
      echo "$(date) $line"
   done
}
killall mate-screensaver
mate-screensaver --no-daemon --debug 2>&1 \
  | adddate  > screen.log

Wait 60 seconds
Lock screen (I used Window manager shortcut)
Wait 60 seconds
Power off monitor (soft off)
Wait 60 seconds
Power on monitor
Wait 9 seconds (that's how long it takes monitor to boot)
Can see and use screen/type/etc; it is (effectively) unlocked.

Notes/logs:
mate-screensaver-command -q reports:

• after killall mate-screensaver:
  • Screensaver is not running!
• After re-running mate-screensaver:
  • The screensaver is inactive
  • The screensaver is not inhibited
• After locking (stays this way forever even while using the computer)
  • The screensaver is active
  • The screensaver is not inhibited

Same as above, annotated with logs: (attached for ease of reading)
mate-screensaver --no-daemon --debug
mate-screensaver-1.txt

Wait 60 seconds
Lock screen (I used Window manager shortcut)
mate-screensaver-2.txt

Wait 60 seconds
Power off monitor (soft off)
mate-screensaver-3.txt
dmesg-3.txt

Wait 60 seconds
Power on monitor
mate-screensaver-4.txt
dmesg-4.txt

Wait 9 seconds (that's how long it takes monitor to boot)
Can see and use screen/type/etc; it is (effectively) unlocked.
dmesg-5.txt

(there is no dmesg-1.txt or dmesg-2.txt or mate-screensaver-5.txt (blank during that time))

Troubleshooting

This occurred on two machines.

• Home Machine
  • Problem occurred on Ubuntu 16.04 (do not have logs unfortunately)
  • Unsure what version of mate it was at the time
  • If relevant
    • monitor was 2560x1600
    • Uses nvidia drivers
  • Upgrading to Ubuntu 18.04 (which upgraded mate to 1.20.0) fixed the problem on home machine.
    • Upgrading to Ubuntu 18.04 on home machine merely made the problem stop when I manually power off the monitor, but if it powers off due to inactivity the problem still occurs.
• Work Machine
  • Problem occurred on Ubuntu 17.10 (mate 1.18) (do not have logs unfortunately)
  • Upgrading to Ubuntu 18.04 (mate 1.20.0) did NOT fix the problem.
  • If relevant
    • monitor is 3840x2160
    • Problem still occurs if I switch to different resolution
    • Has no dedicated video card/using intel onboard graphics
    • monitor is a USB hub.. problem still reproduces if I disconnect the usb cable and have the keyboard connected some other way.

Please let me know what other logs/steps may be useful.

MATE general version

1.20.0

Package version

mate-screensaver 1.20.0-1
See attached
mate-packages.txt
for full list of all mate-related package versions

Linux Distribution

Ubuntu 18.04

Downstream bug link

https://bugs.launchpad.net/ubuntu/+source/mate-screensaver/+bug/1768352

[fizzfaldt]

May be related to #152 and/or #126

[fizzfaldt]

I've placed a bounty on this; how do I get the bounty label added?
https://www.bountysource.com/issues/57823146-mate-screensaver-screen-lock-can-be-bypassed-by-power-cycling-monitor

[raveit65]

I have also several reports open at redhat Bugzila about problems with locking the sceen.
https://bugzilla.redhat.com/show_bug.cgi?id=1397900
https://bugzilla.redhat.com/show_bug.cgi?id=1566571
https://bugzilla.redhat.com/show_bug.cgi?id=1470306
https://bugzilla.redhat.com/show_bug.cgi?id=1474046
https://bugzilla.redhat.com/show_bug.cgi?id=1497930

[phocean]

@raveit65 The issue #158 I opened looks very similar to yours.

Also, added to the bounty.

[oz123]

Does someone knows if this affects also earlier versions of mate-screensaver?

[oz123]

Also, maybe mate-screensaver should be completely archived? I have now switched to xscreensaver after reading this https://www.jwz.org/xscreensaver/toolkits.html

[phocean]

xscreensaver has a security history that does not make it ideal.
I believe it would be better managed by the display manager.

[oz123]

@phocean, can you please refer to links? Better explain?

[phocean]

I lost faith in the utility with CVE-2015-8025:

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

I don't want my security to depend on a single utility that may segfault for various reasons, leaving the computer unlocked.

There is also an issue with most lockers on Linux : when you wake up your computer from suspend, it would show your desktop for about 1 second. Enough for a motivated attacker to take a photo of confidential data, for instance, or even trigger a mouse click (mouse event work during this period).

This is just one of the many reports you can find on Internet:

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

Having a secure locking infrastructure is far from trivial, much more complex than it seems at first.

To my knowledge, only Gnome 3 with gdm managed to do something quite robust (modulo the screen flash issue).

The idea is that I don't want my locking session to depend on a simple X program.

If there is a segfault, like in the DM, I would prefer it crashes my entire session if it has to, so that it gets never unlocked by an attacker.

Anyway, I believe such an architecture will be a requirement for Wayland.

[oz123]

@phocean you have referenced one problem with xscreensaver, while both gnome-screensaver and mate-screensaver (which is based on the former) have far more known CVEs ...
Also, the issue described here is a variant of the same issue you linked to. However the issue you linked to is fixed, while the issue here isn't.
I also believe the issue described here will affect gnome-screensaver due to their shared histroy, but I am not going to spend time proving this, because I don't have the time nor the interest to invest in GNOME.

[phocean]

@oz123 sure, I am not asking anything: you asked, I just explained.
The fact is that locking a screen with a X11 screensaver utility is outdated and will keep causing issues.

Can't it be addressed without coding?

Regarding this issue, I managed to get something much more robust, and with a lower attack surface (fewer LoC) with xss-lock and slock (or i3lock).

[lukefromdc]

This sort of thing is another example of why when security REALLY counts, a machine should be turned all the way off (poweroff and not hibernated nor suspended) when not in use. This is mandatory when encryption is relied upon, and apparently important the rest of the time too. Any application written in any language can have bugs, especially when it may be compiled many ways and run in many distros. X screensavers in particular have issues bad enough that Wayland devs cited them as a reason for moving away from X altogether.

This can be a real pain in the backside, so if anybody does manage to harden any screenlocker to the point that a serious, determined attacker can't recover your session, that will be worth a lot of saved time to a lot of people who are not using encryption, or who are in an environment where coworkers would not have long enough unsupervised access to attack encryption but might be able to sit at the machine long enough to power-cycle a monitor, suspend and restart(though this is reported to have the opposite problem), or execute a similar quick procedure.

[phocean]

@lukefromdc I don't get your point, even though I am aware of these facts (and that is probably not the place for a discussion).

The generic considerations you mention are not a valid reason to not harden the locker security.

It took my collegues less than one minute to get a remote shell on my machine while I was just going to the restroom. Do not tell me that I should have turned off my computer in such a circumstance...

Meanwhile, Windows goes as far as disabling DMA while the computer is locked...

So, I am still convinced that using the DM is a much safer approach, so at least an unexpected crash takes also the session down.

[lukefromdc]

According to https://linux.slashdot.org/story/15/01/28/1520252/why-screen-lockers-on-x11-cannot-be-secure all screenlockers on X are actually only emulating screen locking. What they do is to draw their own fullscreen window over everything else and try to catch all keyboard and mouse input(latter part is really critical), but the problem is that Xorg itself does not treat the screenlocker as anything more than just another app.

Still, this should not mean everything else gets drawn on top of the screenlocker or that it stop drawing at all, rather it's probably why so many X screenlockers show the desktop and applications for a second or so before finally rendering the lock screen on top of them.

Three years ago, t he KDE folks put a lot of effort into hardening their screenlocker and plugging two nasty bugs, but then turned around and published this blog post with a lot of details about the limitations of Xorg screenlockers:
https://linux.slashdot.org/story/15/01/28/1520252/why-screen-lockers-on-x11-cannot-be-secure

Google is offering this screenlocker designed to be as secure as they can get it:
https://github.com/google/xsecurelock

As I have said elsewhere, I only have encrypted machines that must be shut down when unguarded, which is why I don't normally run a screenlocker but when someone has code up that might fix this I can build and test it. I don't have the experience in screenlockers to write this myself, having not poked around the app's code and familiarized myself with it like I have with Caja, mate-panel, the applets, etc.

@raveit65 , @monsta, @sc0w,@vkareh, any ideas for this?

EDIT: This is a really ugly bug, as the poster reports the lock screen stays down with this trivial attack

EDIT2: The KDE folks also found as discussed in the second link that making screen locking a compositor task makes it much more secure, but of course in MATE we support multiple window managers. Still, we could implement some of that in Marco, and use a runtime check to see if Marco is running to use that codepath, and use the existing codepath with a security warning given if compiz or another WM is being used. Ideally that would also be ported to compiz-reloaded, perhaps as a plugin.

[phocean]

@lukefromdc thank you for the interesting pointers.

However, I disagree with your point with encryption. I work in infosec, so for sure my disk is encrypted too, plus secure boot, disk password and a few custom stuff... it just does not address the same threat at all.

You may not need it for your use case (are you working at home?), but for sure many people need a strong screenlocker.

[raveit65]

I tried to reproduce https://bugzilla.redhat.com/show_bug.cgi?id=1566571 yesterday with my notebook (fedora 28) and a external monitor.
But i couldn't reproduce the issue with display-power off and suspend-to-ram.
My results:

- MATE is built from master (developing branch)
- using a second monitor, plugged in via hdmi port to my notebook
- a) screensaver bump in after 1 min
- b) display power off after 5 min.
- c) suspend-to-ram after 10 min

Ending a) state gives me the lockscreen-dialog on notebook display and second monitor shows the screensaver.

Ending b) state gives me the lockscreen-dialog on notebook display and second monitor shows a black screen.

Ending c) state gives me the lockscreen-dialog on notebook display and second monitor shows a black screen.

I get same results if the external monitor is the primary-monitor. 

I will try again with powering off or unplug the external monitor.
This was here the problem, right?

@lukefromdc
I think all of this is handled by systemd on modern distros.
And i agree with you this needs to be fixed.

A girlfriend of mine use a mac notebook and she never shutdown her mac. She only use 'lid-close`, to power on/off their system.
Sadly i think this is the common use of a notebook from a typical users, who don't care about what is inside their box , nowadays.

[raveit65]

Btw. here is another locker , but last commit was from 2017 -_-
http://www.webupd8.org/2013/07/light-locker-new-session-locker-for.html
https://github.com/the-cavalry/light-locker

[lukefromdc]

Since the origjnal poster simply specifies "monitor" and not a particular monitor, I think this is about power-cycling the PRIMARY monitor, which would make this a desktop-only bug. A laptop would be OK as its monitor cannot be power cycled, but an office full of desktops running MATE would leave each workstation vulnerable to everyone else in the office once it got out that turning the monitor off and back on gave access. This is so simple it is guaranteed to be found by accidend in a large enough office.

[lukefromdc]

According to #145 (comment)
some lockers use a vt switch to avoid the mess of having to draw over everything else and thus close some of the worst X screenlocker holes.
EDIT: Light-locker was apparently written at least in part to fix an issue with the screensavers than commonly used with lightdm that it was possible from the locked screen to Ctrl+Alt+F7 back to the unlocked desktop.

[raveit65]

I was able to reproduce the issue with my main box with nvidia-graphic and using one monitor at display-port.

1. Locking the screen with panel applet
2. Power off/on (using the physical switch) my monitor.

But it isn't a clear reproducer, sometimes i had access to my desktop without a lockscreen-dialog, sometimes the dialog displays well.
......i hate such issues....

I think this gsettings key from mate-power-manager has an influence on this problem.

[rave@mother ~]$ LANG=C
[rave@mother ~]$ gsettings describe  org.mate.power-manager sleep-display-ac
The amount of time in seconds before the display goes to sleep when the computer is on AC power.
[rave@mother ~]$ gsettings get org.mate.power-manager sleep-display-ac
2100

Because with changing the value for this key i could trigger the issue again.

I used those commands to debug mate-screensaver and mate-power-manger.

killall mate-screensaver && mate-screensaver --debug
killall mate-power-manager && mate-power-manager --verbose

Screensaver logs were interesting. In both cases they look very similar and the lockscreen-dialog seems to be running.
I found those differences in logs.
Log without visible lockscreen:

[unfade_idle] gs-manager.c:1224 (13:25:25):	 resetting fade
[gs_fade_reset] gs-fade.c:863 (13:25:25):	 Resetting fade
[on_screen_monitors_changed] gs-manager.c:1581 (13:25:37):	 Monitors changed for display :0: num=1
[gs_job_stop] gs-job.c:524 (13:25:37):	 stopping job
[gs_job_stop] gs-job.c:528 (13:25:37):	 Could not stop job: pid not defined
[gs_job_stop] gs-job.c:524 (13:25:37):	 stopping job
[gs_job_stop] gs-job.c:528 (13:25:37):	 Could not stop job: pid not defined
[gs_window_dialog_finish] gs-window-x11.c:1454 (13:25:37):	 Dialog finished
[keyboard_command_finish] gs-window-x11.c:1318 (13:25:37):	 Keyboard finished

Same with a working lockscreen.

[unfade_idle] gs-manager.c:1224 (13:35:39):	 resetting fade
[gs_fade_reset] gs-fade.c:863 (13:35:39):	 Resetting fade
[error_watch] gs-window-x11.c:1022 (13:35:49):	 command error output: [request_response] mate-screensaver-dialog.c:136 (13:35:49):	 got response: -2

[error_watch] gs-window-x11.c:1022 (13:35:50):	 command error output: 

[error_watch] gs-window-x11.c:1022 (13:35:50):	 command error output: (mate-screensaver-dialog:10204): GLib-CRITICAL **: 13:35:50.023: Source ID 19 was not found when attempting to remove it

[error_watch] gs-window-x11.c:1022 (13:35:50):	 command error output: [do_auth_check] mate-screensaver-dialog.c:289 (13:35:50): Verify user returned: TRUE

[lock_command_watch] gs-window-x11.c:1589 (13:35:50):	 command output: RESPONSE=OK

[lock_command_watch] gs-window-x11.c:1611 (13:35:50):	 Got OK response
[gs_window_dialog_finish] gs-window-x11.c:1454 (13:35:50):	 Dialog finished
[keyboard_command_finish] gs-window-x11.c:1318 (13:35:50):	 Keyboard finished

So why Monitors changed for display :0: num=1 in bad log?

Full logs are here:
https://www.dropbox.com/s/mtmnizud94i7ovt/locksreen-debug-bad-log?dl=0
https://www.dropbox.com/s/rhbd5g4he7xixk0/locksreen-debug-good-log?dl=0

[raveit65]

I found a working workaround,.......using gnome-screensaver 😄
and i can't reproduce the issue any more with using gnome-screensaver.
Instructions:

1. Install gnome-screensaver from your distro package-manager.
2. Disable mate-screensaver in mate-session-properties (no auto-start), uninstall is an option but not needed.
3. Add /usr/bin/gnome-screensaver to auto-start
4. Restart session
5. Create a application-launcher for the panel with that command to look the session.
   /usr/bin/gnome-screensaver-command -l
6. Controling g-s via dconf-editor or gsettings command-line.
   Gnome-screensaver use the same gsettings key for idle-activation than MATE.

[rave@mother ~]$ gsettings get org.mate.session idle-delay
1
[rave@mother ~]$ gsettings describe  org.mate.session idle-delay
The number of minutes of inactivity before the session is considered idle.

Other keys for g-s:

[rave@mother ~]$ gsettings list-keys org.gnome.desktop.screensaver
picture-opacity
logout-enabled
lock-enabled
logout-delay
embedded-keyboard-enabled
primary-color
idle-activation-enabled
secondary-color
logout-command
color-shading-type
embedded-keyboard-command
picture-options
lock-delay
show-full-name-in-top-bar
picture-uri
status-message-enabled
user-switch-enabled

That's enough for an office/gaming PC with one or 2 external monitors.
Notebook users needs to patch mate-power-manager to have a working lock-screen with "lid-close" function.
Simply renaming all occurrences of mate-screensaver to gnome-screensaver.
A patch can be found here in this experimental branch for mate-power-manager.
mate-desktop/mate-power-manager@aa36d35
I think user-switching function in lock-dialog will only work if you're using gdm as DM.
Happy testing ;)

I looked in to gnome-screensaver git commit history for a solution for mate-screensaver, but no luck yet.

[lukefromdc]

I am about to test this with an initial test install from master, trying to invoke the bug, then checking the PR to see if it is fixed. This issue is world-class ugly, and any security feature that can by bypassed by power cycling is a dangerous trap for the unwary. This is nearly as bad as the Android 5 bug where a failed attempt to encrypt the fs exits silently and appears to have succeeded.

[lukefromdc]

I could not get mate-screensaver to show the unlocking dialog with lightdm (and GTK 3.23), and whether because of this or something else power cycling the primary monitor with the secondary monitor staying OFF had no effect. If I pressed a key on the keyboard I got my desktop image as used also as a lightdm background, but no lightdm greeter or other password unlocking option. Thus, I cannot directly test this but at least the PR built and ran, with same behavior here either way

[raveit65]

@lukefromdc
Weird, i am using also lightdm with slickgreeter as UI-frontend. But i don't think that this is related to DM.
Are you shure that your screen is locked and do you see the selected screensaver theme, after you locked the screen with panel-lock-launcher?
What value are you using for sleep-display depends if you are on battery or ac?

gsettings get org.mate.power-manager sleep-display-ac
gsettings get org.mate.power-manager sleep-display-battery

Edit: and is this key enabled?

[rave@mother ~]$ gsettings get org.mate.screensaver lock-enabled
true

[lukefromdc]

This was on a desktop, screen was locked and screensaver shown when locked from the main menu's panel-lock-launcher, just no login dialog ever. I have the gtk greeter in Lightdm

[oz123]

@raveit65, I am using gentoo.

[raveit65]

Hmm, i am not really firm with packaging gentoo.
But i tested it again with my notebook. Unplugging the external monitor at hdmi port several times doesn't crash the screensaver with fedora f28.
The desktop is locked on both monitors.
I tested this with MATE from master branch and MATE-1.20.x from fedora 28 repos + the fixed mate-screensaver version from updates testing https://bodhi.fedoraproject.org/updates/FEDORA-2018-f4c88b2bb5
So, i am still wondering why mate-screensaver-1.20.1 + the fix crashes for you.
Can you asked your gentoo maintainer for confirming the crash?

[oz123]

@raveit65 the gentoo maintainer is practically me. I have used the ebuilds from here. My system runs with all mate components built from the current master branch.

[raveit65]

OK :)
I thought Hardass ( or similar name) is the current maintainer.

[raveit65]

Not sure if this causes the issue but building against systemd and consolekit is wrong.
https://github.com/oz123/mate-de-gentoo/blob/master/mate-extra/mate-screensaver/mate-screensaver-1.20.1-r1.ebuild#L68
If you use systemd you should disable consolekit.
See my spec file from fedora.
https://src.fedoraproject.org/cgit/rpms/mate-screensaver.git/tree/mate-screensaver.spec

[oz123]

@raveit65 np-hardass is missing practically. There are some people working on ebuilds for gentoo officially. I used their work to create my ebuilds.
Also, I am compiling using:

$ equery u mate-screensaver
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for mate-extra/mate-screensaver-9999:
 U I
 + + X          : Add support for X11
 + + consolekit : Enable support for sys-auth/consolekit
 - - debug      : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
 - - gtk3       : Build with GTK+3 instead of GTK+2
 - - libnotify  : Enable desktop notification support
 - - opengl     : Add support for OpenGL (3D graphics)
 + + pam        : Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip
 - - systemd    : Enable use of systemd-specific libraries and features like socket activation or session tracking

So it's only consolekit, it was configured with:

--with-console-kit --without-libnotify --without-libgl --without-systemd 

[raveit65]

But why consolekit and not systemd?
Consolekit is obsolete since several years, by all major distros.
Sorry, i cant help with consolkit as i don't use it and i know nothing about.

[oz123]

@raveit65 consolekit in gentoo is consolekit2.
You know why systemd is not an option. If I was in the business of doing what everybody else does I was not writing you here. I'd be using gnome, won't I? ;-)

Also, I don't think this error has anything to do with systemd or consolekit (at least that is what I understand from the crash backtrace I posted above).

[raveit65]

I love to control my box with systemd, using deprecated consolekit-1/2 isn't an option for me.
And don't get this crash with 2 boxes with systemd.

Btw. Are you sure you applied 762ae73 correct?

Did you restart the box?

[oz123]

I applied the patch. It's also in the current master. The ebuild simply pulls the git master and compiles it.

Good point regarding restart!

OK, I have since yesterday restarted my laptop, and currently I can't crash mate-screensaver by unplugging.

One issue which is still there yet, is that the screen flicker for a second, during this second the content of my desktop is shown. I tried a couple of times to capture the mouse and keyboard to prevent mate-screensaver from covering the whole screen. I failed (which is a good thing), but a I am afraid a more sophisticated tester would be able to somehow during this second kill mate-screensaver.

[raveit65]

I am so happy that you could solve your local problem :)

[lukefromdc]

That momentary flicker has been called out as a security issue in X itself, as this is apparently a common problem in screensavers that draw over the other X windows. Details earlier in this thread at
#155 (comment)
One workaround some other screensavers have resorted to is using a VT switch and intercepting efforts to ctrl-alt-F7 back to the desktop. Any flicker with that will be to a black screen, but it's a major rewrite.

[joakim-tjernlund]

@raveit65 , if MATE could support elogind too one could eventually dump consolekit2
Supporting elogind should just be a matter of changing the include prefix and linking against a
different library.

[raveit65]

@fizzfaldt @phocean
Author of the commit which fixed the issue can't claim the bounty for personal reasons.
Do you agree if i claim the bounty for MATE desktop team?

Btw. mate-screensaver-1.20.2 with the fix is released.

[phocean]

No problem for me, nice work! Thanks a lot !

[raveit65]

One issue which is still there yet, is that the screen flicker for a second, during this second the content of my desktop is shown.

#169
Does this help?

[Philippe734]

mate-screensaver-1.20.2 with the fix is released

How to track the progress of this release for 18.04 LTS Mate? I ask, because with 18.04 Mate, on desktop with any 1 monitor, I can reproduce the issue easily by unplug the display cable (not the power). I tested with HDMI, DVI and DisplayPort. Very ugly issue. Videos: https://bit.ly/2VA4oaT + https://bit.ly/2CRui2t

[oz123]

mate-screensaver-1.20.2 with the fix is released

How to track the progress of this release for 18.04 LTS Mate? I ask, because with 18.04 Mate, on desktop with any 1 monitor, I can reproduce the issue easily by unplug the display cable (not the power). I tested with HDMI, DVI and DisplayPort. Very ugly issue. Videos: https://bit.ly/2VA4oaT + https://bit.ly/2CRui2t

This ubuntu package version does not include a fix for this. They have 1.20.1 the fix is in 1.20.2, file a bug there so the package the newer version.

[sunweaver]

Hi,

On Sunday, 6 January 2019, Oz N Tiram wrote: > > mate-screensaver-1.20.2 with the fix is released > > How to track the progress of this release for 18.04 LTS Mate? I ask, because with 18.04 Mate, on desktop with any 1 monitor, I can reproduce the issue easily by unplug the display cable (not the power). I tested with HDMI, DVI and DisplayPort. Very ugly issue. Videos: https://bit.ly/2VA4oaT + https://bit.ly/2CRui2t This ubuntu package version does not include a fix for this. They have 1.20.1 the fix is in 1.20.2, file a bug there so the package the newer version.

I will upload mate-screensaver 1.20.2 to Debian the coming week, so the fix will appear in Ubuntu 19.04. Is this whole issue worth a CVE? It sounds like it. If so, please let me know and I will report it to CVE Mitre. CVEs are more likely to be fixed in Ubuntu LTS than normal bugs. Mike

…

-- Sent from my Sailfish device

[oz123]

@sunweaver please do report a CVE.

[lukefromdc]

Master seems to be in a good state now: power cycling a vga connected primary monitor does nothing, unplugging and replugging an inactive HDMI secondary monitor just brings up the passphrase entry screen.,

[sunweaver]

On So 06 Jan 2019 17:59:35 CET, Oz N Tiram wrote: @sunweaver please do report a CVE.

Submitted. Waiting for CVE Mitre feedback. Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

[sunweaver]

This is CVE-2018-20681

[schneider42]

https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-20681.html

"needs-triage". I don't think it will be fixed in Ubuntu 18.04 LTS.

[mikkorantalainen]

Confirming that this is still broken in Ubuntu 18.04 LTS. I found out about this issue when I got a LG monitor that triggers this bug on DPMS standby. I'm currently using http://ppa.launchpad.net/spvkgn/mate-bionic/ubuntu as a workaround (https://launchpad.net/~spvkgn/+archive/ubuntu/mate-bionic).