Package: rust-sequoia-octopus-librnp
Version: 1.11.0-1
Severity: important
Dear Maintainer,
reported by codean via the YesWeHack bug bounty program:
DoS via bzip2 decompression bomb
Bug type: Denial of Service (CWE-400)
Scope: octopus
Endpoint: decompression mechanism
Vulnerable part: Others
Part name: BZip
Payload: An openpgp message containing a specially crafted compressed message Technical env.: OS
App. fingerprint:
CVE:
Impact:
IP used: 0.0.0.0
Description
The OpenPGP standard supports the use of a Compressed Data packet to include compressed content in OpenPGP messages. The sequoia-pgp implementation supports the zip, zlib, and bzip2 compression algorithms. Decompression for bzip2 is handled using the
bzip2 library.
This decompression function is applied directly to the compressed content without checking the size of the resulting decompressed payload.
As a result, the library decompresses the entire content, regardless of size. This behavior is also present in octopus, the drop-in replacement for the RNP library used by Thunderbird.
Because sequoia-pgp does not enforce size limits on OpenPGP messages and due to the very high compression ratio achievable with bzip2 (greater than 5,000,000), an attacker can craft a small message that, when processed by sequoia-pgp in octopus, causes
CPU usage to spike to 100% for a significant amount of time. This leads to resource exhaustion and renders Thunderbird unresponsive. Similar behavior will occur in any application or library that makes use of sequoia-pgp in a single-threaded manner.
The decompression factor could potentially be increased even further by using nested Compressed Data packets, but this was not tested.
Impact
An attacker is able to craft a PGP message that will force sequoia-pgp to drammatically increase the CPU usage, freezing the Thunderbird application when sequoia-octopus-librnp is used.
Decompressing a 98KB message, which inflates to 20GB of uncompressed content, takes up to 3 minutes on an AMD Ryzen 7 PRO 7840U machine.
While this applies to all supported compression algorithms, it has a significantly higher impact with bzip2, due to the much larger achievable compression ratio.
Solution
A suitable mitigation for libraries like sequoia-pgp is to implement a configurable size limit on the decompressed payload. This would help prevent Denial-of-Service attacks that exploit this behavior.
Attachment: Proof of Concept
In order to generate a small compressed PGP message we can use the following command, which will generate a 50KB ASCII-armored message with a 10GB decompressed payload:
dd if=/dev/zero bs=1M status=none count=10240 | gpg --compress-algo BZIP2 --sign --armor --output dos_message.pgp.asc
Once generated, send the content as the body of an email and open it using Thunderbird with sequoia-octopus-librnp installed. You will notice that the application freezes and CPU usage spikes.
Triager
Hello,
We were able to reproduce the described behavior.
A Decompression Bomb (or Zip Bomb) is a maliciously crafted compressed file designed to consume excessive system resources when decompressed, potentially leading to denial of service or application crashes.
Because sequoia-pgp does not enforce size limits on OpenPGP messages and due to the very high compression ratio achievable with bzip2 (greater than 5,000,000), an attacker can craft a small message that, when processed by sequoia-pgp in octopus, causes
CPU usage to spike to 100% for a significant amount of time. This leads to resource exhaustion and renders Thunderbird unresponsive. Similar behavior will occur in any application or library that makes use of sequoia-pgp in a single-threaded manner.
Proof of Concept
The attacker crafts a small compressed PGP message :
dd if=/dev/zero bs=1M status=none count=10240 | gpg --compress-algo BZIP2 --sign --armor --output dos_message.pgp.asc
This create a 50KB with a 10GB decompressed payload
The attacker send this message as a body of an email
The victims open the email using Thunderbird with sequoia-octopus-librnp
https://crates.io/crates/sequoia-octopus-librnp#building-on-linux
Then, attempt to decrypt the message and observe it dramatically increase the CPU usage, freezing the Thunderbird application.
Note that the proposed CVSS score serves as a starting point to support further discussion. Please feel free to reach out if you'd like to review or adjust it.
About the CVSS vector, it seems correct.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
It's the end of the world as we know it - and I feel fine.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhuQR8ACgkQCRq4Vgaa qhzynQ/+LdRGufEzJzSLnnTBYbAaYv9+OSGd1RA6IUpK7vGIpgRoNGpwlkZfQrhA D71UPUfJJkmofrgats+drIe+BN8EXl4iIfXHdKUKQqttETiGEozf9R52fKdiwj/w tSzSavb6H25nqKvraEvLnayFU3KwXWfL8LnUL5Rr+lbGAkSCU3KVoRmvBO/C1VM2 M2soCA06JXaE0US5yvRVtRT6TOoqxAWqz3iGeE/J3WQDCgUMDkthKrD6qsuDbETY YChLpZute6kJArBWnV/QhudPUb9zdmwwYILAp0iYgwP/fyxmbWC/2nvNV5fdp0FJ jMY2uPXmNVgRh9LMrpCsyx6XCmvFaNnQd+sayLq8B5jfb50F8Ci2uv971SH1uJZc d9rHFN2eYOCPuSogxDHX5Ui9sgF2ug4E5UTUVNVhGAwgOm7EItFcvUKdGOgi+wjx 0tbiObHsEDKkCkjkyRyB0vvAvLq3Bz7SzhsNenL1qJJWaqS+oPPBR5x9mkgvXt5X FSlT3oYPR+qyw1MBwjpgPjjjEiHN0O3PaWATVRJlioK49HLcQU5U38dNkQRuAIu2 0fqm619VEl0aRgPouwdpWDiytVKI23WJP26ymVN4B7tkA/wDx7sZMf