5 ms·
This exploit is mitigated by the fact that the keyboard/mouse normally only have user permission (not admin)
by totony 12y ago
This exploit is mitigated by the fact that the keyboard/mouse normally only have user permission (not admin)
- nulltype 12y agohttp://xkcd.com/1200/ http://xkcd.com/1200/
- totony 12y agoAhah, that's quite true But I was more thinking about corporate computer systems where such an exploit should only last one session (except for privilege escalation, as OP mentioned).
- samyk 12y agoHi totony, unfortunately with the way our systems are designed today, it's typically trivial to usurp admin later on when the user escalates privileges, even after the USB device has been removed. Examples such as injected LD_PRELOAD, adjusting PATH to MITMA sudo, etc. In my example, we interestingly see how by default, OS X does not require additional permissions in this unique scenario. Crazy!
- lukeholder 12y agoIs the screen resolution independent on the mouse x,y coordinates for the OK click? Looks like in the code you know how far from the top left corner the OK button is for that computer only.
- samyk 12y agoHi lukeholder, the screen resolution is "tied" to how quickly the mouse moves, so no matter which screen resolution you choose, the mouse will always move to the right location.
- totony 12y agoThat's true, but this hack is a (clever) way to shortcut doing user commands (if you have access to the USB port and the logged user's unlocked screen, then it is conceivable that you should be able to do such a thing without such a tool). The exploits that could lead to privilege escalation are a different matter (imo they should be fixed). This hack is very relevent for personal computers, where the user account (in windows i.e.) is an admin and plugging in a USB device does not seem as dangerous as you demonstrated it is.