Bug 2484614

Summary: ABRT abrt-dump-journal-core trusts spoofed systemd-coredump journal fields, allowing local root file disclosure
Product: [Fedora] Fedora Reporter: Trung Nguyen <trungnh>
Component: abrtAssignee: Michal Srb <msrb>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 44CC: abrt-devel-list, abrt-sig, msrb
Target Milestone: ---Keywords: Desktop, Security
Target Release: ---Flags: trungnh: needinfo? (msrb)
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: abrt-2.17.9-1.fc44 abrt-2.17.9-1.fc43 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2026-08-05 00:57:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Full report and POC none

Description Trung Nguyen 2026-06-04 05:14:58 UTC
On fully updated Fedora 44, a low-privileged local user can spoof a native journald entry that matches `abrt-dump-journal-core` as if it came from `systemd-coredump`. ABRT then trusts attacker-controlled `COREDUMP_FILENAME` and `COREDUMP_UID` fields. The root `abrt-dump-journal-core` service copies the path from `COREDUMP_FILENAME` into a new ABRT problem as the `coredump` element, and `org.freedesktop.Problems2.GetProblemData()` returns that element to the attacker because the attacker also controls the saved `uid` element.

This gives a low-privileged local user a root file disclosure primitive. In the lab, a file owned by `root:root`, mode `0600`, under `/root` was recovered through ABRT by user `fedtest`.

Additional validation showed that the primitive is not limited to extensionless files. ABRT stores files with extensions as `coredump.<extension>`, and those elements are also returned to the attacker. Using this, `fedtest` recovered high-value root-only files including SSH host private keys, cloud-init sensitive instance data, and Azure Linux Agent private material under `/var/lib/waagent`. The recovered files had the same size and SHA-256 hash as the original root-only files.

In an Azure Fedora VM lab, the impact extends beyond generic file disclosure. The low-privileged user recovered `TransportPrivate.pem`, `TransportCert.pem`, and `Certificates.p7m` from `/var/lib/waagent`, then used the recovered transport credential to decrypt `Certificates.p7m` into a PKCS#12 bundle containing a certificate and private key. This demonstrates host and cloud-agent secret compromise from a local unprivileged account.

The lab was originally in SELinux Permissive mode. A follow-up control test temporarily switched SELinux to Enforcing. In Enforcing mode, `/etc/shadow` was blocked by policy, but the Azure Linux Agent private key under `/var/lib/waagent/*.prv` was still recovered with a matching SHA-256 hash because the file is labeled `var_lib_t`. Therefore, the exact set of readable files depends on SELinux type policy, but cloud-agent secret disclosure is confirmed even under Enforcing in this Azure Fedora lab.

Please check the details report and POC at the below link
https://drive.google.com/file/d/11-kQfYS_ZALC94ikoWZ0UQvpgJ0fAv-2/view?usp=sharing

Reproducible: Always

Comment 1 Trung Nguyen 2026-06-04 05:16:04 UTC
Created attachment 2144095 [details]
Full report and POC

Comment 2 Trung Nguyen 2026-06-04 05:19:42 UTC
This is a security issue, but I'm not sure how to restrict access to it. It appears the issue is currently posted publicly, if possible, could a mod/admin please adjust the visibility?

Comment 3 Michal Srb 2026-06-05 06:02:42 UTC
Thank you for the bug report, Trung! I will take a look ;)

Comment 4 Trung Nguyen 2026-06-15 16:36:25 UTC
@Michal Srb Have you checked the finding?

Comment 5 Trung Nguyen 2026-07-30 05:17:54 UTC
Hello, 

Any updates on this?

Comment 6 Fedora Update System 2026-08-03 11:40:49 UTC
FEDORA-2026-a7417466a1 (abrt-2.17.9-1.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-a7417466a1

Comment 7 Fedora Update System 2026-08-03 12:14:03 UTC
FEDORA-2026-cccf5985b5 (abrt-2.17.9-1.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-cccf5985b5

Comment 8 Trung Nguyen 2026-08-03 17:15:29 UTC
@msrb as I understand, this is not considered as a security finding and is not assigned a CVE ID?

Comment 9 Fedora Update System 2026-08-04 01:41:27 UTC
FEDORA-2026-a7417466a1 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-a7417466a1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-a7417466a1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Fedora Update System 2026-08-04 02:00:13 UTC
FEDORA-2026-cccf5985b5 has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-cccf5985b5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-cccf5985b5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2026-08-05 00:57:25 UTC
FEDORA-2026-a7417466a1 (abrt-2.17.9-1.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 12 Fedora Update System 2026-08-07 01:36:56 UTC
FEDORA-2026-cccf5985b5 (abrt-2.17.9-1.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.