Lock can be circumvented by switching to console

[Jonas Zoner]

Steps to reproduce:
1)lock your screen using "dm-tool switch-to-greeter" or "dm-tool lock"
2)switch to console via ctrl+alt+F1
3)switch back to X via ctrl+alt+F7
Result: session is unlocked without entering a password

Expected behaviour:
session should still be locked when switching back to X

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: lightdm 1.7.7-0ubuntu2
ProcVersionSignature: Ubuntu 3.10.0-5.15-generic 3.10.2
Uname: Linux 3.10.0-5-generic i686
ApportVersion: 2.11-0ubuntu1
Architecture: i386
Date: Fri Jul 26 17:30:23 2013
InstallationDate: Installed on 2013-07-26 (0 days ago)
InstallationMedia: Lubuntu 13.10 "Saucy Salamander" - Alpha i386 (20130723.1)
MarkForUpload: True
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

[Sebastien Bacher (seb128)]

Thank you for your bug report, I can't confirm that. How do you lock the screen?

[Jonas Zoner (jonaszoner)]

Your response time is astonishingly quick, thanks for that!
I've been calling lxlock (lxsession package) which is essentially just a script file calling
dm-tool switch-to-greeter
I just verified that calling this directly from a terminal and then following my steps to reproduce leads to the exact same result (session unlocked without entering a password)

[Jonas Zoner (jonaszoner)]

Can't anybody reproduce this?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Marc Deslauriers (mdeslaur)]

You need to lock the screensaver before using the dm-lock tool to switch to the greeter.

For example:

gnome-screensaver-command -l
dm-tool switch-to-greeter

[Pierre Gobin (pierre-gobin)]

I reproduce this whitout needing to switch tty (Lubuntu 13.10) :
- lock the screen with "Shutdown > Lock Screen" ;
- on lightdm screen, just do ctrl+alt+F7 : you arrive on the desktop, without typing any password.

[ibere fernandes (ibere-fernandes)]

hi,

i've just done a fresh install of Lubuntu saucy 13.10 and I can confirm that lightdm is not keeping the system locked.

Comment #8 is correct.

- lock the screen with "Shutdown > Lock Screen" ;
- on lightdm screen, just do ctrl+alt+F7 : you arrive on the desktop, without typing any password.

I believe it's a security issue once anyone is able to log into your machine without typing any password.

let me know if you need more info.

the guy from webupd8 also got the bug at his article:
http://www.webupd8.org/2013/10/see-whats-new-in-1310-release-of.html

from the article:
" XScreensaver has been removed (LightDM is now used for screen locking but there's a pretty serious bug here unless I'm missing something: if you switch to TTY7 after locking the screen - using Ctrl + Alt + 7 -, you can access the desktop without having to unlock the screen so without having to enter any password!); "

best regards,
ibere

[ibere fernandes (ibere-fernandes)]

find attached the lightdm log.

[Jarno Suni (jarnos)]

Ibere Fernandes, as for #9 can you also bypass the password prompt in logging in, and not just bypass the prompt when unlocking a running session?

[Lars Noodén (larsnooden)]

Jarno, when not logged into a session pressing ctrl-alt-f7 goes to a blank, black screen with a cursor in the upper left corner. Pressing ctrl-alt-f8 brings back the login screen. It looks like you have to be logged in for this bug.

[Jarno Suni (jarnos)]

So far 5 people have told the bug affects them. As for the article mentioned in #9, it is incorrect: you can not bypass password prompt by Ctrl + Alt +7, but by Ctrl + Alt + F7.

[Marc Deslauriers (mdeslaur)]

Just to be clear, this isn't a lightdm issue.

Something needs to lock the user's session before switching to the greeter.

This can either be gnome-screensaver or xscreensaver, and the lxlock script has to tell them to lock before switching to the greeter.

[Jarno Suni (jarnos)]

If lightdm is installed, then lxlock will use dm-tool for screen locking. dm-tool is part of lightdm. It seems to be the same if you use "dm-tool switch-to-greeter" or "dm-tool lock". Aren't these supposed to lock user's session? I do not see the point why you would have to use another lock utility before dm-tool as the latter provides its own password prompt for unlocking screen and you would have to give password another time to ulock the first lock (unless you use Ctrl+Alt+F7 to bypass the greeter). If lxlock would use say slock (from suckless-tools package) for locking, instead of dm-tool, the Ctrl+Alt+F7 trick would not work. So isn't the bug in dm-tool's inability to lock screen properly and thus the correct package for this bug is lightdm?

