4 ms·

> if there’s any way to crash xscreensaver, that is a potential security issue... This has happened before: https://github.com/linuxmint/cinnamon-screensaver/i

> if there’s any way to crash xscreensaver, that is a potential security issue... This has happened before: https://github.com/linuxmint/cinnamon-screensaver/issues/354 https://github.com/linuxmint/cinnamon-screensaver/issues/354

jraph 5y ago
This is not xscreensaver though. This is important because jwz, xscreensaver's author, has written about this at length [1,2]. He was very careful to make the core of xscreensaver as small as possible to avoid crashes. [1] https://www.jwz.org/xscreensaver/toolkits.html https://www.jwz.org/xscreensaver/toolkits.html [2] https://www.jwz.org/blog/2015/04/i-told-you-so-again/ https://www.jwz.org/blog/2015/04/i-told-you-so-again/ (open these links in a new tab or by copy-pasting the URL)
- justinjlynn 5y ago
  True, and certainly a fair distinction. Perhaps I should say that a vulnerability of this nature - involving an xscreensaver fork - has occurred in practice.
  - jraph 5y ago
    Yes, your point still stands, this class of bugs is "fatally" present on X11, there is seemingly nothing that can be done about it.
    - makomk 5y ago
      It can actually be avoided on X11 if you're willing to make the screensaver an integral part of the desktop environment. The way KDE has done it since the KDE 4 era at least is by doing the actual screen locking in ksmserver and having the unlock screen and password entry dialog as a seperate process. This has two effects: crashing the password entry dialog or the screensaver will not unlock the desktop, and if you do somehow manage to crash ksmserver the session will immediately terminate, because ksmserver exiting for any reason is how X decides that the session is over. This is a bit like Wayland's solution, except with much less potentially buggy and crashy code in the process responsible for locking the desktop.
- dEnigma 5y ago
  I had forgotten about that redirection (and didn't read your note), so I thought you were making a crude joke with that link at first.
  - jraph 5y ago
    The Referer header can't die soon enough. Or HN could implement rel=noreferrer (at least on links to this website) or the relevant CSPs. Or jwz stop doing this redirection but I don't see this happening.

jraph 5y ago

This is not xscreensaver though. This is important because jwz, xscreensaver's author, has written about this at length [1,2]. He was very careful to make the core of xscreensaver as small as possible to avoid crashes. [1] https://www.jwz.org/xscreensaver/toolkits.html https://www.jwz.org/xscreensaver/toolkits.html [2] https://www.jwz.org/blog/2015/04/i-told-you-so-again/ https://www.jwz.org/blog/2015/04/i-told-you-so-again/ (open these links in a new tab or by copy-pasting the URL)

justinjlynn 5y ago
True, and certainly a fair distinction. Perhaps I should say that a vulnerability of this nature - involving an xscreensaver fork - has occurred in practice.
- jraph 5y ago
  Yes, your point still stands, this class of bugs is "fatally" present on X11, there is seemingly nothing that can be done about it.
  - makomk 5y ago
    It can actually be avoided on X11 if you're willing to make the screensaver an integral part of the desktop environment. The way KDE has done it since the KDE 4 era at least is by doing the actual screen locking in ksmserver and having the unlock screen and password entry dialog as a seperate process. This has two effects: crashing the password entry dialog or the screensaver will not unlock the desktop, and if you do somehow manage to crash ksmserver the session will immediately terminate, because ksmserver exiting for any reason is how X decides that the session is over. This is a bit like Wayland's solution, except with much less potentially buggy and crashy code in the process responsible for locking the desktop.
dEnigma 5y ago
I had forgotten about that redirection (and didn't read your note), so I thought you were making a crude joke with that link at first.
- jraph 5y ago
  The Referer header can't die soon enough. Or HN could implement rel=noreferrer (at least on links to this website) or the relevant CSPs. Or jwz stop doing this redirection but I don't see this happening.