Bug 1866498 (CVE-2020-14352)
| Summary: | CVE-2020-14352 librepo: missing path validation in repomd.xml may lead to directory traversal | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Mauro Matteo Cascella <mcascell> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | amatej, davide, dmach, jberan, jrohel, lberton, mblaha, mvanderw, packaging-team-maint, pkratoch, rpm-software-management, security-response-team, tmlcoch |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | librepo 1.12.1 | Doc Type: | If docs needed, set a value |
| Doc Text: |
A flaw was found in librepo. A directory traversal vulnerability was found where it failed to sanitize paths in remote repository metadata. An attacker controlling a remote repository may be able to copy files outside of the destination directory on the targeted system via path traversal. This flaw could potentially result in system compromise via the overwriting of critical system files. The highest threat from this flaw is to users that make use of untrusted third-party repositories.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-09-08 13:19:44 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: | |||
| Bug Depends On: | 1866500, 1866501, 1866502, 1866503, 1866504, 1866505, 1868639 | ||
| Bug Blocks: | 1864106 | ||
|
Description
Mauro Matteo Cascella
2020-08-05 18:04:02 UTC
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 |