Bug 2484614 - ABRT abrt-dump-journal-core trusts spoofed systemd-coredump journal fields, allowing local root file disclosure [NEEDINFO]
Summary: ABRT abrt-dump-journal-core trusts spoofed systemd-coredump journal fields, a...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 44
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Michal Srb
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-06-04 05:14 UTC by Trung Nguyen
Modified: 2026-08-07 01:36 UTC (History)
3 users (show)

Fixed In Version: abrt-2.17.9-1.fc44 abrt-2.17.9-1.fc43
Clone Of:
Environment:
Last Closed: 2026-08-05 00:57:25 UTC
Type: ---
Embargoed:
trungnh: needinfo? (msrb)


Attachments (Terms of Use)
Full report and POC (11.52 KB, application/zip)
2026-06-04 05:16 UTC, Trung Nguyen
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.