Arbitrary File Write via Archive Extraction (Zip Slip) in go-rpmutils
2020年7月20日
0 分で読めますWelcome to the Snyk Monthly Vulnerability Profile. In this series, Snyk looks back on the vulnerabilities discovered by or reported to our Security Research Team. We choose one noteworthy vulnerability from the past month and tell the story behind the discovery, research, and disclosure of the vulnerability. We highlight the researchers, developers, and users who are helping identify and remediate vulnerabilities across the open source community.
This month we’re looking at one of a series of Zip Slip vulnerabilities Snyk’s Security Research Team identified in Golang packages.
Vulnerability: Arbitrary File Write via Archive Extraction (Zip Slip) CVEs assigned:CVE-2020-7667Snyk Analyst: George GkitsasDiscovered by: Snyk Research Team
On 5 June 2020, the Snyk Research Team published the details of an Arbitrary File Write vulnerability that could be achieved via a malicious zip archive. The vulnerability was identified in the Golang package go-rpmutils and was discovered by Snyk researchers as part of a larger effort to identify Zip Slip vulnerabilities across the open source ecosystem. Senior Security Analyst, George Gkitsas was the researcher who initially identified the vulnerability in the rpmutils package. Ultimately, the vulnerability was reported to the package maintainer, fixed quickly, and published to the CVE as well as the Snyk Vulnerability Database once the fixed version of the package was released.
Before we dive into the details of the research that uncovered this vulnerability, let’s quickly discuss the nature of a Zip Slip vulnerability. Exploiting a Zip Slip vulnerability involves leveraging directory traversal via a maliciously crafted archive file. When the file is extracted by a vulnerable method, files in unintended locations can be overwritten. This could allow an attacker to overwrite system files and ultimately result in malicious remote command execution or possibly gaining remote access to the system. For more technical details on the Zip Slip vulnerability and how you can prevent it, check out the Zip Slip Cheat Sheet.
As a member of the Snyk Research Team, George was attempting to find patterns that could be identified quickly across repositories to help pinpoint potentially vulnerable packages. As part of his research, he chose to focus initially on the Golang ecosystem. The team chose roughly 60 packages to focus on in the initial round and went through each package analyzing them for the potential vulnerability. There were a number of false positives identified which helped the team better tune their algorithms, but ultimately five vulnerabilities were discovered from their research. Three of these vulnerabilities, including the vulnerable go-rmputils package, have been assigned CVEs and published to the Snyk Vulnerability Database. Snyk is continuing to work with the maintainers for the other two vulnerable packages to ensure a fix is available before the vulnerabilities are publicly disclosed.
In the case of go-rpmutils, after discovering and confirming the exploitability of the vulnerability, George attempted to reach out to the maintainer of the package which in this case was an organization, SAS Software. The initial contact was made via email to the address that was specified on the organization profile for the repository itself. While this ultimately proved not to be the correct address for these types of reports, George’s notification was quickly forwarded to a dedicated resource responsible for handling such disclosures. Snyk was later informed that SAS Software does have a dedicated email address for vulnerability disclosures. This is considered by many in the security and development communities to be the best practice.
In any event, SAS Software was responsive throughout the process—the initial response to the disclosure came within hours. George worked with the security personal to ensure responsible public disclosure of the vulnerability once a fix was available. The vendor’s team responded quickly with a fix which George was then able to test and validate sufficiently remediated the vulnerability. The vulnerability was ultimately published on 5 June 2020, only 6 days after the initial notification to the vendor.
This particular instance is a great example of the cooperation between researchers and maintainers that can happen when all parties are committed to responsibly and efficiently addressing security concerns. The maintainer, SAS Software in this instance, was very responsive and acted quickly and definitively to resolve the issue. Snyk and SAS Software were able to work together to ensure the fix fully addressed the issue and to make the details of the vulnerability public only after a fix was available. If there is an action item that can be taken from this story to improve for the future it would be that having a dedicated notification path for vulnerability disclosure is good. You should also consider making that easily available by publishing it within your README files and posting it to your profile in the repository.
Snyk’s goal is to ensure the validity and exploitability of the vulnerabilities while providing maintainers with responsible disclosure and detailed guidance for fixing their vulnerabilities. For more information on this vulnerability or how to report a vulnerability you’ve discovered in an open source project, see the links below.