Bug 800531
| Summary: | D-Bus: hash table collisions CPU usage DoS | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Kurt Seifried <kseifried> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | carnil, ebenes, rhughes, security-response-team, stefw, walters |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-10-19 21:51:53 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: | |||
| Bug Blocks: | 770929, 802685 | ||
There doesn't appear to be many (any?) ways to inject data easily to trigger this vulnerability. Statement: The Red Hat Security Response Team has rated this issue as having Low to no security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/. |
Similar to the denial of service flaw present in various programming languages' hash function usage, a potential flaw was found in the dbus implementation (specifically in the DBusHashTable() function): A specially-crafted set of keys could trigger hash function collisions, which degrade dictionary performance by changing hash table operations complexity from an expected/average O(1) to the worst case O(n). Please note that this level of access requires both local access to the system and the ability to send specific types of dbus messages (e.g. service activiation names) in order to trigger this vulnerability and cause high CPU utilization resulting in a possible DoS. DBus uses the following code to permute data in dbus-hash.c: /* * Takes a preliminary integer hash value and produces an index into a * hash tables bucket list. The idea is to make it so that * preliminary values that are arbitrarily similar will end up in * different buckets. The hash function was taken from a * random-number generator. (This is used to hash integers.) * * The down_shift drops off the high bits of the hash index, and * decreases as we increase the number of hash buckets (to keep more * range in the hash index). The mask also strips high bits and strips * fewer high bits as the number of hash buckets increases. * I don't understand two things: why is the initial downshift 28 * to keep 4 bits when the initial mask is 011 to keep 2 bits, * and why do we have both a mask and a downshift? */ #define RANDOM_INDEX(table, i) \ (((((long) (i))*1103515245) >> (table)->down_shift) & (table)->mask) The Red Hat Security Response Team has rated this issue as having low security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.