[Marc Deslauriers (mdeslaur)]

Something has to draw a window over the user's session. Lightdm does _not_ do this.

If you use dm-tool to tell lightdm to lock the screen, it calls logind over dbus, and whatever you use in the user's session to hide the screen needs to receive the dbus signal from logind to lock the screen. In Unity, it is gnome-screensaver, in GNOME, it is gnome-shell.

I don't believe XScreensaver listens to logind signals over dbus, hence, if you want to use XScreensaver in lubuntu, you need to call it to lock the screen before you use dm-tool.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

On top of that, "dm-tool switch-to-greeter" does exactly what it is suppose to do, it switches to the greeter and does _not_ ask the session manager to activate the screen lock for the activate user session.

[Jarno Suni (jarnos)]

Would it be accepted, that lxlock were changed not to use dm-tool at all, but other means such as slock which does not run on any daemon and would not listen to dbus signal anyway?

Another option, if dm-tool is used, would be to use the command "dm-tool switch-to-greeter" preceded by some command to lock session. In greeter, if you login the user that has a session running already, password will be prompted again by the screen saver or the session locker utility.

[Jarno Suni (jarnos)]

I tried installing this light-locker and logging out and in:
http://www.webupd8.org/2013/08/lightdm-session-locker-light-locker.html
Thereafter Ctrl-Alt-F7 will not bypass the greeter anymore, no mater whether you use "light-locker-command -l" or "dm-tool lock" or "dm-tool switch-to-greeter" to bring on the greeter (or whatever it is) which is strange, since "dm-tool switch-to-greeter" does not activate lock according to #17.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

My fault. Apparently it also locks the active user session (and allows user switching).

[ibere fernandes (ibere-fernandes)]

Jarno Suni,

in reply to #11 and #13:

a) you need to be logged in, then follow the steps:
- lock the screen with "Shutdown > Lock Screen" ;
- on lightdm screen, just do ctrl+alt+F7 : you arrive on the desktop, without typing any password.

b) althought the webupd8 article mentioned Ctrl + Alt + 7, i'm sure he wanted to mean Ctrl + Alt + f7 once that's the correct shortcut to go back from any tty console.

After all, is there a way to fix this kind of security issue?

I'm not a dev. I'm just a QA tester and so far I can only assure that anyone can have access to a locked machine running Lubuntu 13.10 just hitting the shortcut Ctrl + Alt + f7 without any need to input username or password.

As said before, the machine was locked and before that there was a username logged in.

Thank you for your kind help,
Iberê

[Jarno Suni (jarnos)]

Well, #19 describes a workaround, but it requires using a package from a PPA repository https://launchpad.net/~light-locker/+archive/release .

Another workaround that uses a package from Universe repository of Ubuntu and works around Bug #1229486, too, is here: Install suckless-tools, edit /usr/bin/lxlock to run slock insead of any other locking utility (or add a script named lxlock at /usr/local/bin/ to run slock). Note that slock does not even display password prompt, but a blank screen you have to type password in, and there is no way to swit. xlock would be better, but xlockmore package containing it is no more available in Ubuntu repositories. Neither of those work with xfce4-power-manager that uses xscreensaver, which have to be run as a daemon; if you are going to suspend/hibernate+lock by xfce4-power-manager, you have to autostart xfce4-power-manager (edit in lxsession-edit) and xscreensaver (how?) and then you may want to use "xscreensaver-command -lock" in lxlock, instead of slock. xscreensaver allows new login.

[Jarno Suni (jarnos)]

I was trying to tell in the previous comment: Note that slock does not even display password prompt, but a blank screen you have to type password in, and there is no way to make a new login by slock. However, if you run "slock &" and then "dm-tool switch-to-greeter" in lxlock, you have that ability.

[Jarno Suni (jarnos)]

As for #19, the workaround stopped working in my last session for some reason, i.e. Ctrl+Alt+F7 bybassed password prompt again. Logging out and in again made it work again. I would not call light-locker reliable, yet.

[Markus J Schmidt (smiddy84)]

I can confirm this bug on lubuntu 13.10 amd64.

