Bug 1245673 (CVE-2015-3255) - CVE-2015-3255 polkit: Heap-corruption on duplicate ids
Summary: CVE-2015-3255 polkit: Heap-corruption on duplicate ids
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2015-3255
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1233809
TreeView+ depends on / blocked
 
Reported: 2015-07-22 14:05 UTC by Vasyl Kaigorodov
Modified: 2019-09-29 13:35 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-09 06:04:36 UTC


Attachments (Terms of Use)
0011-Fix-GHashTable-usage.patch (2.52 KB, text/plain)
2015-07-22 14:06 UTC, Vasyl Kaigorodov
no flags Details

Description Vasyl Kaigorodov 2015-07-22 14:05:54 UTC
It was reported that if polkit, while reading action descriptions from /usr/share/polkit-1/actions, encounters a duplicate action ID, it corrupts the heap.
The effects of corruption are e.g. visible on stderr as frequent use of unrelated strings when running polkit without --no-debug.

Presumably a local attacker might be able to manipulate polkit’s heap enough to achieve privilege escalation through this.

Upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=83590
Upstream patch is attached.

Comment 1 Vasyl Kaigorodov 2015-07-22 14:06:39 UTC
Created attachment 1054865 [details]
0011-Fix-GHashTable-usage.patch

Comment 2 Marcus Meissner 2015-07-23 13:46:32 UTC
How is this a security issue?

Or is it due if the heap is corrupted that an attacker can work on top of that?

Comment 3 Miloslav Trmač 2015-07-23 13:57:21 UTC
Heap corruptions are, depending on your point of view, either not security issues until someone writes a worm, or security issues unless someone formally proves they are not exploitable.

(It may not be obvious from the patch: if a hash table contains [K1, V1], g_hash_table_insert(K2, V2) for K1 == K2 will actually store [K1, V2] into the hash table; but the way the old code worked, freeing V1 would also free K1, i.e. the hash table was pointing to freed memory for the key value.)

Comment 4 Tomas Hoger 2015-07-23 21:38:42 UTC
I guess the question was not whether heap corruptions are exploitable or not, but where / if trust boundary is crossed here.  Description implies that the problem occurs when configuration contains duplicate ids, so it does not seem seem attacker has ways to trigger this and that specific (mis-)configuration is required for this to happen.  Let's assume attacker is lucky and there is such configuration, can they take advantage of it?  Is K1 double-freed, or written to?

Comment 5 Marcus Meissner 2015-07-24 09:03:40 UTC
I think the idea is that due to a follow up of the heap corruption due to the misconfiguration , a specific access pattern in queries can lead to a different string placed the same place , that could be used then to bypass the rules.

tricky to exploit, but theoretically possible.

Comment 6 Miloslav Trmač 2015-07-24 14:23:33 UTC
Yeah, polkit clients have a fair amount of control over the number, sizes and contents of allocated strings.

And this specific misconfiguration happened to be shipped by default in some Fedora releases.


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