You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The chain of calls was detected in this repository in a way that leaves this project vulnerable.
File.createTempFile(..) -> file.delete() -> file.createNewFile().
Impact
This vulnerability can have one of two impacts depending upon which vulnerability it is.
1.Temporary Directory Information Disclosure - Information in this directory is visable to other local users, allowing a malicious actor co-resident on the same machine to view potentially sensitive files.
2.Temporary Directory Hijacking Vulnerability - Same impact as 1. above, but also, ther local users can manipulate/add contents to this directory. If code is being executed out of this temporary directory, it can lead to local priviledge escalation.
The fix has been to convert the logic above to use the following API that was introduced in Java 1.7. File tmpDir = Files.createTempFile(prefix, suffix).toFile();
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.
The text was updated successfully, but these errors were encountered:
There may has a temporary file information disclosure vulnerability by use File.createTempFile().
hutool/hutool-core/src/main/java/cn/hutool/core/io/FileUtil.java
Line 1007 in 89832cd
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.
The chain of calls was detected in this repository in a way that leaves this project vulnerable.
File.createTempFile(..) -> file.delete() -> file.createNewFile().
Impact
This vulnerability can have one of two impacts depending upon which vulnerability it is.
1.Temporary Directory Information Disclosure - Information in this directory is visable to other local users, allowing a malicious actor co-resident on the same machine to view potentially sensitive files.
2.Temporary Directory Hijacking Vulnerability - Same impact as 1. above, but also, ther local users can manipulate/add contents to this directory. If code is being executed out of this temporary directory, it can lead to local priviledge escalation.
Other Examples
CVE-2020-15250 - junit-team/junit
CVE-2021-21364 - swagger-api/swagger-codegen
CVE-2022-24823 - netty/netty
CVE-2022-24823 - netty/netty
The Fix
The fix has been to convert the logic above to use the following API that was introduced in Java 1.7.
File tmpDir = Files.createTempFile(prefix, suffix).toFile();
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.
The text was updated successfully, but these errors were encountered: