Summary
Hutool is a java tool library that provides a wealth of utility class and methods so that developers can handle a variety of common tasks in Java applications. It is widely used in Java development because of its simplicity operation, rich functionality, and exceptional performance.
The author selected the common vulnerabilities of the Hutool component for research by analyzing components introduced in hundreds of real projects. This analysis is about the Resource Exhaustion Vulnerability CVE-2022–4565 when Hutool-core performs unzip operations.
Hutool-core components include Bean operations, dates, various Util, etc,of which the ZipUtil class will be used when compressing or decompressing files.
Information
• Name：Resource Exhaustion Vulnerability
• Number：CVE-2022–4565
• Type：CWE-400 Uncontrolled Resource Consumption
• CVSS Score：CVSS v3.1：7.5
• Severity Level：high
The unzip function of the library’s ZipUtil class does not detect the decompression size of a zip file by default, and therefore may cause resource consumption when decompressing zip files.
This vulnerability can be caused by using Hutool’s default unzip function and not checking the size of the data extracted from the zip file.
This vulnerability affects Hutool-core 4.4.2 ~ 5.8.10.
Analysis
Resource Exhaustion Vulnerabilitity is malicious users or attackers using specific methods to exploit system resources, leading to the depletion of system resources such as CPU, memory, disk space, network bandwidth, etc. This consequently affects the normal operation and availability of the system.
This type of vulnerability can result in the DoS(Denial of Service) attack, causing the system to crash or death. and the system’s performance may degrade when resources are exhausted, thus it may not be able to handle other important security events or prevent attackers from using other known vulnerabilities.
The reason for this vulnerability in the Hutool-core component is that the limit parameter (limit the size after decompression) passed by the default unzip function is set to -1.
When limit is -1, zipFileSize will not be detected. zipFileSize is the sum of the uncompressed sizes of all the files in the zip file.
Reproduction
1.Construct a Zip Bomb file
The principle of ZipBomb is to create a compressed file containing the same symbols, and since this file contains the same information, its compressed file will be much smaller than itself.
For infinitely long repeating bytes, a zip using the DEFLATE compression algorithm has a compression ratio of nearly 1032 (compression ratio = size before compression / size after compression).
For some maliciously constructed Zips, the compression ratio can even reach 28000000:1, which means that a 10MB Zip file can end up decompressing 281TB of files.
The author only for testing, so the construction of the Zip Bomb for about 1024 compression ratio.
The code to create a Zip Bomb file is as follows:
2. Unzip the compressed file using the unzip function of the Hutool component.
3.Result
The 1.08MB zip file was successfully decompressed into a 0.97GB file.
Fix
There are several ways to fix the vulnerability as follows:
1. Upgrade Hutool to version 5.8.11
The principle of the fix is that the checkZipBomb method is called when decompressing, calculating the compression ratio of the file, if the compression ratio is greater than 100 then the decompressed file is regarded as a Zip Bomb file.
The fix can be accomplished by modifying the package management files (pom.xml, build.gradle) and subsequently rebuilding the project.
2.Manual modification of source code
The essence of the first fix is a Patch of code which checks the compression rate inside the unzipped file.So it is also possible to avoid vulnerabilities by implementing the relevant check code yourself.
The fix can be achieved by downloading the component source code and manually Patch the fix, without upgrading the component as a whole to ensure that the rest of the project is not affected.
3.Set disk quotas
Set reasonable disk quotas for users and processes to limit the disk space they use and prevent malicious use.
Take Ubuntu for example.
First, make sure the file system supports disk quotas by adding the usrquota and grpquota parameters when mounting the file system.
sudo mount -o remount,usrquota,grpquota /dev/sda1 /mnt
Subsequently install the disk quota tool.
sudo apt-get install quota
Then configure the disk quota and set the disk quota limit for user user1 to 1GB.
sudo setquota -u user1 1048576 1048576 0 0 /mnt
Among them, the parameter meanings are as follows in sequence: user, hard limit (measured in 1KB units), soft limit (measured in 1KB units), soft limit of inode, hard limit of inode, and file system path.
Finally, the disk quota database is generated and disk quotas are activated.
sudo quotacheck -cum /mnt
sudo quotaon /mnt
This fix can prevent malicious compressed files from impacting other users and systems when there is a resource exhaustion vulnerability in the code.