[baltasarq (baltasarq)]

I can confirm this bug on lubuntu 13.10 amd64.

The workaround I chose (following #22) was to:

1) Install suckless-tools: sudo apt-get install suckless-tools
2) edit /usr/bin/lxlock (sudo nano /usr/bin/lxlock). It tries to trigger screen locking using various tools, one of them is in fact slock, the tool provided by suckless-tools. The whole contents can be erased and just write "slock" instead. What I did was to add the "el" prefix to the first "if", and move the "elif" testing and triggering slock to the top (removing the "el" prefix).

[Jarno Suni (jarnos)]

If you don't want to change the original lxlock script, you can copy the script to /usr/local/bin/ and change it there. The modified script will be used, since the "local" directory is mentioned earlier in the environment variable called PATH. Upgrading the operating system will not change the script in the "local" directory, as far as I know.

[Alberto Salvia Novella (es20490446e)]

This bug needs to be forwarded upstream (https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding_upstream).

[Julien Lavergne (gilir)]

The lightdm locking facility is an unfinished work, and lack a proper way to lock the session, it started at the begin of the cycle, and was a bit forgotten later in the development. It's unfortunate that it went into the release in this state.

That's said, the less invasive way I can see to "fix" it is to completely remove the lightdm option in lxlock. However, it will break the "Lock" button of lxsession-logout, which need another lock system by default to work properly by default. But, no-one is currently ready enough out-of-the-box to work as a replacement (xscreensaver need to be start at startup, slock provide a not-user-friedly interface, light-locker is out of universe, and gnome-screensaver is out of the question). So, the only way is to just remove the "Lock" button to avoid confusion. It will be still possible to lock the session if people use lxlock and set-up the proper configuration.

I'm preparing a patched version of lxsession with those changes, so people will be able to test it.

[Jarno Suni (jarnos)]

Actually, xscreensaver does not need to start at startup; the daemon can be started within lxlock, if needed. But xscreensaver needs to be installed, of course. I wrote a replacement script for lxlock that tries to lock by xscreensaver; see the attachement for more details.

Still, there is a problem with how lxlock is used by e.g. the suspend function of the Logout Lubuntu dialog: It runs lxlock in background and does not check, if it ran successfully before entering the suspend mode, see Bug #1054299

[amjjawad  (amjjawad)]

This bug affects me too!

[amjjawad  (amjjawad)]

In my case:

Lubuntu 13.10 amd64

Menu > Logout > Lock Screen

ctrl+alt+F1

ctrl+alt+F7

Result: session is unlocked without entering a password

[ibere fernandes (ibere-fernandes)]

is sudo apt-get install xscreensaver a good workaround while ligthdm implementation is not finished?

i've installed xscreensaver on my Lubuntu 13.10 test machine (fresh install) and lock was not being circumvented anymore.

[amjjawad  (amjjawad)]

@ibere

Most likely I will try this on my test machine and report back ;)

[Jarno Suni (jarnos)]

A workaround is to do this on terminal:

sudo apt-get install xscreensaver
sudo wget --directory-prefix=/usr/local/bin/ https://launchpadlibrarian.net/154739229/lxlock
sudo chmod a+x /usr/local/bin/lxlock

You may also want to start xscreensaver as an automatically started application, but that is not necessary, when using the above.

[Jarno Suni (jarnos)]

Please note that "lxlock" between the sudos is a part of the preceding command's URL option on #35, even if it is wrapped on separate line there.

[C de-Avillez (hggdh2)]

@Julien: Hi, when should we expect a fix/bypass? This is a pretty bad bug... Thank you.

[amjjawad  (amjjawad)]

Installing 'xscreensaver' did NOT solve the issue for me.

I will now try this workaround - https://bugs.launchpad.net/ubuntu/+source/lxsession/+bug/1205384/comments/35 - and will report back :)

[amjjawad  (amjjawad)]

Confirmed - Installing 'xscreensaver' alone will NOT fix the issue.

Confirmed - the workaround on this post: https://bugs.launchpad.net/ubuntu/+source/lxsession/+bug/1205384/comments/35
Has solved the issue for me.

Indeed, NO need for xscreensaver service to start automatically so I can confirm that it is OKAY to install the package (xscreensaver) by default to solve this AS LONG AS the service is not going to work by default and that is of course, if the Developers will not find the right solution for this issue without installing 'xscreensaver' :)

