Is injecting D-Bus into the process not fundamentally flawed?
Lewiscowles1986 opened this issue · 1 comments
Hi thanks for writing and sharing this tool.
It is very interesting engineering. I Particularly love that it uses existing mechanisms, such as LD_PRELOAD and flatpak sandboxing. What I am about to say is not about the engineering prowess, and more about basic risk mitigation.
This is a bit messy because Flatpak's sandboxing APIs all use D-Bus, so a new D-Bus session must be "injected" into the main Chromium process
I Think this sounds really dangerous, and likely could be used in a beach-head situation to attack user machines.
flatpak/flatpak#5161 describes how subtle misconfiguration in flatpak can leave it's "secure sandbox" in a state than can leave a machine vulnerable. That won't matter if the software is never reading from a network, but chromium definitely is.
GHSA-4ppf-fxf6-vxg2 allows for remote code execution, so every user of this will have to perpetually keep everything up to date and pray that no red team or bad actor targets this configuration to harm users.
I'm absolutely not saying that Chromium, or flatpak might not also suffer from similar flaws, due to the chromium proprietary garbage nature of downloading "trusted" third-party code, such as widevine; I don't see how this could ever be safe for users.
Even "legitimate actors" could use this to harm their users. In the way SONY BMG used to think it was okay to protect themselves by root-kit'ing user machines https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal the dbus access, and potential for RCE would give more than enough access to change the host system, outside of the flatpak configuration.
I'm pretty confident this does not affect security at the Flatpak level. I don't know if it might weaken Chromium's own sandboxing (the walls between different domains you visit), but if it's only injected in the main process, as that quote says, I think it's OK on that count too.
Zypak runs, as I understand it, inside Flatpak's sandbox, and thus it can't give the app any access it wouldn't already have. Zypak sets up a D-Bus connection inside the sandbox, but the app could just as well connect to D-Bus itself, or use something like the dbus-send command (which is there in the freedesktop runtime, for instance). The sandbox should restrict what D-Bus messages can be sent from inside to outside the sandbox.
You point to two general issues with Flatpak's sandboxing:
The GHSA one is simply a bug. All non-trivial software has bugs. 😉 "Perpetually keep everything up to date" is pretty much what we should do with any security-critical software. That applies to Flatpak just like it does to web browsers. The specific bug you linked was fixed nearly 2 years ago, but there have been others and there will almost certainly be more to be found.
The other one is part of a broader issue. For decades, we've built software assuming it has complete access to your user account, if not the entire system. So we often need to leave the sandbox leaky just to make stuff work. And developers don't feel much pressure to change how the code works. Making the sandboxing more restrictive is going to be a long process, depending on things like Wayland replacing X11, Portals being good enough to meet most needs, developers learning about newer ways of doing things, and users caring about sandboxing & gently applying pressure that exceptions should be rare.
Web & mobile sandboxing is easier, because those environments started with sandboxing; for desktop apps we're trying to get there from a completely unsandboxed world. And the open nature of Linux means even the likes of Red Hat & Canonical can't apply pressure on app developers like Microsoft or Apple can for their ecosystems.