The first two vulnerabilities (CVE-2024-45491, CVE-2024-45492) do not affect our container image, because they apply only to 32-bit architectures. The third one applies to 64-bit architectures as well, so it requires a bit more dig from us.
Our understanding (credits to @lsd-cat) is that to exploit the bug, you need to pass a negative length to the XML_ParseBuffer libexpat API call when parsing an XML buffer. Usually this function is not called on its own, but users call a wrapper instead, which should provide the proper length. For this reason, we believe that this attack is valid, but does not apply to our workloads, and therefore is more theoretical. Case in point:
LibreOffice does not use the XML_ParseBuffer function directly.
We believe we can ignore these CVEs from our security scans, but we're well aware that we need to release a new container image soon. We also hope that we will have a permanent solution to this problem with independent container updates (#745) within the next releases.
Our security scanner has picked up the following CRITICAL
libexpatvulnerabilities for the Dangerzone image:The first two vulnerabilities (CVE-2024-45491, CVE-2024-45492) do not affect our container image, because they apply only to 32-bit architectures. The third one applies to 64-bit architectures as well, so it requires a bit more dig from us.
Our understanding (credits to @lsd-cat) is that to exploit the bug, you need to pass a negative length to the
XML_ParseBufferlibexpat API call when parsing an XML buffer. Usually this function is not called on its own, but users call a wrapper instead, which should provide the proper length. For this reason, we believe that this attack is valid, but does not apply to our workloads, and therefore is more theoretical. Case in point:XML_ParseBufferfunction directly.libexpatversions (as of 2024-09-09): https://security-tracker.debian.org/tracker/CVE-2024-45490We believe we can ignore these CVEs from our security scans, but we're well aware that we need to release a new container image soon. We also hope that we will have a permanent solution to this problem with independent container updates (#745) within the next releases.