qubes-issues

qubes-issues copied to clipboard

Qubes OS version

4.0.4

Affected component(s) or functionality

Screensaver, locking with Ctrl-Alt-L

Brief summary

Nothing happens when trying to lock the screen. No logs. Screensaver IS set to autostart already. And it works for some time. But after some time, (not sure about the exact cause), inactivity timer does not lock the screen, nor the screen lock shortcut works. When I open the Xfce Screensaver panel, it complains about the screensaver daemon being not running. Even after starting the daemon, same thing happens after some time. As there is no log at all, I cannot trace the cause.

How Reproducible

This started a few days ago, probably after applying a UEFI firmware update. The bug is always present since then, I guess.

To Reproduce

Steps to reproduce the behavior:

1. boot the system
2. log in. do some work.
3. the computer won't lock when you expect it to lock its screen

Expected behavior

The lock should work.

Actual behavior

Lock is disabled

Screenshots

Additional context

It might be considered a security issue as well, I did not notice that the screen was not locked but had the impression that it was.

Solutions you've tried

starting the xscreensaver using the respective xfce settings panel

Relevant documentation you've consulted

Found some basic info that suggests to restart the screensaver, to put it into autostart (which already appears in session and startup panel as a ticked item)

Related, non-duplicate issues

(could not find any)

Try starting xscreensaver manually (kill the autostarted one if you have to), then put the log here when it crashes.

I think I can easily reproduce it now. I don't want to paste it here as it might be a security concern.

The bug can be reproduced even when the screen is locked

It might be considered a security issue as well, I did not notice that the screen was not locked but had the impression that it was.

Perhaps, but it is somewhat suspicious that this has not been more widely reported, given how many other XScreenSaver issues we have and the overwhelming volume of discussion about it over the years. I suggest suspending judgment until we get more information.

I think I can easily reproduce it now. I don't want to paste it here as it might be a security concern.

You can instead report it confidentiality to the Qubes Security Team, if you believe that would be more appropriate: https://www.qubes-os.org/security/ Please make sure to provide a link to this issue so that they know what you're referring to.

The bug can be reproduced even when the screen is locked

To be clear, you're saying that someone with physical access to a screen-locked Qubes installation can bypass the screen locker without the password? If so, I certainly agree that's a critical security bug.

It's worth pointing out that XScreensaver has no relation to the "Xfce Screensaver panel" referred to in the report, which is why the screensaver daemon is reported as not running. Starting from xfce settings while using xscreensaver, will just cause trouble.

A first step would be to determine whether one or other daemon is running, by checking ps aux|grep screensaver

It isn't stated in the report whether the issue is with locking the screen, or running the screensaver - these are different mechanisms. There's a suggestion that "lock is disabled" but also that the screensaver does not start. Can you clarify, op?

@unman Sorry that the original question might be vague. At that time I did not have an idea about the cause.

The screensaver runs.. but then it crashes. I have captured and sent the log to the security team email already.

On Tue, May 11, 2021 at 08:32:19AM -0700, Mustafa Kuscu wrote:

I have captured and sent the log to the security team email already.

I didn't got anything.

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

@marmarek sent again

I have tried the new xscreensaver package (version 6.00) and can confirm that this issue is not present anymore. Therefore closing this.

Lets keep it open until package lands in current-testing repo.

I have experienced the same behavior after upgrading to r4.1 (where xscreensaver version is 5.45)

I have experienced the same behavior after upgrading to r4.1 (where xscreensaver version is 5.45)

same. died after 2 weeks uptime or so

On Tue, Jun 01, 2021 at 12:10:41AM -0700, Foppe wrote:

I have experienced the same behavior after upgrading to r4.1 (where xscreensaver version is 5.45)

same. died after 2 weeks uptime or so

I have 5.45 on 4.0 and it is solid after extended uptime.

Since a reasonable time has passed and a fix exists, I would disclose a little bit more details.

The issue is related to TB3 and probably to UEFI settings. In my case, plugging/unplugging a TB3 dock kills the screensaver. Yes, as simple as that. But probably not all hardware/firmware are affected (who knows).

The xscreensaver update to 6.0.0 apparently fixes the issue.

I will be away from my dock for some time. But i can speculate that i3wm etc would not suffer from this.

@marmarek this needs to be backported to R4.0. It might also call for a QSB, but I am not sure.

Yes, I'm on it. The changes in 6.0 are massive and while many of them are improvements, they are too invasive for a security fix. R4.0 will receive fix for just this specific issue.

QSB has been issued: https://www.qubes-os.org/news/2021/06/04/qsb-068/

Lets keep it open until package lands in current-testing repo.

Guessing you meant security-testing. The package is there now, so I'm closing this as resolved.

Thanks again for the report, @mcku.

Has a CVE been requested for this bug? Since this is a confirmed security bug, it should get one.

Has a CVE been requested for this bug? Since this is a confirmed security bug, it should get one.

I also plan to propose an X protocol extension for “exit if this connection dies”.

Has a CVE been requested for this bug? Since this is a confirmed security bug, it should get one.

Not that I'm aware of. Please go ahead.

I also plan to propose an X protocol extension for “exit if this connection dies”.

Shouldn't that be filed as a separate enhancement issue? This security bug has already been fixed.

I also plan to propose an X protocol extension for “exit if this connection dies”.

Shouldn't that be filed as a separate enhancement issue? This security bug has already been fixed.

Yes, it should. We can carry it as an out-of-tree patch if necessary.

Has a CVE been requested for this bug? Since this is a confirmed security bug, it should get one.

Not that I'm aware of. Please go ahead.

CVE-2021-34557. Please add it somewhere it can easily be associated with its patch (commit message, issue name, GH SA), other than in the changelog.

Has a CVE been requested for this bug? Since this is a confirmed security bug, it should get one.

Not that I'm aware of. Please go ahead.

CVE-2021-34557. Please add it somewhere it can easily be associated with its patch (commit message, issue name, GH SA), other than in the changelog.

Thanks! Just added it to this issue's title. Does that work?

Come to think of it, might as well also update the issue title to match the QSB title and reference the QSB number too.

Hi, there is a variant to this issue, which results in the same behavior with the patched xscreensaver 5.45.

Will send details to the security team.

Since this seems to be a new embargoed bug, it should be discussed at the linux-distros ML, at least until it will get public. Can you open a new thread there sharing all the details?

Since this seems to be a new embargoed bug, this should be discussed at the linux-distros ML, at least until it will get public. Can you open a new thread there sharing all the details?

distros@ would actually be better, as this bug is (presumably) not Linux-specific.

Until there is a solution, I decided to switch to a different screen lock.

The one I used before was i3lock. In order to switch, I have uninstalled xscreensaver completely. Then using xfconf I have assigned i3lock to be the default screen lock.

The ultimate fix for these problems is to switch to Wayland. In the meantime, there are plans to terminate the X server if the screen locker dies.