Missing length checks in `hdrblobInit()` which may be able to cause memory unsafety.
Acknowledgments: Name: Demi M. Obenour
Created attachment 1757364 [details] Proposed patch provided by Demi M. Obenour.
Upstream PR: https://github.com/rpm-software-management/rpm/pull/1500
This only affects headerCheck(), which is only intended for and used on headers coming from the rpmdb by any of the standard tooling, and I'm not aware of any non-standard tooling using it either. A caller can of course toss any memory address at it (including a malicious header mmap()'ed from a package on disk) in which case the missing checks could hurt but that's not the expected usage. So to exploit this in practise, an attacker needs to be able to modify the rpmdb. At that point there are bigger problems.
Okay, this "affects" headerImport() in addition to headerCheck(), somehow missed/mixed that up. Not that it makes any particular difference for the severity: both are used on an in-memory serialized header, which only happens for packages coming from the rpmdb in the rpm stack (other arbitrary API users could do different things of course). I have to say I'm doubtful this is worth the fuss. Adding those checks upstream makes makes sense but beyond that it seems a bit meh: these API's are unsafe by design as they don't require caller to specify the blob size, and no amount of added checking will help with that. The limits imposed by the existing checks are completely arbitrary anyway, except perhaps for negative values and overflow, in which case ... I don't know what happens. Perhaps I should do some concrete testing with this.
Also you don't actually need any particular mitigation against this, normal package read/query/install etc are NOT affected. For this to affect standard tooling one needs to be able to directly manipulate the rpmdb contents, which requires root privileges. So a mitigation would essentially amount to: "Do not give root access to untrusted parties"... 3rd party / in-house software relying on these functions could be different, but there's little reason for anybody to use these on completely untrusted headers as headers do not wander around alone, they come in via packages and that route is covered by existing checks.
Created rpm tracking bugs for this issue: Affects: fedora-all [bug 1938022]
Statement: In order to exploit this flaw with rpm tooling as shipped in Red Hat Enterprise Linux, an attacker would need to already have root access to modify the rpm database.
Mitigation: If using the headerCheck() and headerImport() APIs in your software, do not run them on headers from untrusted sources.
As an addendum: one should always pass the blob size ("uc" argument) to both headerCheck() and headerImport() - when used this way, and uc is large enough to hold at least the header intro, both functions are quite safe. If 0 (for unknown) is used, there's simply no way to make it safe. For the same reason, one should not use the deprecated headerLoad(), headerCopyLoad() and headerUnload() interfaces.
Upstream patch: https://github.com/rpm-software-management/rpm/commit/8f4b3c3cab8922a2022b9e47c71f1ecf906077ef
FEDORA-2021-2383d950fd has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-8d52a8a999 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-662680e477 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
This was fixed in 4.16.1.3 already, but of course 4.17.0 will have it as well.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4489 https://access.redhat.com/errata/RHSA-2021:4489