Bug 1245673 (CVE-2015-3255)

Summary: CVE-2015-3255 polkit: Heap-corruption on duplicate ids
Product: [Other] Security Response Reporter: Vasyl Kaigorodov <vkaigoro>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: meissner, mitr, sisharma, slawomir
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: 2015-11-09 06:04:36 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: 1233809    
Attachments:
Description Flags
0011-Fix-GHashTable-usage.patch none

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.