Security scan reported problem with com.google.common.io.FileBackedOutputStream

[venusjain10]

We are using google commons APIs in our project and security scan on our code has reported following problem. Could you please let me know if this is of any concern or it can be fixed in new version of this API.

Problem: Creating and using insecure temporary files can leave application and system data vulnerable to attack. In particular,file names created by the tmpnam family of functions can be easily guessed by an attacker. If an attacker can predictthe filename and create a malicious collision, he may be able to manipulate the behavior of the application.

Recommendations (Generated by tool)
Ensure that unpredictable names are used for temporary files and that files are created in a secure directory with appropriate permissions. Using mkstemp() is a reasonably safe way to create temporary files. It will attempt to create and open a unique file based on a filename template provided by the user, combined with a series of randomly generated characters. Note that mkstemp() is safe if only the descriptor is used and the returned filename is not used in a subsequent function call with extra privileges. Using mkstemp() does not completely eliminate race conditions but does provide better protection than other methods

Class:
com.google.common.io.FileBackedOutputStream

[lowasser]

This seems like it could at least conceivably be a problem if, and only if, you used FileBackedOutputStream. Do you?

[abhisheksharma43]

I have not used the class FileBackedOutputStream directly. However I am not sure if the classes that we have used from the API internally use FileBackedOutputStream.

[cpovirk]

I have a request in for a CVE for this, which is fundamentally the same as #4011. The just-merged fix will be part of the next release, hopefully to be published tomorrow.

[cpovirk]

(We have the number CVE-2023-2976 reserved, but it's not posted yet.)

[Horcrux7]

The CVE-2023-2976 match also to the version 32.0.0. Is it fixed and the CVE version match is wrong or will it fix in the next version?

[pwagland]

SonaType also flags this CVE as being present in 32.0.0, despite the release notes saying the release fixes CVE-2023-2976.

Basically what do we need to do:

1. Wait for upstream to fix their data, or
2. Suppress this CVE, since we don't use these classes anyway, or
3. Wait for a new fix, aka 32.0.1?

Trying not to just say "me too", I hope this is additional useful information.

[malfoj89]

yesteday it was okay - today it matches 32.0.0 any comment on that?

[cpovirk]

Thanks for the reports. I'd welcome any help in figuring this out on #6532.

[feilimb]

Can I ask if Windows 10 users are affected by this vulnerability, I am not entirely clear from reading of this issue whether this is related to Unix / Android OS only, or whether Windows users are also affected.

[cpovirk]

First, I should emphasize that almost no app uses FileBackedOutputStream. And if an app doesn't use it, then it's not affected.

If an app does use it, then my understanding is that the app is still safe under Windows because Windows gives each user a private temporary directory:

• Files#createTempDir stopped working on Windows with 32.0.0 #6535 (comment)
• Files#createTempDir stopped working on Windows with 32.0.0 #6535 (comment)

So, as best I understand, the problem is restricted to the cases laid out in CVE-2023-2976:

• Linux systems whose temporary directory might be accessible to people you don't want to see your FileBackedOutputStream data. We made this case secure in new Guava versions.
• Android Ice Cream Sandwich. That version is so old that probably no one is it, so we broke FileBackedOutputStream entirely in new Guava versions.

[feilimb]

@cpovirk Many thanks for the clarification Chris, that makes sense now and it is good to know that Windows is not affected.