Over the last few months, we (Patrick and I) have done a substantial amount of research into, and discussion with others about, the security risks of executable MIME handlers. This is a log of the discussions, posts, and CVEs related to this, several of which were discovered by us.
Further conversations about this should be edited into this post or posted underneath as new posts. (I think we traditionally do new posts, but I’d kind of like to use edits for this to keep all of the links in one place.)
I was trying to find a RAM-efficient way of triggering PCManFM-Qt over D-Bus, ran into some weird behavior when launching it, mentioned it on the Whonix forums, then Qubes OS’s lead dev asked a question that led down a rabbit hole.
Many of the issues have been patched already, and the biggest one that isn’t patched (PCManFM-Qt) has been mitigated through a D-Bus shim in Kicksecure:
The next largest unpatched one is Wine. For that, the best mitigation is, don’t install Wine from WineHQ. (Maybe we should add a systemcheck test to see if WineHQ’s repos are enabled and warn if so…)
It does both. It checks to ensure that all of the file system objects being opened are directories, not files, so that opening them with PCManFM-Qt doesn’t result in files being opened/launched. This approach is inherently vulnerable to a time-of-check to time-of-use (TOCTOU) attack, i.e. an attacker could place a dir somewhere so the shim’s validation check would pass, then swap it out with a file before the shim points PCManFM-Qt at it. To mitigate that, we prompt the user if they actually want to open the requested list of directories before opening it.
This gives the user more control, but critically, it makes it impossible for an attacker to accurately predict when they should swap a dir with a file to exploit the TOCTOU issue. They would need to predict exactly when the user was about to click the “Open” button, and if they have enough access to the system to do that, they most likely already have full control of the system anyway. If they don’t do that, the shim will notice the attack attempt, refuse to point PCManFM-Qt to the file, and will display an error message.
This means the attack requires hitting a very small window that is impossible to predict the location of, and the consequences of a failed attack are very bad for the attacker, thus this makes the issue unexploitable in practice. (We could go a step further and prevent the user from clicking the “Open” button for a bounded, random amount of time.) The same “vulnerability” exists when simply navigating through the filesystem with any file manager; when you double-click on a directory, an attacker could replace it with a file at the exact moment you double-click. The checks in the shim are even more robust to this kind of attack than normal file manager behavior.
thank u