Flatpak hasta 1.10.5/1.12.2 Metadata File escalada de privilegios

Una vulnerabilidad clasificada como crítica ha sido encontrada en Flatpak hasta 1.10.5/1.12.2. Una función desconocida del componente Metadata File Handler es afectada por esta vulnerabilidad. Una actualización a la versión 1.10.6 o 1.12.3 elimina esta vulnerabilidad. La actualización se puede descargar de github.com. Aplicando el parche 54ec1a482dfc668127eaae57f135e6a8e0bc52da es posible eliminar el problema. El parche puede ser descargado de github.com. El mejor modo sugerido para mitigar el problema es actualizar a la última versión.

Cronología

Usuario

136
019

Campo

source_cve_nvd_summary2
advisory_confirm_url1
exploit_price_0day1
vulnerability_cvss3_meta_tempscore1
vulnerability_cvss3_meta_basescore1

Commit Conf

90%42
50%10
70%3

Approve Conf

90%42
80%10
70%3
IDComprometidoUsuarioCampoCambioObservacionesAceptadoRazónC
120501782022-01-15VulD...cve_nvd_summaryFlatpak is a Linux application sandboxing and distribution framework. Prior to versions 1.12.3 and 1.10.6, 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. 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.cvedetails.com2022-01-15aceptado
70
120501772022-01-15VulD...cve_nvd_summaryFlatpak is a Linux application sandboxing and distribution framework. Prior to versions 1.12.3 and 1.10.6, 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. 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.cve.mitre.org2022-01-15aceptado
70
120501762022-01-15VulD...confirm_urlhttps://github.com/flatpak/flatpak/security/advisories/GHSA-qpjc-vq3c-572jcve.mitre.org2022-01-15aceptado
70
120379722022-01-13VulD...price_0day$0-$5ksee exploit price documentation2022-01-13aceptado
90
120379712022-01-13VulD...cvss3_meta_tempscore8.3see CVSS documentation2022-01-13aceptado
90
120379702022-01-13VulD...cvss3_meta_basescore8.5see CVSS documentation2022-01-13aceptado
90
120379692022-01-13VulD...cvss3_vuldb_tempscore8.4see CVSS documentation2022-01-13aceptado
90
120379682022-01-13VulD...cvss3_vuldb_basescore8.8see CVSS documentation2022-01-13aceptado
90
120379672022-01-13VulD...cvss2_vuldb_tempscore7.8see CVSS documentation2022-01-13aceptado
90
120379662022-01-13VulD...cvss2_vuldb_basescore9.0see CVSS documentation2022-01-13aceptado
90
120379652022-01-13VulD...cvss3_cna_basescore8.2see CVSS documentation2022-01-13aceptado
90
120379642022-01-13VulD...cvss3_vuldb_eXderived from historical data2022-01-13aceptado
80
120379632022-01-13VulD...cvss2_vuldb_eNDderived from historical data2022-01-13aceptado
80
120379622022-01-13VulD...cvss2_vuldb_auSderived from historical data2022-01-13aceptado
80
120379612022-01-13VulD...cvss2_vuldb_rlOFderived from vuldb v3 vector2022-01-13aceptado
80
120379602022-01-13VulD...cvss2_vuldb_rcCderived from vuldb v3 vector2022-01-13aceptado
80
120379592022-01-13VulD...cvss2_vuldb_aiCderived from vuldb v3 vector2022-01-13aceptado
80
120379582022-01-13VulD...cvss2_vuldb_iiCderived from vuldb v3 vector2022-01-13aceptado
80
120379572022-01-13VulD...cvss2_vuldb_ciCderived from vuldb v3 vector2022-01-13aceptado
80
120379562022-01-13VulD...cvss2_vuldb_acLderived from vuldb v3 vector2022-01-13aceptado
80

35 no se muestran más entradas

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!