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.
Created attachment 1054865 [details] 0011-Fix-GHashTable-usage.patch
How is this a security issue? Or is it due if the heap is corrupted that an attacker can work on top of that?
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.)
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?
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.
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.