Closed apyrgio closed 3 months ago
What would be required to update the aom-libs package to a patched version?
Is it not possible for a creative person to find a similar zero-day in the decode functions in order to get a similar vulnerability?
What would be required to update the aom-libs package to a patched version?
We would need to ship a new container image to our users. Because the container image is currently baked into the application, we need to build Dangerzone on every platform, and essentially do a new 0.7.1 release. We reserve this only for CVEs that affect Dangerzone (as we did for the 0.5.1 release)
Is it not possible for a creative person to find a similar zero-day in the decode functions in order to get a similar vulnerability?
There's an important distinction between zero-days and bug fixes, like for this CVE. I'll try to explain below:
Regarding zero-days, I bet a... creative person most likely has several LibreOffice vulnerabilities in the bag already. Dangerzone operates under this assumption actually. Because these zero-days by definition are not known to the upstream developers, updating the container image will not mitigate them. The defense we offer against these types of known unknowns is a hardened sandbox. The 0.7.0 release has substantially improved the situation there, with the integration of the gVisor project.
Regarding regular bug fixes, we want to offer them to our users by keeping the container image up to date, independently from the Dangerzone application. This requires some changes to make it happen, and we're working on them, but we're not there yet.
Hopefully this answers your question.
P.S. Thanks for your input on the GUI redesign issues. The team currently operates with a skeleton crew (so to speak), but we'll reply to your comments once we're back.
Our security scanner has detected that the
aom-libs
package that we ship in our container has a critical vulnerability (CVE-2024-5171).Who uses this library?
This is a library that renders AV1 codecs. From the original Chromium thread, it seems that the vulnerable function calls are:
aom_img_alloc
aom_img_alloc_with_cb
aom_img_wrap
aom_img_alloc_with_border
In our case, it seems that a GStreamer library (
libgstaom.so
) does use these function calls:More specifically, it uses the vulnerable
aom_img_alloc
function in the encode path (see here).LibreOffice is a consumer of GStreamer, and therefore uses this library when converting documents to PDF:
(taken from https://vmiklos.hu/blog/pdf-video-export.html)
Is Dangerzone affected?
Dangerzone is not affected.
GStreamer uses the vulnerable
aom_img_alloc
function in thegstav1enc.c
file, which implements the encoding of videos to AV1 streams. On the other hand, LibreOffice needs to decode the AV1 stream in order to generate a thumbnail. So, their paths don't cross.We can verify this by invoking LibreOffice with the following GStreamer envvars:
We see that
gstav1enc.c
is not present in the logs. Instead, we see logs fromgstav1parse,c
,gstav1parser.c
andgstav1dec.c
, which belong to the decode path.Next steps
We believe that we can ignore CVE-2024-5171 from our security scans, by adding a reference in
.grype.yaml
.