Librepo fails to sanitize paths in the 'repomd.xml' configuration file. Malformed or malicious repository metadata could allow a remote attacker to copy files outside of the destination directory via path traversal. Considering that DNF runs as root, this flaw could potentially result in system compromise via arbitrary file overwriting of critical system files.
Could you provide more details about the vulnerability that would help us to reproduce and narrow down the problem? Are there any logs or reports we should be aware of? Is the person who discovered this problem able to share more details incl. pointers to the suspicious code? Is there a reproducer?
The flaw lies in prepare_repo_download_std_target() and prepare_repo_download_zck_target() in yum.c: -> https://github.com/rpm-software-management/librepo/blob/master/librepo/yum.c#L673 -> https://github.com/rpm-software-management/librepo/blob/master/librepo/yum.c#L706 The code concatenates 'handle->destdir' and 'record->location_href' without properly validating the latter, which means a malformed location such as "../../../../" could allow overwriting of arbitrary files stored on the file system. I'm working on a reproducer for this issue, will post additional comments to let you know. N.B., if I'm not mistaken the version of librepo in RHEL-7 did not include the aforementioned functions, though the same vulnerable lr_pathconcat()/open() can be found in prepare_repo_download_targets(). That's why I consider RHEL-7 to be affected too.
Statement: This issue is rated as having Moderate impact on Red Hat Enterprise Linux 7 because `DNF` is not installed by default. The `DNF` package is available through the Extras channel as an enhancement to YUM 3. Both Fedora and Red Hat Enterprise Linux leverage transport security and package signatures to ship software to their users in a safe way. Fedora provides a centralized, non-mirrored Fedora-run metalink service which provides a list if active mirrors and the expected cryptographic digest of the `repomd.xml` files. yum uses this information to select a mirror and verify that it serves the up-to-date, untampered `repomd.xml`. The chain of cryptographic digests is verified from there, eventually leading to verification of the .rpm file contents. Red Hat uses a different option to distribute Red Hat Enterprise Linux and its RPM-based products: a content-distribution network, managed by a trusted third party. Furthermore, the repositories provided by Red Hat use a separate public key infrastructure which is managed by Red Hat. For further information, refer to the following articles. [1] https://access.redhat.com/blogs/766093/posts/1976693 [2] https://access.redhat.com/articles/1373143
YUM 3 is not affected by this issue. As mentioned above, the DNF package (YUM 4) is shipped in RHEL-7 via the Extras channel. It's worth noting that the version of librepo in RHEL-7 does not allow file overwriting with arbitrary content; the targeted file ends up being overwritten with an empty file. This is most probably due to the O_TRUNC file status flag: https://github.com/rpm-software-management/librepo/blob/1.8.1/librepo/yum.c#L577.
Mitigation: Avoid downloading software from untrusted third-party mirrors. Note that under normal circumstances, this flaw does not pose any threat to Red Hat users, as repositories are fully trusted and controlled by Red Hat.
Acknowledgments: Name: Sergei Iudin <siudin>
Created librepo tracking bugs for this issue: Affects: fedora-all [bug 1868639]
Upstream fix: https://github.com/rpm-software-management/librepo/commit/7daea2a2429a54dad68b1de9b37a5f65c5cf2600
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:3658 https://access.redhat.com/errata/RHSA-2020:3658
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-14352
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Extended Update Support Via RHSA-2020:3749 https://access.redhat.com/errata/RHSA-2020:3749
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.0 Update Services for SAP Solutions Via RHSA-2020:3756 https://access.redhat.com/errata/RHSA-2020:3756
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:5012 https://access.redhat.com/errata/RHSA-2020:5012