Thanks!

[sudodus (nio-wiklund)]

I can confirm that the bug is there 2013-10-07 in an updated/upgraded Lubuntu 13.10 i386 system installed into a USB 3 drive in the following computer.

 http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/

I can confirm that installing 'xscreensaver' alone will NOT fix the issue.

The workaround in #35 alone does *not* fix the issue for me, not even after reboot. (I copied and pasted the commands from Firefox to lxterminal, so I think they were correctly done.)

[sudodus (nio-wiklund)]

I should also mention that I have installed a complete Swedish language pack, and set the system to use it globally. (I don't know if that would make any difference, but I don't know of any other particular feature; Standard Lubuntu updated/upgraded today.)

[sudodus (nio-wiklund)]

I have re-done it in the same computer with the same result, and I have redone it in another computer (still using the same i386).

IBM Thinkpad T42:

http://www.cnet.com/laptops/lenovo-thinkpad-t42-2373/4507-3121_7-31155666.html

-o-

But it works if I lock with

xscreensaver-command -lock

or activate xscreensaver and let it auto-lock using

xscreensaver-demo

[sudodus (nio-wiklund)]

More details:

1. Typing error in comment #40: 2013-10-07 should be 2013-11-07

2. My systems of Lubuntu13.10 i386 are made via OEM (final installations but via OEM). Maybe that makes a difference concerning the locking ability.

[Jarno Suni (jarnos)]

sudodus, you told in #40 that workaround #35 did not work for you. Did you get any error messages when running the commands in terminal?

[Jarno Suni (jarnos)]

If you already have some lxlock file in /usr/local/bin directory before doing the workaround mentioned in comment #35, it may fail. You may want to delete the old lxlock in /usr/local/bin/ before trying the workaround.

[sudodus (nio-wiklund)]

No I saw no error messages. I'll try to delete lxlock and try again.

[Jarno Suni (jarnos)]

I instructed to download the script to /usr/local/bin/ since you don't have to overwrite the original lxlock script in /usr/bin/ in that case, but it will be used instead of the original, if the /usr/local/bin is before /usr/bin in PATH environment variable (and not full path is used in the command to launch lxlock). You can type "echo $PATH" in terminal to see, if that is the case in your OEM installation. If you don't have /usr/local/bin/lxlock, but overwrite lxlock in /usr/bin, a possible update of lxsession may overwrite the workaround script.

For some reason there is lxlock in /usr/bin/X11/, too, but it seems to be identical to the version in /usr/bin/.

[sudodus (nio-wiklund)]

echo $PATH
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

so /usr/local/bin is before /usr/bin in my user's path.

But what about root's path? Maybe /usr/bin/lxlock will be used that way?
-----
 /usr/bin/lxlock:
...
# Try to lock the screen with thos applications (in this order) :
# lighdtm, xscreensaver, gnome-screensaver, slock, slock, i3lock and xdg-screensaver

if test x"`which dm-tool 2>/dev/null`" != x""; then
    dm-tool switch-to-greeter
elif `dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.freedesktop.DisplayManager > /dev/null 2>&1` ; then
    seat="$XDG_SEAT_PATH"
    dbus-send --system --print-reply --dest=org.freedesktop.DisplayManager "$seat" org.freedesktop.DisplayManager.Seat.SwitchToGreeter \
              2> /dev/null
elif test x"`which xscreensaver-command 2>/dev/null`" != x""; then
    xscreensaver-command -lock
elif test x"`which gnome-screensaver-command 2>/dev/null`" != x""; then
    gnome-screensaver-command --lock
elif test x"`which slock 2>/dev/null`" != x""; then
    slock
elif test x"`which xlock 2>/dev/null`" != x""; then
    xlock $*
elif test x"`which i3lock 2>/dev/null`" != x""; then
    i3lock -d
# In the end, try to fallback to xdg-screensaver. Don't do at the first try,
# because if lxlock is called by xdg-screensaver, we may enter a loop.
else
    xdg-screensaver lock
fi
exit 0

[sudodus (nio-wiklund)]

After wiping and downloading /usr/local/bin/lxlock again, I can still log in without any password via 'ctrl + alt + F1-F6'.

[sudodus (nio-wiklund)]

