Update for CVE-2021-43860 and CVE-2022-21682

[Links]
https://github.com/flatpak/flatpak/security/advisories/GHSA-qpjc-vq3c-572j ( CVE-2021-43860 )
https://security-tracker.debian.org/tracker/CVE-2021-43860

https://github.com/flatpak/flatpak/security/advisories/GHSA-8ch7-5j3h-g4fx ( CVE-2022-21682 )
https://security-tracker.debian.org/tracker/CVE-2022-21682

[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.4, 1.10.7

[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]
The first CVE has 4 patches (+ 1 test patch), the second CVE has 1 patch (+ 6 doc/test 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.

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.