flatpak-builder applies finish-args last in the build. At this point the build directory will have the full access that is specified in the manifest, so running flatpak build against it will gain that permissions. Normally this will not be done, so this is not problem. However, if --mirror-screenshots-url is specified, then flatpak-builder will launch flatpak build --nofilesystem=host appstream-utils mirror-screenshots after finalization, which can lead to issues even with the --nofilesystem=host protection.
There are two issues:
--nofilesystem=host only overrides the access to the full host. The app can still request access to a specific directory, like --filesystem=~/some-dir, which is not affected by this.- If a filesystem is specified like
--filesystem=~/foobar:create, then that directory will be created before running the command.
In normal use the only issue is that these empty directories can be created wherever the user has write permissions. However, a malicious application could replace the appstream-util binary and potentially do something more hostile.
Workaround
Do not build apps provided by untrusted sources until this vulnerability is resolved, or isolate flatpak-builder into a virtual machine or a securely-configured container.
Solution
This has been resolved in flatpak-builder 1.2.2 when used with Flatpak 1.12.4 and 1.10.7, by adding a new --nofilesystem=host:reset command-line option and making flatpak-builder use it.
In Flatpak >= 1.12.4 and Flatpak 1.10.x >= 1.10.7, the --nofilesystem=host:reset option behaves like --nofilesystem=host, but also prevents filesystem permissions from being inherited from the app manifest or overrides. flatpak-builder >= 1.2.2 uses --nofilesystem=host:reset to resolve the vulnerability.
In older Flatpak versions, the --nofilesystem=host:reset option prints a warning, but otherwise behaves like --nofilesystem=host, making flatpak-builder 1.2.2 backwards-compatible with older versions of Flatpak (although it will still be vulnerable to CVE-2022-21682 in this situation, and upgrading Flatpak is strongly recommended).
Patches
flatpak:
flatpak documentation and test coverage (not strictly required):
flatpak-builder:
Previous solution
In Flatpak 1.12.3 and Flatpak 1.10.6, the semantics of --nofilesystem=host were changed to prevent filesystem permissions from being inherited from the app manifest or overrides. However, this change caused regressions for some previously-working Flatpak use cases, and was subsequently reverted. These versions are not vulnerable to CVE-2022-21682 (even if flatpak-builder has not been upgraded), but upgrading to newer versions is recommended.
flatpak-builder applies
finish-argslast in the build. At this point the build directory will have the full access that is specified in the manifest, so runningflatpak buildagainst it will gain that permissions. Normally this will not be done, so this is not problem. However, if--mirror-screenshots-urlis specified, then flatpak-builder will launchflatpak build --nofilesystem=host appstream-utils mirror-screenshotsafter finalization, which can lead to issues even with the--nofilesystem=hostprotection.There are two issues:
--nofilesystem=hostonly overrides the access to the full host. The app can still request access to a specific directory, like--filesystem=~/some-dir, which is not affected by this.--filesystem=~/foobar:create, then that directory will be created before running the command.In normal use the only issue is that these empty directories can be created wherever the user has write permissions. However, a malicious application could replace the
appstream-utilbinary and potentially do something more hostile.Workaround
Do not build apps provided by untrusted sources until this vulnerability is resolved, or isolate
flatpak-builderinto a virtual machine or a securely-configured container.Solution
This has been resolved in flatpak-builder 1.2.2 when used with Flatpak 1.12.4 and 1.10.7, by adding a new
--nofilesystem=host:resetcommand-line option and making flatpak-builder use it.In Flatpak >= 1.12.4 and Flatpak 1.10.x >= 1.10.7, the
--nofilesystem=host:resetoption behaves like--nofilesystem=host, but also prevents filesystem permissions from being inherited from the app manifest or overrides. flatpak-builder >= 1.2.2 uses--nofilesystem=host:resetto resolve the vulnerability.In older Flatpak versions, the
--nofilesystem=host:resetoption prints a warning, but otherwise behaves like--nofilesystem=host, making flatpak-builder 1.2.2 backwards-compatible with older versions of Flatpak (although it will still be vulnerable to CVE-2022-21682 in this situation, and upgrading Flatpak is strongly recommended).Patches
flatpak:
flatpak documentation and test coverage (not strictly required):
flatpak-builder:
Previous solution
In Flatpak 1.12.3 and Flatpak 1.10.6, the semantics of
--nofilesystem=hostwere changed to prevent filesystem permissions from being inherited from the app manifest or overrides. However, this change caused regressions for some previously-working Flatpak use cases, and was subsequently reverted. These versions are not vulnerable to CVE-2022-21682 (even if flatpak-builder has not been upgraded), but upgrading to newer versions is recommended.