Comment 0 for bug 1957716

[Links]
https://github.com/flatpak/flatpak/security/advisories/GHSA-qpjc-vq3c-572j
https://github.com/flatpak/flatpak/security/advisories/GHSA-8ch7-5j3h-g4fx
https://security-tracker.debian.org/tracker/CVE-2021-43860

[Impact]
Versions in Ubuntu right now:
Jammy: 1.12.2-2
Impish: 1.10.2-3ubuntu0.1
Focal: 1.6.5-0ubuntu0.4
Bionic: 1.0.9-0ubuntu0.4

Affected versions:
    all

Patched versions:
    1.12.3, 1.10.6

[Test Case]
Unknown

[Regression Potential]
Flatpak has a test suite, which is run on build across all relevant architectures and passes.

There is also a manual test plan https://wiki.ubuntu.com/Process/Merges/TestPlan/flatpak .

Flatpak has autopkgtests enabled http://autopkgtest.ubuntu.com/packages/f/flatpak .

Regression potential is low, and upstream is very responsive to any issues raised.

[Patches]
There are two separate github advisories but only one of them has a CVE.

The advisory with the CVE has 5 patches, the other has 2 patches.

[Other Information]

For the first advisory with the CVE:

Ryan Gonzalez discovered that Flatpak doesn't properly validate that the permissions displayed to the user for an app at install time match the actual permissions granted to the app at runtime, in the case that there's a null byte in the metadata file of an app. Therefore apps can grant themselves permissions without the consent of the user.

Flatpak shows permissions to the user during install by reading them from the "xa.metadata" key in the commit metadata. This cannot contain a null terminator, because it is an untrusted GVariant. Flatpak compares these permissions to the actual metadata, from the "metadata" file to ensure it wasn't lied to.

However, the actual metadata contents are loaded in several places where they are read as simple C-style strings. That means that, if the metadata file includes a null terminator, only the content of the file from before the terminator gets compared to xa.metadata. Thus, any permissions that appear in the metadata file after a null terminator are applied at runtime but not shown to the user. Maliciously crafted apps can use this to give themselves hidden permissions.

In addition, a similar weakness was discovered, where if the permissions in the summary metadata are invalid, they would not be displayed to the user, but the the actual permissions would be granted, even though it didn't match the invalid version.

For the second advisory:

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.

These changes result in a behaviour change as debian have noted in their changelog:

  * Behaviour changes, as a result of how GHSA-8ch7-5j3h-g4fx was fixed:
    - --nofilesystem=host is now special-cased to negate all --filesystem
      permissions. Previously, it would cancel out --filesystem=host but
      not --filesystem=/some/dir.
    - --nofilesystem=home is now special-cased to negate several
      home-directory-related filesystem permssions such as
      --filesystem=xdg-config/foo, not just --filesystem=host.