freedomofpress / dangerzone

Take potentially dangerous PDFs, office documents, or images and convert them to safe PDFs
https://dangerzone.rocks/
GNU Affero General Public License v3.0
3.73k stars 172 forks source link

Ignore CVE-2024-5171 from security scans #895

Closed apyrgio closed 3 months ago

apyrgio commented 3 months ago

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:

In our case, it seems that a GStreamer library (libgstaom.so) does use these function calls:

$ readelf -Ws /usr/lib/gstreamer-1.0/libgstaom.so | grep aom_img
    26: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND aom_img_free
    41: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND aom_img_alloc

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:

On the LibreOffice side all we require is to be able to extract a key frame from the video to provide a preview image, so e.g. on Linux the support depends on what gstreamer plugins you have installed.

(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 the gstav1enc.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:

$ GST_DEBUG=*:6 libreoffice --headless --convert-to pdf --outdir . test.odp
[...]
0:00:00.192904920 359295 0x7525f0002690 LOG         codecparsers_av1 gstav1parser.c:819:gst_av1_parser_identify_one_obu: identify obu type is 6                                                                                               
0:00:00.192912986 359295 0x7525f0002690 LOG                 av1parse gstav1parse.c:1430:gst_av1_parse_handle_one_obu:<av1parse1> parsing the obu frame, result is 0
0:00:00.193099180 359295 0x7525f0002690 DEBUG               av1parse gstav1parse.c:744:gst_av1_parse_update_src_caps:<av1parse1> Update src caps video/x-av1, stream-format=(string)obu-stream, alignment=(string)tu, codec_data=(buffer)81040c000a0b00000024cf7f0dbfff3008, width=(int)960, height=(int)540, framerate=(fraction)25/1, pixel-aspect-ratio=(fraction)1/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)main
0:00:00.195891100 359295 0x7525f0002690 DEBUG                 av1dec gstav1dec.c:142:gst_av1_dec_init:<GstAV1Dec@0x7525b400ead0> gst_av1_dec_init
[...]

We see that gstav1enc.c is not present in the logs. Instead, we see logs from gstav1parse,c, gstav1parser.c and gstav1dec.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.

DeltaEpsilon19498 commented 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?

apyrgio commented 3 months ago

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.