CVE-2023-2976
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Google Guava is a widely used set of core Java libraries providing utilities for collections, caching, concurrency, hashing, I/O operations, and other common programming needs. One utility class within Guava, FileBackedOutputStream, helps manage data that spills over from memory to disk during output operations.
A security vulnerability (CVE-2023-2976) has been identified in Google Guava. The issue arises from the use of Java’s default temporary directory for file creation without appropriate access control. Because these temporary files may be created in world-accessible locations, other users or apps with access to the system’s default Java temporary directory can read or manipulate the files. Applications relying on FileBackedOutputStream for sensitive data handling may therefore inadvertently expose information if running in shared environments.
Per OWASP: Incorrect Permission Assignment for Critical Resource occurs when a resource is given a permission setting that provides access to a wider range of actors than required, it could lead to the exposure of sensitive information, or the modification of that resource by unintended parties. This is especially dangerous when the resource is related to program configuration, execution, or sensitive user data.
This issue affects multiple versions of Google Guava guava.
Details
Module Info
- Product: Google Guava
- Affected packages: guava
- Affected versions: <32.0.0
- GitHub repository: https://github.com/google/guava
- Published packages: https://central.sonatype.com/namespace/com.google.guava
- Package manager: Maven
- Fixed In: NES for Google Guava
Vulnerability Info
This medium-to-high severity vulnerability is found in the FileBackedOutputStream component of the Google Guava library in all versions prior to the fix. Guava’s implementation uses Java’s default temporary directory (typically defined by java.io.tmpdir) to store intermediate data when an output stream exceeds its in-memory threshold.
On Unix-like operating systems, the default temporary directory is often accessible to multiple users or processes. When an application uses this functionality to handle sensitive data, other local users or applications with access to the same temporary directory can locate, open, and read (and potentially modify) the temporary files created by FileBackedOutputStream. This can lead to unauthorized information disclosure or interference with application behavior.
Steps To Reproduce
- Build or use a Java application that depends on Google Guava and that creates a FileBackedOutputStream instance to write data exceeding its in-memory buffer.
- Run the application on a Unix-like system where multiple users or applications share the default Java temporary directory (java.io.tmpdir).
- Trigger the output stream to exceed its in-memory threshold so that it spills to disk, creating a temporary file in the default temporary directory.
- From a different local user account or application with access to the temporary directory, locate and read the temporary file created by the vulnerable FileBackedOutputStream instance. In affected versions, these files are readable due to insecure temporary directory placement.
Proof Of Concept
On a vulnerable system, an attacker or another local user can list and open temporary files under the default Java temporary directory created by a process using the vulnerable FileBackedOutputStream. Because the files are created in a shared temporary space with default permissions, the attacker does not need elevated privileges beyond access to the same system user environment. Successfully reading the contents of such files demonstrates how sensitive data intended for temporary use by the application can be exposed to unauthorized local parties.
Mitigation
Only recent versions of Google Guava are community-supported. Only the recent community supported version will receive updates to address this issue. For more information, see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade affected applications to supported versions of Google Guava.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
Credit
- Chris Povirk