Bug 1927741 (CVE-2021-20266) - CVE-2021-20266 rpm: missing length checks in hdrblobInit()
Summary: CVE-2021-20266 rpm: missing length checks in hdrblobInit()
Keywords:
Status: NEW
Alias: CVE-2021-20266
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1929445 1929446 1938022
Blocks: 1912449
TreeView+ depends on / blocked
 
Reported: 2021-02-11 13:09 UTC by msiddiqu
Modified: 2021-04-27 06:54 UTC (History)
12 users (show)

Fixed In Version: rpm 4.17.0
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in RPM’s hdrblobInit() in lib/header.c. This flaw allows an attacker who can modify the rpmdb to cause an out-of-bounds read. The highest threat from this vulnerability is to system availability.
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
Proposed patch provided by Demi M. Obenour. (1.89 KB, patch)
2021-02-16 22:55 UTC, Todd Cullum
no flags Details | Diff

Description msiddiqu 2021-02-11 13:09:42 UTC
Missing length checks in `hdrblobInit()` which may be able to cause memory unsafety.

Comment 1 msiddiqu 2021-02-11 13:09:45 UTC
Acknowledgments:

Name: Demi M. Obenour

Comment 3 Todd Cullum 2021-02-16 22:55:50 UTC
Created attachment 1757364 [details]
Proposed patch provided by Demi M. Obenour.

Comment 5 Todd Cullum 2021-02-18 19:30:47 UTC
Upstream PR: https://github.com/rpm-software-management/rpm/pull/1500

Comment 7 Panu Matilainen 2021-02-24 08:12:23 UTC
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.

Comment 10 Panu Matilainen 2021-03-09 09:51:10 UTC
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.

Comment 11 Panu Matilainen 2021-03-09 10:09:35 UTC
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.

Comment 12 Todd Cullum 2021-03-11 23:02:57 UTC
Created rpm tracking bugs for this issue:

Affects: fedora-all [bug 1938022]

Comment 13 Todd Cullum 2021-03-12 19:25:04 UTC
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.

Comment 14 Todd Cullum 2021-03-12 19:25:05 UTC
Mitigation:

If using the headerCheck() and headerImport() APIs in your software, do not run them on headers from untrusted sources.

Comment 15 Panu Matilainen 2021-03-15 10:17:24 UTC
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.

Comment 17 Fedora Update System 2021-03-30 00:15:38 UTC
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.

Comment 18 Fedora Update System 2021-03-30 01:10:14 UTC
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.

Comment 19 Fedora Update System 2021-04-07 15:25:38 UTC
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.

Comment 20 Panu Matilainen 2021-04-27 06:54:16 UTC
This was fixed in 4.16.1.3 already, but of course 4.17.0 will have it as well.


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