sudo echo $PATH
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

so /usr/local/bin is before /usr/bin also in root's path. But if /usr/bin/X11/lxlock has priority ...

[Jarno Suni (jarnos)]

sudodus, lxlock and xscreensaver only protects the desktop (case Ctrl + Alt + F7), not the virtual consoles.

[L K (koziollz-v)]

This might be related:

After completing a full Lubuntu 13.10 install on my laptop when I attempt to lock the screen via shortcuy (Ctrl+Alt+L) I receive the following error:

"Failed to execute child process "xscreensaver-command" (No such file or directory)"

[amjjawad  (amjjawad)]

From reading the comments and following up with this issue and the whole process of removing 'xscreensaver' and replace it with whatever suppose to work to lock the screen but it is not actually working, it appears that there is/are some package or files or whatever you call it is 'still' somehow (yes, odd enough) using 'xscreesaver' and this SHOULD be fixed :)

Long story short, 'xscreensaver' does not exist and it is not shipped by default with Lubuntu 13.10 so I fail to see the point why when someone who wants to lock his/her screen that he/she should see a message like - see comment #52 - "Failed to execute child process "xscreensaver-command" (No such file or directory)" ??!!

@L K (koziollz-v)

I believe this new and fresh installation of yours has no xscreensaver installed, correct? or have you installed it?
because if you have installed it then YES, the process is not working by default and you need to manually add xscreensaver to the autostarter app.

I also fail to understand why there isn't any progress in this really nasty and critical bug!!!

Thank you :)

[Julien Lavergne (gilir)]

A fixed package will be available in https://launchpad.net/~lubuntu-dev/+archive/staging

The fix is based on the script Jarno Suni submitted. It re-install xscreensaver by default, but only start it when you launch lxlock. It also removes the lightdm method for locking the screen. Please test it and report back if it's working for you.

[ibere fernandes (ibere-fernandes)]

Fresh install of saucy. System updated.

Bug is still there as expected.

Terminal:

sudo add-apt-repository ppa:lubuntu-dev/staging

Confirmed PPA addition.

sudo apt-get update
sudo apt-get dist-upgrade

The following NEW packages will be installed:
  libjpeg-progs libjpeg-turbo-progs miscfiles xscreensaver xscreensaver-data
The following packages will be upgraded:
  lxappearance lxsession lxsession-data lxsession-default-apps
  lxsession-logout

Confirm: Yes.

Success! Now if you lock the screen > screen locked > press ctrl+alt+f7 > lock will not be circumvented anymore.

From locked screen, you may even goto a tty such as 1-6 (make the login or not, your choice), press ctrl+alt+f7 > lock will not be circumvented anymore either.

I have even rebooted to check if the fix/patch remains. Things are working as expected in this case too: lock will not be circumvented anymore either.

Bug is fixed by patch.

Thank you.

[ibere fernandes (ibere-fernandes)]

@L K (koziollz-v) from comment #52:

the patch will also fix your issue.

[sudodus (nio-wiklund)]

It works for me in a system that is not installed via OEM. Thanks at lot for solving the issue :-)

I did as described by ibere fernandes in post #55.

I have no time right now to test it in an OEM install, but will do it later (I hope within 2-3 days).

[Federico Leoni (effelle-gmail)]

