TIOCSTI check

[wland32]

Snap just had a vulnerability where the TIOCSTI seccomp filter could be circumvented.
https://www.exploit-db.com/exploits/46594

Is bubblewrap also affected by this?

[smcv]

bubblewrap doesn't do anything to allow or prevent TIOCSTI, but common/flatpak-run.c in Flatpak might be vulnerable.

[smcv]

Closing this. bubblewrap itself doesn't write seccomp programs, it only accepts seccomp programs from its callers: it is up to the caller (such as Flatpak) to make sure the seccomp program behaves as intended.

I've opened flatpak/flatpak#2782 for the possible existence of a vulnerability similar to CVE-2019-7303 in the overall system of bubblewrap and Flatpak.

[wland32]

Thank you for clarifying.

Before reporting this I found this issue:
#142

Isn't this the same issue regarding bubblewrap itself?

[smcv]

There was some discussion about the best place to fix the class of vulnerability where commands are injected into a parent shell with TIOCSTI (CVE-2017-5226, #142), and my change in #143 was partially reverted in #154. bubblewrap is deliberately minimal and (on systems where it needs to be) highly privileged, so we didn't want it to be linking libseccomp and parsing and compiling its own seccomp rules.

In the end bubblewrap gained two separate ways to fix CVE-2017-5226, and projects that call bubblewrap are expected to choose one (if they care about preventing that class of attack):

• Use --new-session to call setsid(). This fixes the vulnerability completely, is more robust, and should be immune to this new variation too; but it breaks shell job-control (setsid() workaround in 0.1.6 breaks interactive terminals #147, Inappropriate ioctl for device #148), which is very annoying if you're trying to debug something inside a container, so the Flatpak maintainer didn't want to do this.

• Use --seccomp to add seccomp filters, and write your seccomp filter to block TIOCSTI. If you do this, the caller of bubblewrap (Flatpak or equivalent) is responsible for compiling suitable seccomp filters. This is the mechanism that Flatpak chose, which is why this new variation would now need to be fixed in Flatpak instead of in bubblewrap.

[smcv]

Another way to think about this is that bubblewrap doesn't guarantee to provide a security boundary that prevents processes inside the sandbox from attacking processes outside: it's mechanism, not policy. Some bubblewrap command-lines give you relatively strong protection against malicious processes in the sandbox, at the cost of seriously limiting the functionality of non-malicious processes in the sandbox. Other bubblewrap command-lines don't limit the functionality of non-malicious processes in the sandbox, at the cost of giving you no real protection against malicious processes in the sandbox. Real-world uses of bubblewrap like the ones in Flatpak and libgnome-desktop are somewhere in between.

What bubblewrap does provide is a set of building blocks, with which a larger project (like Flatpak or libgnome-desktop) can set up a security boundary that's suitable for its needs. If those building blocks aren't behaving as documented, that might be a security vulnerability in bubblewrap, but if they have been put together wrong, that's a security vulnerability in the user of bubblewrap.

bubblewrap does have one important security guarantee that it needs to provide itself: on systems where it's setuid root (like Debian and RHEL), it needs to prevent user processes (both inside and outside the sandbox) from escalating their privileges beyond what they started with. The TIOCSTI attacks don't cause a problem here, because the most they can do is whatever the user running bwrap could already have done without using bwrap.

[wland32]

Another way to think about this is that bubblewrap doesn't guarantee to provide a security boundary that prevents processes inside the sandbox from attacking processes outside: it's mechanism, not policy. Some bubblewrap command-lines give you relatively strong protection against malicious processes in the sandbox, at the cost of seriously limiting the functionality of non-malicious processes in the sandbox. Other bubblewrap command-lines don't limit the functionality of non-malicious processes in the sandbox, at the cost of giving you no real protection against malicious processes in the sandbox. Real-world uses of bubblewrap like the ones in Flatpak and libgnome-desktop are somewhere in between.

What bubblewrap does provide is a set of building blocks, with which a larger project (like Flatpak or libgnome-desktop) can set up a security boundary that's suitable for its needs. If those building blocks aren't behaving as documented, that might be a security vulnerability in bubblewrap, but if they have been put together wrong, that's a security vulnerability in the user of bubblewrap.

Thanks for the explanation

bubblewrap does have one important security guarantee that it needs to provide itself: on systems where it's setuid root (like Debian and RHEL), it needs to prevent user processes (both inside and outside the sandbox) from escalating their privileges beyond what they started with. The TIOCSTI attacks don't cause a problem here, because the most they can do is whatever the user running bwrap could already have done without using bwrap.

My assumption is, that bubblewrap only uses suid to execute user namespaces on systems where only privileged users have access to this feature, then dropping all privileges for good and executing everything else inside the user namespace (where it has access to all other namespaces as the "namespaced root").

There have been many vulnerabilities due to unprivileged user namespaces being available to unprivileged users. This is why many distributions have limitid access to user namespaces.

Question is:
Does using suid to gain access to user namespaces as an unprivileged user reopen this issue, meaning the same security issues that where removed by limiting the use of user namespaces to privileged users, are reopened when bubblewrap is installed as suid?

[smcv]

My assumption is, that bubblewrap only uses suid to execute user namespaces on systems where only privileged users have access to this feature, then dropping all privileges for good and executing everything else inside the user namespace (where it has access to all other namespaces as the "namespaced root").

Partially. On some systems (where user namespaces are completely disabled, not just restricted), bubblewrap needs to do its setup as root, and only drop privileges later. However, it always drops those privileges before running the user-supplied executable (in the Flatpak case: before running code from inside the sandbox).

Does using suid to gain access to user namespaces as an unprivileged user reopen this issue, meaning the same security issues that where removed by limiting the use of user namespaces to privileged users, are reopened when bubblewrap is installed as suid?

Mostly no. A setuid bubblewrap is higher-risk than no bubblewrap at all, because there might be a bug in bubblewrap; but it's designed to be lower-risk than letting users create namespaces whenever they want to, because it doesn't let users execute arbitrary code with capabilities, not even in the new namespace.