CVE-2020-8908: Files::createTempDir local information disclosure vulnerability
See original GitHub issueIMPORTANT NOTE
Updating to Guava 30.0 does not fix this security vulnerability. The method is merely deprecated. There currently exits no fix for this vulnerability.
https://github.com/google/guava/issues/4011#issuecomment-765672282
Since the fix for this vulnerability is now disclosed by this commit (https://github.com/google/guava/commit/fec0dbc4634006a6162cfd4d0d09c962073ddf40) and it was closed internally by google as ‘Intended Functionality’ I figure I’ll disclose the vulnerability fully.
Vulnerability
File guavaTempDir = com.google.common.io.Files.createTempDir();
System.out.println("Guava Temp Dir: " + guavaTempDir.getName());
runLS(guavaTempDir.getParentFile(), guavaTempDir); // Prints the file permissions -> drwxr-xr-x
File child = new File(guavaTempDir, "guava-child.txt");
child.createNewFile();
runLS(guavaTempDir, child); // Prints the file permissions -> -rw-r--r--
On the flip side, when using java.nio.file.Files
, this creates a directory with the correct file permissions.
Path temp = Files.createTempDirectory("random-directory");
System.out.println("Files Temp Dir: " + temp.getFileName());
runLS(temp.toFile().getParentFile(), temp.toFile()); // Prints the file permissions -> drwx------
Path child = temp.resolve("jdk-child.txt");
child.toFile().createNewFile();
runLS(temp.toFile(), child.toFile()); // Prints the file permissions -> -rw-r--r--
Impact
The impact of this vulnerability is that, the file permissions on the file created by com.google.common.io.Files.createTempDir
allows an attacker running a malicious program co-resident on the same machine can steal secrets stored in this directory. This is because by default on unix-like operating systems the /temp
directory is shared between all users, so if the correct file permissions aren’t set by the directory/file creator, the file becomes readable by all other users on that system.
Workaround
This vulnerability can be fixed by explicitly setting the java.io.tmpdir
system property to a “safe” directory when starting the JVM.
Resolution
The resolution by the Google team was the following:
The team decided to document the behavior, as well as deprecate the method as other alternatives exist.
This completely makes sense to me, and I think is appropriate. The open question that exists in my mind is whether or not this issue warrants a CVE number issued.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:3
- Comments:64 (19 by maintainers)
Top GitHub Comments
A few options for you.
https://github.com/TNG/ArchUnit
Agreed.
A few suggestions for you:
The following two CodeQL queries would find all instances of this vulnerability across your codebases.
TempDirsUtil.qll
(This is a utility the two queries below depend upon)Query 1
Finds
Example of this query finding vulns against other Google projects: https://lgtm.com/query/7917272935407723538/
The above query will find method calls like this:
Query 2:
Example of this query finding vulns against other Google projects: https://lgtm.com/query/548722881855915017/
The above query will find instances of this vulnerability by doing dataflow analysis to find where uses of the system property flow to a file creation location.
With the GitHub Code Scanning feature, once my queries are merged, you’ll automatically get alerts about these vulnerabilities in your code. The pull request can be found here: https://github.com/github/codeql/pull/4388
You sometimes have to reload a few times. I have over 1,596 forks against my profile. I have a bot that I use to automate the generation of thousands of security-fix pull requests across GitHub projects. The first project I did this for, I forked all the projects under my personal account, I have since learned this is a mistake 😆 . Legit, do not do this. GitHub doesn’t scale well to having this many forks bound to your account. The second project, where I generated 3,880 pull requests, I realized that it was better for the health of my account if I forked them under organizations instead. I ended up creating 45 GitHub organizations for that project.