Yes, the patch from Lubuntu-dev/staging PPA (post #55) is working fine in OEM install ( and on OBI too). Thanks Iberê.

[Jarno Suni (jarnos)]

As for the lxlock from https://launchpad.net/~lubuntu-dev/+archive/staging, "xscreensaver-command -lock" at line 27 is redundant.

The script will fail, if gnome-screensaver is running and xscreensaver is not running, when you run lxlock. Running

 which gnome-screensaver-command >/dev/null && gnome-screensaver-command --exit >/dev/null 2>&1

before starting xscreensaver daemon in the script fixes that.

When lxlock starts xscreensaver daemon, the xscreensaver daemon will be running the rest of the session, if it is not terminated explicitly. I think that is not a problem, but maybe it would be better to start xscreensaver daemon at startup anyway to give contiguous user experience.

If gnome-screensaver is installed, it will be used by xfce4-power-manager, even if xscreensaver is running. Would it be good to prefer gnome-screensaver in lxlock, too?

I wonder what is the reason to keep xlock in the script, as the xlockmore package has not been available in Ubuntu packages after Ubuntu Quantal (12.10). Actually, none of the alternatives of xscreensaver will be used by lxlock in the current fix, as xscreensaver is installed as a dependency of lxsession-logout and thus used by the script.

Furthermore, I see no point of using code like

 if test x"`which xscreensaver-command 2>/dev/null`" != x""; then ...

when you could use

 if which xscreensaver-command >/dev/null; then ...

As for the lxlock script I uploaded earlier (https://launchpadlibrarian.net/154739229/lxlock), error handling in it fails since the exit statements exit only the innermost block, besides the script's exit code may be wrong. I attached the corrected script.

[Elbennit Turner (luvlinuxos)]

I installed the patch accordint to #55 instruction on my personal machine and it did not fix the bug! I do not have gnome-screensaver installed but This is my production machine thus it is equiped with quite a bit of additional packages installed.

[Jarno Suni (jarnos)]

Elbennit, please type
xscreensaver -nosplash &
in terminal. Is there some output? If not, try
xscreensaver-command -nosplash
in terminal. Does it lock successfully or does it output some error?

[Jarno Suni (jarnos)]

Elbenit, sorry, the second command is
xscreensaver-command -lock

[Elbennit Turner (luvlinuxos)]

Jarno, I new that I could lock my computer with xscreensaver it works perfect but not with dm-tool lock.

[Phill Whiteside (phillw)]

Hmm, added the patch and now 'Lock Screen' no longer has any affect! I'll have to bite the bullet and do a clean re-install, this system has had a lot done to it since the alpha1 of 13.10 came out!

[Jarno Suni (jarnos)]

Elbennit, the patch does not use dm-tool, but xscreensaver to lock screen. I am afraid there is no fix available for lightdm.

[Elbennit Turner (luvlinuxos)]

Jarno,

Thanks for your input and response!!! xscreensaver <ctrl>+<alt>+L locks my system perfectly! I will say that adding the new staging ppa did solve some reboot / shutdown issues on my machine!!!

Be Blessed!!!

~LuvLinuxOS~

[Julien Lavergne (gilir)]

@jarnos
The change was minimal on purpose. The goal is to include it as a SRU update, so it needs to be as minimal as possible.
However, if you want to propose a patch to improve lxlock more, you can do it upstream so it can be include for the next release.

[Jarno Suni (jarnos)]

Julien Lavergne, #29, why is gnome-screensaver out of the question? It does not delay locking; xscreensaver does and reveals the desktop for a while when resuming from suspend: Bug #1229486

Marc Deslauriers, #7, I tested that, and indeed the combination seems to work, but only with gnome-screensaver you are not asked password twice.

[sudodus (nio-wiklund)]

Now I have tested that It works for me also in a system that is installed via OEM. Thanks at lot for solving the issue :-)

I did as described by ibere fernandes in post #55.

[ibere fernandes (ibere-fernandes)]

one more use case/scenario:

I've just tested hibernate and also suspend (fresh installation) with the patch described above.

Things are working as expected.

Thank you Julien.

[Jarno Suni (jarnos)]

@ibere-fernandes
It does not work, if gnome-screensaver is running.

@gilir
What is a SRU update? The proposed fix in the PPA does not give user any other option than to use xscreensaver, but still keeps the options hanging there in lxlock script. If the options are wanted to be preserved, xscreensaver or whichever screen saver/locker is installed as a dependency of the desktop environment, should be used as fallback. Using "xdg-screensaver lock" as the fallback is insane, if there is a possibility, that it calls lxlock, like a comment in the script suggests, since there may be endless loop then.
Therefore, something like the attachment should be used. (I dropped xlock as an option, because it is not available for Ubuntu anymore.)

[Julien Lavergne (gilir)]

@jarnos
SRU are update of a stable release : https://wiki.ubuntu.com/StableReleaseUpdates
Your modified lxlock looks correct, I'll update the package to have a bit more testing (PPA users should receive an update soon). Thanks for the help on this.

[Jarno Suni (jarnos)]

@gilir
Great, just the introducing comment should be updated accordingly:

# Try to lock the screen with the following applications (in this order) :
# running xscreensaver, running gnome-screensaver, slock,
# i3lock, and finally, if none of them is available, use xscreensaver.

[Jarno Suni (jarnos)]

There are no complaints of the fix, so I wonder why the fix is not released, yet.

[Jarno Suni (jarnos)]

Is the problem, that xscreensaver (or any other locker application) is not wanted as a dependency? Altrenatively lxlock could exit with an error, if it can't find an available locking method. Please see bug https://bugs.launchpad.net/ubuntu/+source/lxsession/+bug/1253046

[Jarno Suni (jarnos)]

The behavior described in the previous comment is in use in current xflock4 script for Xfce desktop environment. By the way, I proposed a new xflock4 script that adds light-locker (available in Trusty) as an option for locking: http://bug-attachment.xfce.org/attachment.cgi?id=5288
It uses "command -v" instead of "which" althought both likely work as well. It also defines its own supposedly stricter PATH and expects locking commands to be there. (The said bug report is https://bugzilla.xfce.org/show_bug.cgi?id=3770)

[Jarno Suni (jarnos)]

I suggest that the current lxlock script should be replaced by this: http://bug-attachment.xfce.org/attachment.cgi?id=5295 It does not have any specific dependency, but adds support for various screen savers and locker utilities one of which user may install and run according to his/her preference. Even if lxlock fails, when no such software is available, it is IMO better than to suggest, that lxlock works, when it does not.

[Jarno Suni (jarnos)]

In order to make xfce4-power-manager support lxlock for locking in general case, you could add certain symbolic link to it:

sudo ln -s -T /usr/bin/lxlock /usr/local/bin/xflock4

This would make Xfce also use lxlock as its locker, if Xfce is installed in the same system. Please test.

[Zen Kitteh (thezenkitteh)]

Solution in this comment fixed this bug for me:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1205384/comments/55

[Jean Jordaan (jean-jordaan)]

@thezenkitteh : that link is a 404. Looks like the correct link is now:
https://bugs.launchpad.net/ubuntu/+source/lxsession/+bug/1205384/comments/55

Lock screen now gets me xscreensaver which seems to work (but damn it's ugly).

[Jean Jordaan (jean-jordaan)]

To be clear: this is after after adding ppa:lubuntu-dev/staging and upgrading
or installing libjpeg-progs libjpeg-turbo-progs xscreensaver xscreensaver-data
lxappearance lxsession lxsession-data lxsession-default-apps lxsession-logout
as noted in comment 55.

[Theodore Papamarkou (theodore-papamarkou)]

Has there been any progress with this high priority bug?

[Stéphane Gourichon (stephane-gourichon-lpad)]

This bug does not affect Xubuntu 16.04 rnuning XFCE Desktop.
This is consistent with this bug set to affect LXDE not XFCE.

[Nazar Mokrynskyi (nazar-pc)]

Still present on 16.10. I'm trying to get custom environment with just Compiz and no Unity, but this is quite annoying bug.

[Julien Lavergne (gilir)]

This bug on lxsession (actually lxlock) was fixed sometimes ago, by removing the use of dm-tools, replaced by light-locker.

[Nazar Mokrynskyi (nazar-pc)]

Looks like this is a duplicate of https://bugs.launchpad.net/lightdm/+bug/904006

[MaggieC (imbubble)]

any news ?

[Jarno Suni (jarnos)]

If you have light-locker running, and do the steps in the description, session will remain locked, but it will show desktop for short time. This is in Xubuntu 16.04, which does not have lxsession installed. I do not see how lxsession is affected.

[smurfendrek (smurfendrek123)]

This bug still exists in 18.04 when using lightdm with gnome, please fix this, it is a massive vulnerability with shared computers.

[smurfendrek (smurfendrek123)]

When using lightdm with gnome, the exploit works in exactly the same ways as the original bug, just by switching tty's the lock can be circumvented.

[smurfendrek (smurfendrek123)]

When trying to circumvent the lock on gnome with lightdm, it seems that the exploit only works when using gnome on X. The exploit does not seem to work when using gnome on wayland with lightdm.

[Eduardo Barretto (ebarretto)]

Hi smurfendrek,

Please check jarnos comment #89, you need to use light-locker, using dm-tool for lock is not recommended.
You could also try with other screen lockers program.
Also this is an old bug, if you are still experiencing the problem, please open a new bug.
I am unsubscribing the security team from this ticket.
If needed please subscribe it again.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.