[SECURITY] Fix Temporary Directory Hijacking or Information Disclosure Vulnerability #53
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Security Vulnerability Fix
This pull request fixes either 1.) Temporary Directory Hijacking Vulnerability, or 2.) Temporary Directory Information Disclosure Vulnerability, which existed in this project.
Preamble
The system temporary directory is shared between all users on most unix-like systems (not MacOS, or Windows). Thus, code interacting with the system temporary directory must be careful about file interactions in this directory, and must ensure that the correct file permissions are set.
This PR was generated because the following chain of calls was detected in this repository in a way that leaves this project vulnerable.
File.createTempFile(..)
->file.delete()
-> eitherfile.mkdir()
orfile.mkdirs()
.Impact
This vulnerability can have one of two impacts depending upon which vulnerability it is.
Temporary Directory Hijacking
This vulnerability exists because the return value from
file.mkdir()
orfile.mkdirs()
is not checked to determine if the call succeeded. Say, for example, because another local user created the directory before this process.Other Examples
Temporary Directory Information Disclosure
This vulnerability exists because, although the return values of
file.mkdir()
orfile.mkdirs()
are correctly checked, the permissions of the directory that is created follows the default systemuname
settings. Thus, the directory is created with everyone-readable permissions. As such, any files/directories written into this directory are viewable by all other local users on the system.Other Examples
The Fix
The fix has been to convert the logic above to use the following API that was introduced in Java 1.7.
The API both created the directory securely, ie with a random, non-conflicting name, with directory permissions that only allow the currently executing user to read or write the contents of this directory.
➡️ Vulnerability Disclosure ⬅️
👋 Vulnerability disclosure is a super important part of the vulnerability handling process and should not be skipped! This may be completely new to you, and that's okay, I'm here to assist!
First question, do we need to perform vulnerability disclosure? It depends!
Vulnerability Disclosure How-To
You have a few options options to perform vulnerability disclosure. However, I'd like to suggest the following 2 options:
Detecting this and Future Vulnerabilities
This vulnerability was automatically detected by GitHub's LGTM.com using this CodeQL Query.
You can automatically detect future vulnerabilities like this by enabling the free (for open-source) GitHub Action.
I'm not an employee of GitHub, I'm simply an open-source security researcher.
Source
This contribution was automatically generated with an OpenRewrite refactoring recipe, which was lovingly hand crafted to bring this security fix to your repository.
The source code that generated this PR can be found here:
UseFilesCreateTempDirectory
Opting-Out
If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called
.github/GH-ROBOTS.txt
to your repository with the line:This bot will respect the ROBOTS.txt format for future contributions.
Alternatively, if this project is no longer actively maintained, consider archiving the repository.
CLA Requirements
This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.
It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.
If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.
Sponsorship & Support
This contribution is sponsored by HUMAN Security Inc. and the new Dan Kaminsky Fellowship, a fellowship created to celebrate Dan's memory and legacy by funding open-source work that makes the world a better (and more secure) place.
This PR was generated by Moderne, a free-for-open source SaaS offering that uses format-preserving AST transformations to fix bugs, standardize code style, apply best practices, migrate library versions, and fix common security vulnerabilities at scale.
Tracking
All PR's generated as part of this fix are tracked here: JLLeitschuh/security-research#10