CVE-2015-3142 in Automatic Bug Reporting Tool
Summary
by MITRE
The kernel-invoked coredump processor in Automatic Bug Reporting Tool (ABRT) does not properly check the ownership of files before writing core dumps to them, which allows local users to obtain sensitive information by leveraging write permissions to the working directory of a crashed application.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 12/09/2022
The vulnerability identified as CVE-2015-3142 resides within the Automatic Bug Reporting Tool (ABRT) kernel-invoked coredump processor, representing a critical security flaw that undermines the integrity of core dump handling mechanisms. This issue specifically affects systems where ABRT is configured to process core dumps generated by kernel crash events, creating a potential attack vector for local privilege escalation and information disclosure. The flaw manifests when ABRT attempts to write core dump files to locations within the working directory of crashed applications, failing to validate file ownership permissions before proceeding with the write operation. This oversight creates a scenario where malicious local users can manipulate the core dump writing process to access sensitive data from other users' processes.
The technical implementation of this vulnerability stems from insufficient input validation within ABRT's core dump processing logic, specifically in how it handles file system operations during crash reporting. When a kernel-generated crash occurs, ABRT's coredump processor attempts to write the core dump file to a location specified by the crashed application's working directory. The flaw occurs because the processor does not perform proper ownership checks on the target file or directory before writing the core dump data. This design weakness allows a local attacker with write permissions to the application's working directory to create or modify files in a manner that can expose sensitive information contained within core dumps. The vulnerability operates under CWE-276, which classifies improper file permissions as a fundamental security flaw, and aligns with ATT&CK technique T1059.001 for command and scripting interpreter execution.
The operational impact of CVE-2015-3142 extends beyond simple information disclosure, as it can enable attackers to extract sensitive data from memory segments of other processes, potentially including authentication tokens, cryptographic keys, or confidential application data. This vulnerability is particularly concerning in multi-user environments where different users share the same system resources, as it allows for cross-user data access without requiring elevated privileges. Attackers can exploit this weakness by first identifying applications running in the target user's context, then manipulating the working directory permissions to intercept and read core dump data containing sensitive information. The vulnerability effectively undermines the principle of least privilege by allowing local users to bypass normal file access controls and extract information from processes they should not have access to.
Mitigation strategies for CVE-2015-3142 should focus on both immediate system hardening and long-term architectural improvements to ABRT's core dump handling procedures. System administrators should ensure that ABRT is properly configured with strict file ownership checks and that core dump directories are appropriately secured with restrictive permissions. The recommended approach involves implementing proper file system access controls that prevent unauthorized write operations to critical application directories, while also ensuring that ABRT components are updated to versions that include proper ownership verification mechanisms. Additionally, organizations should consider implementing monitoring solutions that can detect anomalous core dump creation patterns and unauthorized file access attempts. The vulnerability demonstrates the importance of proper privilege separation in system components and highlights the need for comprehensive security testing of crash handling mechanisms to prevent similar issues from arising in other security-critical software components.