Stirling-Tools
Introduced protections against "zip slip" attacks
This change updates all new instances of ZipInputStream to protect against malicious entries that attempt to escape their "file root" and overwrite other files on the running filesystem.
Normally, when you're using ZipInputStream it's because you're processing zip files. That code might look like this:
File file = new File(unzipTargetDirectory, zipEntry.getName()); // use file name from zip entry
InputStream is = zip.getInputStream(zipEntry); // get the contents of the zip entry
IOUtils.copy(is, new FileOutputStream(file)); // write the contents to the provided file name
This looks fine when it encounters a normal zip entry within a zip file, looking something like this pseudo-data:
path: data/names.txt
contents: Zeus\nHelen\nLeda...
However, there's nothing to prevent an attacker from sending an evil entry in the zip that looks more like this:
path: ../../../../../etc/passwd
contents: root::0:0:root:/:/bin/sh
Yes, in the above code, which looks like every piece of zip-processing code you can find on the Internet, attackers could overwrite any files to which the application has access. This rule replaces the standard ZipInputStream with a hardened subclass which prevents access to entry paths that attempt to traverse directories above the current directory (which no normal zip file should ever do.) Our changes end up looking something like this:
+ import io.github.pixee.security.ZipSecurity;
...
- var zip = new ZipInputStream(is, StandardCharsets.UTF_8);
+ var zip = ZipSecurity.createHardenedInputStream(is, StandardCharsets.UTF_8);
More reading
Powered by: pixeebot (codemod ID: pixee:java/harden-zip-entry-paths)
Hi zcarroll4,
We are updating Stirling-PDF's license to MPL 2.0 (Mozilla Public License Version 2.0) to continue fostering our open-source commitment while introducing more flexible usage of the project.
What We Need From You:
In order to transition to the MPL 2.0 license, we need the explicit consent of all our contributors.
- If you're comfortable relicensing your contributions for this specific PR under MPL 2.0, please respond with:
I, zcarroll4, grant permission to relicense my contributions from this PR to Stirling-PDF under the Mozilla Public License 2.0. - If you'd prefer to give blanket permission for all of your contributions to Stirling-PDF (be it through pull requests, commits, or any other form of contribution) rather than on a PR-by-PR basis, please respond with:
I, zcarroll4, grant permission to relicense all my contributions to Stirling-PDF under the Mozilla Public License 2.0.
What does this do and why?
As your old code was contributed under a different license it legally cannot move to a new license without your permission, and since we dont want to lose your code we wanted to reach out. Remember this project is remaining open-source!.
Deadline:
If we dont receive a response, or if you decline, unfortunately, we will have to remove your contributions from Stirling-PDF before the license change, which is scheduled in coming months.
Thank You!
Your contributions are invaluable, and we hope to continue having them in Stirling-PDF under the new license. Feel free to ask if you have any questions or concerns about this change.
Best, Frooodle Stirling-PDF Maintainer
@Frooodle I, zcarroll4, grant permission to relicense all my contributions to Stirling-PDF under the Mozilla Public License 2.0.
Sorry for waiting so long on this one, was reviewing their code we are pulling in dependency, i see this has conflicts so i am re-raising with their plugin applied directly to repo, as such will close this PR. thats for bringing this app to my attention however!