New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disconnecting a video output can cause XScreenSaver to crash (QSB-068, CVE-2021-34557) #6595
Comments
|
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. |
|
The bug can be reproduced even when the screen is locked |
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.
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/ |
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) |
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/
Guessing you meant 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. |
I also plan to propose an X protocol extension for “exit if this connection dies”. |
Not that I'm aware of. Please go ahead.
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. |
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? |
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. |
|
On Fri, Jun 25, 2021 at 05:10:15AM -0700, Demi Marie Obenour wrote:
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.
I know this was mooted in the past, but is it actually in the plan?
If so, where is that documented?
|
The plans are mostly in my head and in internal discussions; I have not documented them yet. |
|
I agree. Another option would be to rely on a new X protocol extension (version 6.1 of XFixes) that causes screenlocker crashes to terminate the X server. I have implemented it and I believe there is a decent chance it will be accepted upstream. |
|
Closing as this particular bug is fixed. |

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:
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)
The text was updated successfully, but these errors were encountered: