Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2020-8908: Files::createTempDir local information disclosure vulnerability #4011

Open
JLLeitschuh opened this issue Sep 8, 2020 · 87 comments
Assignees
Labels

Comments

@JLLeitschuh
Copy link

JLLeitschuh commented Sep 8, 2020

IMPORTANT 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.

#4011 (comment)


Since the fix for this vulnerability is now disclosed by this commit (fec0dbc) 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.

@JLLeitschuh JLLeitschuh changed the title Files.::createTempDir local information disclosure vulnerability Files::createTempDir local information disclosure vulnerability Sep 8, 2020
@melloware
Copy link

melloware commented Sep 30, 2020

Yuck this code is being reported as a security vulnerability by Sonatype IQ Server as SONATYPE-2020-0926.

RECOMMENDATION
There is no non-vulnerable upgrade path for this component/package. We recommend investigating alternative components or replacing all usages of the deprecated Files.createTempDir() method with a safer alternative, such as java.nio.file.Files.createTempDirectory() for Java 7+.

I know its deprecated by why not just rip this code out?

It will be forever reported as a vulnerability by apps like OWASP and Sonatype.

@JLLeitschuh
Copy link
Author

Can someone from Google make an official statement on whether or not this issue will receive a CVE number or not?

@melloware
Copy link

And leaving the deprecated there is OK so people have Javadoc on alternatives but shouldn't it throw UnsupportedOperationException instead of just leaving this vulnerable code in here for someone to use?

@JLLeitschuh
Copy link
Author

JLLeitschuh commented Oct 1, 2020

@melloware, this is indeed a security vulnerability, however, given that the severity of this vulnerability is quite low, I think that the way that Google and the Guava team has handled this vulnerability with a documented depreciation is appropriate.

It's important to note that the JDK actually contains a method with a very similar vulnerability. You'll notice that the documentation on File.createTempFile method changed between Java 6 and Java 7.

This new line of documentation reads:

The Files.createTempFile method provides an alternative method to create an empty file in the temporary-file directory. Files created by that method may have more restrictive access permissions to files created by this method and so may be more suited to security-sensitive applications.

@melloware
Copy link

melloware commented Oct 1, 2020

I understand but its listed in Sonatype with a score of 7 which means my management team freaks out we are using a JAR with a vulnerability. Even if you prove to management you aren't using that feature it doesn't mean someone tomorrow in the org couldn't accidentally start using it. So that is why I am PRO on removal vs documentation.

When you work at a very security sensitive client who receives daily reports that include this type of alert.

image

@JLLeitschuh
Copy link
Author

A few options for you.

  1. Push back on Sonatype's analysis of this vulnerability. As a customer, if you think that your security vendor's analysis of a given vulnerability is rating the vuln as too high, then push back. Feel free to include me in the email thread. My email address can be found on my GitHub profile.
  2. Push back on management. Here's an ArchUnit test that you can add into your JUnit or TestNG tests that will verify that this method isn't used anywhere, thus preventing its from being used by someone tomorrow.

https://github.com/TNG/ArchUnit

@ArchTest
public static final ArchRule forbid_calls_to_guava_Files_createTempDir =
    classes()
        .should(not(callMethod(com.google.common.io.Files.class, "createTempDir")))
        .because("Files::createTempDir contains a local information disclosure vulnerability (https://github.com/google/guava/issues/4011)");

@melloware
Copy link

Cool I didn't know about ArchUnit!!! It won't help much we have over 50 in production applications using it so we would have to add this test to each one and all future applications.

As for your email when I click on your profile GitHub gives me the "Unicorn page is taking too long to load!"??? you must have a lot in your profile.

@JLLeitschuh
Copy link
Author

JLLeitschuh commented Oct 2, 2020

It won't help much we have over 50 in production applications using it so we would have to add this test to each one and all future applications.

Agreed.

A few suggestions for you:

  1. Create one Gradle build that pulls down all of the JAR artifacts from your different applications, load them all onto the classpath of that Gradle build, and run the check there. Sounds complicated, but it may not be if you publish all your jars to the same internal Sonatype instance.
  2. Something that may scale better is GitHub's Code Scanning feature. I'm a OSS Security researcher that contributes to the GitHub Security Lab Bug Bounty program. Your question here actually inspired me to finally write the queries below for my GitHub Security Lab Bug Bounty submission.

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)

import java
import semmle.code.java.dataflow.FlowSources

class MethodAccessSystemGetProperty extends MethodAccess {
  MethodAccessSystemGetProperty() {
    getMethod() instanceof MethodSystemGetProperty
  }

  predicate hasPropertyName(string propertyName) {
    this.getArgument(0).(CompileTimeConstantExpr).getStringValue() = propertyName
  }
}

class MethodAccessSystemGetPropertyTempDir extends MethodAccessSystemGetProperty {
  MethodAccessSystemGetPropertyTempDir() { this.hasPropertyName("java.io.tmpdir") }
}

/**
 * Find dataflow from the temp directory system property to the `File` constructor.
 * Examples:
 *  - `new File(System.getProperty("java.io.tmpdir"))`
 *  - `new File(new File(System.getProperty("java.io.tmpdir")), "/child")`
 */
private predicate isTaintedFileCreation(Expr expSource, Expr exprDest) {
  exists(ConstructorCall construtorCall |
    construtorCall.getConstructedType() instanceof TypeFile and
    construtorCall.getArgument(0) = expSource and
    construtorCall = exprDest
  )
}

private class TaintFollowingFileMethod extends Method {
  TaintFollowingFileMethod() {
    getDeclaringType() instanceof TypeFile and
    (
      hasName("getAbsoluteFile") or
      hasName("getCanonicalFile")
    )
  }
}

private predicate isTaintFollowingFileTransformation(Expr expSource, Expr exprDest) {
  exists(MethodAccess fileMethodAccess |
    fileMethodAccess.getMethod() instanceof TaintFollowingFileMethod and
    fileMethodAccess.getQualifier() = expSource and
    fileMethodAccess = exprDest
  )
}

predicate isAdditionalFileTaintStep(DataFlow::Node node1, DataFlow::Node node2) {
  isTaintedFileCreation(node1.asExpr(), node2.asExpr()) or
  isTaintFollowingFileTransformation(node1.asExpr(), node2.asExpr())
}

Query 1

Finds

/**
 * @name Temporary Directory Local information disclosure
 * @description Detect local information disclosure via the java temporary directory
 * @kind problem
 * @problem.severity warning
 * @precision very-high
 * @id java/local-information-disclosure
 * @tags security
 *       external/cwe/cwe-200
 */

import TempDirUtils

/**
 * All `java.io.File::createTempFile` methods.
 */
class MethodFileCreateTempFile extends Method {
  MethodFileCreateTempFile() {
    this.getDeclaringType() instanceof TypeFile and
    this.hasName("createTempFile")
  }
}

class TempDirSystemGetPropertyToAnyConfig extends TaintTracking::Configuration {
  TempDirSystemGetPropertyToAnyConfig() { this = "TempDirSystemGetPropertyToAnyConfig" }

  override predicate isSource(DataFlow::Node source) {
    source.asExpr() instanceof MethodAccessSystemGetPropertyTempDir
  }

  override predicate isSink(DataFlow::Node source) { any() }

  override predicate isAdditionalTaintStep(DataFlow::Node node1, DataFlow::Node node2) {
    isAdditionalFileTaintStep(node1, node2)
  }
}

abstract class MethodAccessInsecureFileCreation extends MethodAccess { }

/**
 * Insecure calls to `java.io.File::createTempFile`.
 */
class MethodAccessInsecureFileCreateTempFile extends MethodAccessInsecureFileCreation {
  MethodAccessInsecureFileCreateTempFile() {
    this.getMethod() instanceof MethodFileCreateTempFile and
    (
      this.getNumArgument() = 2 or
      getArgument(2) instanceof NullLiteral or
      // There exists a flow from the 'java.io.tmpdir' system property to this argument
      exists(TempDirSystemGetPropertyToAnyConfig config |
        config.hasFlowTo(DataFlow::exprNode(getArgument(2)))
      )
    )
  }
}

class MethodGuavaFilesCreateTempFile extends Method {
  MethodGuavaFilesCreateTempFile() {
    getDeclaringType().hasQualifiedName("com.google.common.io", "Files") and
    hasName("createTempDir")
  }
}

class MethodAccessInsecureGuavaFilesCreateTempFile extends MethodAccessInsecureFileCreation {
  MethodAccessInsecureGuavaFilesCreateTempFile() {
    getMethod() instanceof MethodGuavaFilesCreateTempFile
  }
}
from MethodAccessInsecureFileCreation methodAccess
select methodAccess,
  "Local information disclosure vulnerability due to use of file or directory readable by other local users."

Example of this query finding vulns against other Google projects: https://lgtm.com/query/7917272935407723538/

The above query will find method calls like this:

File.createTempFile("biz", "baz", null); // Flagged vulnerable
File.createTempFile("biz", "baz"); // Flagged vulnerable
com.google.common.io.Files.createTempDir(); // Flagged vulnerable
File tempDirChild = new File(new File(System.getProperty("java.io.tmpdir")), "/child"); // Not Flagged
File.createTempFile("random", "file", tempDirChild); // Flagged vulnerable

Query 2:

/**
 * @name Temporary Directory Local information disclosure
 * @description Detect local information disclosure via the java temporary directory
 * @kind path-problem
 * @problem.severity warning
 * @precision very-high
 * @id java/local-information-disclosure
 * @tags security
 *       external/cwe/cwe-200
 */

import TempDirUtils
import DataFlow::PathGraph

private class MethodFileSystemCreation extends Method {
  MethodFileSystemCreation() {
    getDeclaringType() instanceof TypeFile and
    (
      hasName("mkdir") or
      hasName("createNewFile")
    )
  }
}

private class TempDirSystemGetPropertyToCreateConfig extends TaintTracking::Configuration {
  TempDirSystemGetPropertyToCreateConfig() { this = "TempDirSystemGetPropertyToAnyConfig" }

  override predicate isSource(DataFlow::Node source) {
    source.asExpr() instanceof MethodAccessSystemGetPropertyTempDir
  }

  override predicate isSink(DataFlow::Node sink) {
    exists (MethodAccess ma |
      ma.getMethod() instanceof MethodFileSystemCreation and
      ma.getQualifier() = sink.asExpr()
    )
  }

  override predicate isAdditionalTaintStep(DataFlow::Node node1, DataFlow::Node node2) {
    isAdditionalFileTaintStep(node1, node2)
  }
}


from DataFlow::PathNode source, DataFlow::PathNode sink, TempDirSystemGetPropertyToCreateConfig conf
where conf.hasFlowPath(source, sink)
select source.getNode(), source, sink,
  "Local information disclosure vulnerability from $@ due to use of file or directory readable by other local users.", source.getNode(),
  "system temp directory"

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.

File tempDirChild = new File(System.getProperty("java.io.tmpdir"), "/child"); // Not flagged
tempDirChild.mkdir(); // Flagged vulnerable
tempDirChild.createNewFile(); // Flagged vulnerable

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: github/codeql#4388


As for your email when I click on your profile GitHub gives me the "Unicorn page is taking too long to load!"??? you must have a lot in your profile.

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.

@melloware
Copy link

@JLLeitschuh Than you for all your work! That GitHub bot code will be a huge help!

@semmalimayan
Copy link

@JLLeitschuh does the com.google.common.io.Files.createParentDirs() creates with similar vulnerable permissions ?

@JLLeitschuh
Copy link
Author

@semmalimayan here's the method you're asking about.

@Beta
public static void createParentDirs(File file) throws IOException {
checkNotNull(file);
File parent = file.getCanonicalFile().getParentFile();
if (parent == null) {
/*
* The given directory is a filesystem root. All zero of its ancestors exist. This doesn't
* mean that the root itself exists -- consider x:\ on a Windows machine without such a drive
* -- or even that the caller can create it, but this method makes no such guarantees even for
* non-root files.
*/
return;
}
parent.mkdirs();
if (!parent.isDirectory()) {
throw new IOException("Unable to create parent directories of " + file);
}
}

The true answer here is "it depends".

For example, this would be vulnerable:

File tempDirChild = new File(System.getProperty("java.io.tmpdir"), "/child/text_file.txt");
com.google.common.io.Files.createParentDirs(tempDirChild); // Anything in the 'child' directory would have a local information disclosure vulnerability 
tempDirChild.createNewFile(); // This file would be visible to other users, putting sensitive information in this file would be an information disclosure vulnerability.

That being said, I think that at that point, this is probably more likely a user-error vulnerability, less a guava vulnerability.

@JLLeitschuh
Copy link
Author

A similar vulnerability has been disclosed and patched in JUnit 4. CVE pending.

GHSA-269g-pwp5-87pp

To reiterate my earlier question:

Can someone from Google make an official statement on whether or not this issue will receive a CVE number or not?

CC: @google-admin

@melloware
Copy link

Here is the fix Junit did: junit-team/junit4@610155b#diff-25d902c24283ab8cfbac54dfa101ad31

drleff pushed a commit to Yeshiva-University-CS/COM2545StubbedAssignments that referenced this issue Oct 25, 2020
 Open	GitHub opened this alert 12 days ago
Bump junit from 4.11 to 4.13.1 in /SortDoublingRatios dependencies
1 junit:junit vulnerability found in SortDoublingRatios/pom.xml 12 days ago
Remediation
Upgrade junit:junit to version 4.13.1 or later. For example:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>[4.13.1,)</version>
</dependency>
Always verify the validity and compatibility of suggestions with your codebase.

Details
GHSA-269g-pwp5-87pp
low severity
Vulnerable versions: >= 4.7, < 4.13.1
Patched version: 4.13.1
Vulnerability
The JUnit4 test rule TemporaryFolder contains a local information disclosure vulnerability.

Example of vulnerable code:

public static class HasTempFolder {
    @rule
    public TemporaryFolder folder = new TemporaryFolder();

    @test
    public void testUsingTempFolder() throws IOException {
        folder.getRoot(); // Previous file permissions: `drwxr-xr-x`; After fix:`drwx------`
        File createdFile= folder.newFile("myfile.txt"); // unchanged/irrelevant file permissions
        File createdFolder= folder.newFolder("subfolder"); // unchanged/irrelevant file permissions
        // ...
    }
}
Impact
On Unix like systems, the system's temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system.

This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability.

When analyzing the impact of this vulnerability, here are the important questions to ask:

Do the JUnit tests write sensitive information, like API keys or passwords, into the temporary folder?
If yes, this vulnerability impacts you, but only if you also answer 'yes' to question 2.
If no, this vulnerability does not impact you.
Do the JUnit tests ever execute in an environment where the OS has other untrusted users.
This may apply in CI/CD environments but normally won't be 'yes' for personal developer machines.
If yes, and you answered 'yes' to question 1, this vulnerability impacts you.
If no, this vulnerability does not impact you.
Patches
Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using.

Java 1.7 and higher users: this vulnerability is fixed in 4.13.1.
Java 1.6 and lower users: no patch is available, you must use the workaround below.
Workarounds
If you are unable to patch, or are stuck running on Java 1.6, specifying the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability.

References
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Fix commit junit-team/junit4@610155b
Similar Vulnerabilities
Google Guava - google/guava#4011
Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945
JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
For more information
If you have any questions or comments about this advisory, please pen an issue in junit-team/junit4.
openwms added a commit to spring-labs/org.openwms.services that referenced this issue Oct 25, 2020
OLEGSHA added a commit to OLEGSHA/Progressia that referenced this issue Nov 5, 2020
Relevant info: google/guava#4011. We never
used it but better prevent this in the future.
melloware added a commit to melloware/guava that referenced this issue Nov 19, 2020
@JLLeitschuh
Copy link
Author

JLLeitschuh commented Mar 3, 2023

It's my intention to run a campaign to bulk generate PRs across all OSS to fix this vulnerability (by replacing the method's use with the new java std lib Files variant).

That should significantly decrease the likelihood that this vulnerability will impact you via a transitive dependency.

If you're curious and want to do the same across your corporate repositories, this is the OpenRewrite recipe to automate making this change:

https://github.com/openrewrite/rewrite-migrate-java/blob/f104cb19305fa18b3faa3b929f10765691da8fb9/src/main/java/org/openrewrite/java/migrate/guava/NoGuavaCreateTempDir.java

@norrisjeremy
Copy link

Hi @JLLeitschuh,

That's great...
But wouldn't it be a whole lot simpler if Google simply stepped up and actually remediated the issue in Guava itself?
Doesn't seem like it would be especially difficult to just not create a world readable directory in the first place.

Thanks,
Jeremy

@JLLeitschuh
Copy link
Author

But wouldn't it be a whole lot simpler if Google simply stepped up and actually remediated the issue in Guava itself?

I mean, absolutely, yes. But that ship may have sailed. I tried to convince them to fix this without any luck 3 years ago. 🤷‍♂️

@arjopoldervaart
Copy link

If it has been 3 years since the code was deprecated, now seems to be a good time to remove it.

We also use the OWASP dependency checker and it is now breaking all the builds that pull in guava. We hardly ever use the library directly so we would need to inspect the library that pulls it in to see if we can safely ignore the CVE. This is not something I would like to spend my time on. Just blindly ignoring it is also not an option. I would support a new attempt to convince Google to remove the code.

@cpovirk
Copy link
Member

cpovirk commented Mar 6, 2023

@nick-someone was just OOO but will be getting back and may have thoughts.

I gather from the many recent posts (#4011 (comment), #4011 (comment), #4011 (comment), #4011 (comment)), as well as from https://stackoverflow.com/q/75615883/28465, that more tools have begun reporting this lately.

And, as suggested just above, anyone who actually wants the current functionality has been getting deprecation warnings since version 30.0 (released almost 2.5 years ago), so even a project that is slow to upgrade has probably heard of this by now (perhaps because of, you know, the build breakages...).

A quick recap, since I can't remember if we gave a good summary of the situation 3 years ago: We can't change the behavior to be secure because Java didn't provide a secure API for this until Java 7, and we support versions of Android that are old enough not to offer Java 7 APIs. That leaves us with a set of options that all can cause problems for someone: remove the method (and break existing users), make the method work only under JVMs and new versions of Android (and make it do no nothing (and log?) or throw under old versions of Android), or deprecate the method in place (and have some number of tools report warnings).

Our call at the time was that deprecating was the least costly way forward. But as various tools move to consider deprecation to be insufficient, and as existing users of the method have more time to find alternatives, that shifts the relative costs and benefits.

I still don't know exactly what that will mean for the future, but I think enough has changed that it makes sense for us to give this some focused attention again.

@JLLeitschuh
Copy link
Author

and we support versions of Android that are old enough not to offer Java 7 APIs

You can use reflection to secure Java 7+ version usage though, correct? Also, regardless of version, the following two methods have been available since Java 6:

I think you can call each on the file in sequence like this to lock it down before returning it:

// Make the file readable by no user
tempFile.setReadable(false, false);
// Then only make it readable to the owner
tempFile.setReadable(true, true);

Of course, the better solution on java 7+ is to explicitly use the posix permissions setting APIs offered on Files.

I still don't know exactly what that will mean for the future, but I think enough has changed that it makes sense for us to give this some focused attention again.

🎉

@cpovirk
Copy link
Member

cpovirk commented Mar 6, 2023

Right, we could use reflection. However, the code has to do something under Android versions under which the methods aren't available, so we'd be back to either breaking the method under those versions or leaving it insecure under those versions, and I don't think I can predict whether the latter would be enough to get tools to stop reporting a vulnerability.

As for setReadable, there would still be a window during which the directory is accessible. And it turns out to be possible (at least under Linux) for someone to open that directory during that window and then use that open file descriptor(?) to read even files that are created after the directory was made unreadable to that user. (I may have a demonstration of this in the form of some snippets of Java lying around somewhere.... I'll see if I can dig it up.) That's not to say that the change wouldn't help, just that it might not be enough to get tools to stop reporting a vulnerability, either.

@cpovirk
Copy link
Member

cpovirk commented Mar 6, 2023

I found the hacked-up Guava code that I used to demo the race [edited to change to a Gist]. The end of the file shows a transcript of the race in action.

@norrisjeremy
Copy link

Why all the consternation for a method that is flagged as @Beta?

Signifies that a public API (public class, method or field) is subject to incompatible changes, or even removal, in a future release.
An API bearing this annotation is exempt from any compatibility guarantees made by its containing library.
Note that the presence of this annotation implies nothing about the quality or performance of the API in question, only the fact that it is not "API-frozen."

@JLLeitschuh
Copy link
Author

I found the hacked-up Guava code that I used to demo the race. The end of the file shows a transcript of the race in action.

Nifty! Mind throwing that into a GitHub Gist instead? Would be far more readable. But I appreciate what you're pointing out here 🤔

@cpovirk
Copy link
Member

cpovirk commented Mar 6, 2023

Ah, yes, that would be smarter:

https://gist.github.com/cpovirk/3aa1e9accb44c35f967175b237c6e1fb

Don't worry, though: It's still plenty unreadable, since the methods are named things like "deleteDirectoryContentsSecure" (from the code I copied to create the demo) :)

@JLLeitschuh
Copy link
Author

JLLeitschuh commented Mar 6, 2023

You've just me to inspired 🐰 🕳️ (rabbit hole), thanks 😆

I had some previous cases of this vulnerability in some other projects that I had previously believed were safe, but actually aren't because of this information 😬. There may be a few other CVEs to come out of this. Thanks! 😆

https://unix.stackexchange.com/questions/631766/can-i-get-unix-file-permissions-to-take-effect-immediately-for-all-processes

@JLLeitschuh
Copy link
Author

What if you create the directory in a user-controlled directory, ensure the permissions are set correctly, then move it into the temporary directory?

@cpovirk
Copy link
Member

cpovirk commented Mar 6, 2023

That sounds to me like it ought to work, but I am not at all an expert in this area. Certainly I am always more comfortable pointing out a specific problem with an approach than I am with claiming that an approach is definitely safe :)

Fishbowler added a commit to Fishbowler/Openfire that referenced this issue Mar 19, 2023
Guava has vulnerability related to permissions on a temp directory (google/guava#4011) but we don't use that method. This wasn't flagged by the previous version of dependency-check-maven, as it'd been assumed fixed in Guava.
guusdk pushed a commit to igniterealtime/Openfire that referenced this issue Mar 21, 2023
Guava has vulnerability related to permissions on a temp directory (google/guava#4011) but we don't use that method. This wasn't flagged by the previous version of dependency-check-maven, as it'd been assumed fixed in Guava.
lhotari added a commit to lhotari/pulsar that referenced this issue Apr 4, 2023
- The vulnerable method is deprecated in Guava, but isn't removed. It's necessary to suppress this CVE.
  See google/guava#4011
@cpovirk cpovirk assigned cpovirk and unassigned nick-someone Apr 5, 2023
guusdk pushed a commit to igniterealtime/Openfire that referenced this issue May 15, 2023
Guava has vulnerability related to permissions on a temp directory (google/guava#4011) but we don't use that method. This wasn't flagged by the previous version of dependency-check-maven, as it'd been assumed fixed in Guava.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests