http://bugs.winehq.org/show_bug.cgi?id=59767 Bug ID: 59767 Summary: loader/wine.desktop enables programs to escape Flatpak sandboxes in many if not most situations Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: loader Assignee: wine-bugs@list.winehq.org Reporter: arraybolt3@gmail.com Distribution: --- This is kind of a weird bug as it doesn't have anything to do with Windows applications in particular, but rather with how Wine registers itself with the system. loader/wine.desktop registers Wine as a MIME handler for a number of different Windows-related executable file formats (EXEs, MSIs, and Batch files. Linux doesn't recognize these files as programs (unless they have their executable bit set and are registered with binfmt-misc of course), so it will attempt to "open" these files with Wine. Wine will then run arbitrary code within these programs with the privileges of whatever program launched Wine. On the surface, this doesn't sound like a problem, but it becomes an issue because sandboxed code under Linux can usually use D-Bus to open files in their default application *outside of the sandbox*. Since the default application to open EXE files in is Wine, anything that can open arbitrary files outside of the sandbox can now escape the sandbox by writing an EXE file somewhere and then "opening" it with Wine. There are two ways I know of to do this: * Some file managers handle the org.freedesktop.FileManager1.ShowFolders method call by opening the "folders" they are told to open with their default application. Of course, there is no guarantee that the "folders" actually are folders; if the sandboxed app passes a file name in this call, those file managers will open the specified files in their default application. If Wine is installed, and one of the "folders" specified is an EXE file, the application can now run arbitrary code outside of the sandbox. (I reported this bug to an affected file manager over 90 days ago.) * xdg-desktop-portal-gtk intentionally allows applications to open arbitrary files outside of a sandbox, via the org.freedesktop.portal.OpenURI.OpenFile D-Bus method. If there are multiple applications that can open the same file type, it will usually open a dialog asking what application to open the file in, but if there is only one handler for a file type on the system, it will immediately open the file with its default handler. Handlers for EXE files other than Wine are relatively rare (lxqt-archiver is one, oddly enough), so there is a very good chance that a sandboxed app can just write an EXE file to the disk, then open it with xdg-desktop-portal-gtk and have code execution outside the sandbox. (I reported this privately to the Flatpak developers over 90 days ago.) Arguably, neither of these issues are security vulnerabilities in xdg-desktop-portal or file managers. The `xdg-mime` manpage warns: Security Note: Never set a handler that will blindly execute code or commands from the file being handled. Such behavior will sooner than later lead to unintended code execution i.e. through a curious user trying to inspect a freshly downloaded file but running it by accident. Keeping opening and executing separate actions helps with people protecting themselves from malware, the default handler is an opener, not a runner. Therefore I believe this is an issue with Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.