CVE Vulnerabilities

CVE-2021-43860

Incorrect Default Permissions

Published: Jan 12, 2022 | Modified: Dec 23, 2023
CVSS 3.x
8.6
HIGH
Source:
NVD
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
CVSS 2.x
6.8 MEDIUM
AV:N/AC:M/Au:N/C:P/I:P/A:P
RedHat/V2
RedHat/V3
Ubuntu

Flatpak is a Linux application sandboxing and distribution framework. Prior to versions 1.12.3 and 1.10.6, Flatpak doesnt 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 theres 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 wasnt 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. So maliciously crafted apps can give themselves hidden permissions. Users who have Flatpaks installed from untrusted sources are at risk in case the Flatpak has a maliciously crafted metadata file, either initially or in an update. This issue is patched in versions 1.12.3 and 1.10.6. As a workaround, users can manually check the permissions of installed apps by checking the metadata file or the xa.metadata key on the commit metadata.

Weakness

During installation, installed file permissions are set to allow anyone to modify those files.

Affected Software

Name Vendor Start Version End Version
Flatpak Flatpak * 1.10.6 (excluding)
Flatpak Flatpak 1.11.1 (including) 1.12.3 (including)

Potential Mitigations

  • Compartmentalize the system to have “safe” areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
  • Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

References