A flaw was found in ansible-collection-redhat-leapp. An attacker with privileged write access to a managed node's Leapp report content can manipulate it. When an operator runs a specific remediation task, this manipulated report can cause the Ansible controller to read its own local files and copy them to the managed node. This vulnerability leads to information disclosure, potentially exposing sensitive controller-side data such as private keys or credentials.

AIONLYREPORT package: ansible-collection-redhat-leapp-1.7.4-1.el102 ------ Summary: Controller-to-Node Information Disclosure via Leapp Report Tampering: attacker-controlled Leapp report content on a managed node can cause controller-local files to be read during remediation and copied back to that managed node. Requirements to exploit: An attacker needs privileged write access to the managed node's Leapp report content, or equivalent control over the remediation hint data consumed from that report, and an operator must run remediation that includes leappcorruptedgrubenvfile. Component affected: ansible-collection-redhat-leapp, specifically the remediation flow in roles/remediate/tasks/leappcorruptedgrubenvfile.yml reached from roles/remediate/tasks/main.yml Version affected: ansible-collection-redhat-leapp-1.7.4-1.el102 when the remediation role is executed against a managed node whose Leapp report content can be modified by an attacker Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N - 6.2 (MEDIUM) AV:N - exploitation uses the normal network path between the Ansible controller and managed node. AC:L - once the report content is attacker-controlled, exploitation only requires supplying a chosen path in the remediation context. PR:H - modifying the expected Leapp report on the managed node appears to require high privileges there, or equivalent control over that report content. UI:R - an operator must run the remediation workflow after the malicious report content is in place. S:C - managed-node-controlled input causes the controller to read a controller-local file and send it back to the node, crossing a trust boundary. C:H - sensitive controller files such as private keys or credentials may be disclosed. I:N - the established issue is file disclosure rather than unauthorized modification. A:N - the available evidence does not show a direct availability impact. Impact: Moderate. Based on Red Hat's severity guidance, this issue can expose confidential controller-side data, but exploitation depends on a compromised or equivalently privileged managed node and operator-triggered remediation. Those preconditions make the issue materially harder to exploit than an Important issue, even though the resulting disclosure can be high value. Embargo: no Reason: the issue is Moderate severity, requires prior compromise or equivalent privileged access on the managed node, and has straightforward mitigations in deployment and code. Acknowledgement: Aisle Research Vulnerability Details: The remediation logic extracts file paths from report-controlled remediation context and then passes those paths to ansible.builtin.copy as src without remotesrc: true. In Ansible, copy.src is controller-side by default. Because the Leapp report is first read from the managed node and parsed into remediation data, a malicious managed node can influence which controller-local file is read. yaml filesgrub: >- {{ (leappinhibitorremediationhint.context | regexfindall(leappinhibitorhintpattern, ' 1') | first).split(',') map('trim') list }} name: leappcorruptedgrubenvfile | Backup file(s) ansible.builtin.copy: src: "{{ item }}" dest: "{{ item }}.backup" mode: "0644" withitems: "{{ filesgrub }}"

The report data consumed by this task comes from the managed node: yaml name: Read leapp report ansible.builtin.slurp: src: "{{ leappreportlocation }}" ...

name: Parse leapp report ansible.builtin.setfact: leappreportdata: "{{ leappreportcontent.content | b64decode | fromjson }}"

This remediation is reachable through the inhibitor mappings below: yaml "Detected a corrupted grubenv file": leappcorruptedgrubenvfile f32345b6140b5a318c1c01e1cbc6ef1c0321e04a: leappcorruptedgrubenvfile In practical terms, if the remediation hint context is changed to reference a controller-local path such as /root/.ssh/idrsa, the backup task may attempt to read that file from the controller and write it to the managed node as {{ item }}.backup. Based on the available evidence, this is an information disclosure issue across the controller-to-node trust boundary. The evidence does not establish direct code execution. Steps to reproduce: 1. On a test managed node, create or modify /var/log/leapp/leapp-report.json so it contains an entry with key f32345b6140b5a318c1c01e1cbc6ef1c0321e04a and remediation hint context Delete /root/.ssh/idrsa file. 2. Run remediation with leappremediationtodo including leappcorruptedgrubenvfile. 3. Execute the remediation role or playbook from the controller. 4. Observe that leappcorruptedgrubenvfile | Backup file(s) attempts to use /root/.ssh/idrsa as src on the controller and writes /root/.ssh/idrsa.backup on the managed node. Mitigation: Until fixed, avoid running this remediation against hosts whose Leapp report content cannot be trusted. As a local hardening measure, treat the backup source as remote by setting remotesrc: true and constrain accepted paths to the expected /boot subtree before using them. Proposed Fix: The remediation should both restrict accepted paths to the expected boot-related locations and force the copy source to be resolved on the managed node. diff diff --git a/roles/remediate/tasks/leappcorruptedgrubenvfile.yml b/roles/remediate/tasks/leappcorruptedgrubenvfile.yml @@ filesgrub: >- {{ (leappinhibitorremediationhint.context | regexfindall(leappinhibitorhintpattern, ' 1') | first).split(',') map('trim') + select('match', '^/boot(/ $)') list }} @@ name: leappcorruptedgrubenvfile

Backup file(s) ansible.builtin.copy: src: "{{ item }}" dest: "{{ item }}.backup" mode: "0644" + remotesrc: true withitems: "{{ filesgrub }}" @@ name: leappcorruptedgrubenvfile

Backup grub.cfg file ansible.builtin.copy: src: "{{ grubcfgpath.stdout }}" dest: "{{ grubcfgpath.stdout }}.backup" mode: "0644" + remotesrc: true ------ This report was generated using AI technology. Always review AI-generated content prior to use