Version: unspecified (using KDE 4.5.5) OS: Linux When pressing Ctrl+Alt+L , the screen is locked. But if I press the middle button of the mouse , the content in the clipboard will be paste into the password input. I think it is a security bug , because if a user copies his passsword before locking his screen , others can access his session easily. Reproducible: Always Steps to Reproduce: Input the password to a kate. Select the password. Lock the screen. Press the middle button of the mouse. Actual Results: The password is pasted to the dialog. Expected Results: Nothing should be pasted to the dialog ,or '*' should be pasted to the dialog.
I just investigated the options to resolve this issue. First of all it's not possible to copy from the lock screen. So that's already quite good. Disabling the clipboard is not easy. I did not find any way in Qt to disable the general clipboard handling, so we cannot just tell the lock screen to not interact with the clipboard. There is a way to clear the clipboard. While that would be possible, it conflicts with e.g. klipper and other clipboard managers which have options to "prevent an empty clipboard". So clearing is a futile effort. Also clearing the clipboard is wrong as that would also require to restore the clipboard content after locking. The only possibility I see is extending klipper to make it lock screen aware. But that's a complex task and would heavily conflict with internal options like preventing an empty clipboard. So that's not really an option either. Also one has to consider whether it's worth the effort: it's only a problem if and only if the user copied his/her password to the clipboard prior to locking the screen. Is that really a valid use case? Why should a user write his/her own password prior to locking? And why copy? It just doesn't look like a valid case to me. Sorry.
This is not just dangerous when the password was copied. Any information that is leaked by the lock screen is potentially dangerous. Note that middle-mouse also works, which means that anything that was selected before locking is obtainable from the lock screen. This can include any private information, such as emails, credit card information, etc. @Martin Flöser: The objections you have to clearing the clipboard prior to locking are of course valid. However, this is just one of the ways to solve this issue. Another way would be to capture middle-mouse (and other paste-events) in the one leaky password input box and explicitly ignore them. Here is an example on how to do this: https://forum.qt.io/topic/30162/how-disable-copy-and-paste-on-qlineedit/2. Alternatively, since QLineEdit already has the ability to allow/disallow undo/redo, the Qt developers would be open to add a similar flag to allow/disallow copy/paste. Note that this is still an issue in 2018 and kscreenlocker 5.10.5.1-0ubuntu2.
Please do not reopen bugs. Thank you.
@sybren. Bug is open elsewhere. I will fix it in due course.
@David, do you have a bug number to follow the progress of the fix?
The biggest problem I had with this pasting behavior is that last time I checked, there were no limits on the password field. Thus, if you have a few hundred megabytes on your clipboard and you paste it in a few times, your system is going to run out of memory. Then what? Will it ever recover from scratching around on the hard drive to free something up? Maybe. Will OOM kill the right process? Not necessarily. You might lose data. You might lock up the system. (Obviously the same problem exists without the paste behavior, but it would take something like laying something on the keyboard and walking away for a very long time, whereas this can be done in seconds.) If I were building something like this, I'd do these things: 1) Sane limit to the password field, e.g. 64 KiB, preallocated (preferably with tone and visual indicator if full/overflow). 2) No pasting. 3) Keyboard repeat disabled. 4) Clear the field and restart any enabled screensaver after reasonable timeout.
Don't think disabling keyboard repeat will help a lot here. If one can hold key down, he/she can also simply plug an USB dongle which generates keyboard events.
If someone has physical access to the machine, that's a whole 'nother level of security issue. One should not assume that at all. But my main reason for including no keyboard repeat was also that no sane person actually means to use it while entering a password.
Ok, indeed screen locker can be used on a remote session or so. Was my wrong assumption that begin able to type in a screen locker means you've got physical access. You're right about physical access is a whole different world of security issues. There is only so much screen locking can do here. But not leaking data would be already big step. For another types of attacks one should not simply rely on a simple screen locking software. Note on the repeat events: you do want repeats on backslash/delete, and maybe arrows. There are legit cases (i.e. you noticed capslock is enabled) and want to erase handful of characters you've just typed.
Yeah, repeat would make sense for delete & backspace - I hadn't thought about that. I'd be more likely to Ctrl+A and start over, but not everyone knows their shortcuts.