Twenty Year Anniversary

Microsoft Windows COM Session Moniker Privilege Escalation

Microsoft Windows COM Session Moniker Privilege Escalation
Posted Jul 14, 2017
Authored by James Forshaw, Google Security Research | Site

Microsoft Windows has a bad fix for the COM session moniker that can allow for elevation of privilege.

tags | advisory
systems | windows
advisories | CVE-2017-0298
MD5 | 3415ad73c8d69869f7f6b54856151c87

Microsoft Windows COM Session Moniker Privilege Escalation

Change Mirror Download
Windows: Bad Fix for COM Session Moniker EoP 


Windows: Bad Fix for COM Session Moniker EoP


The previous fix for CVE-2017-0100 sounds wrong on the face of it. Rather than fixing the underlying Session creation bug you "fixed" the HxHelpPane class. Even if this was a correct fix ultimately it just requires you to find an alternative COM object to abuse.

However looking at the fix in HelpPane.exe you can see that the fix isn't actually sufficient. The bug is in the check.

if ( imp_token_il >= process_token_il
|| EqualSid(process_token_user, imp_token_user)))
ShellExecuteW(NULL, L"open", path, NULL, NULL, SW_SHOW);

This first checks if the impersonation token IL is < process token IL which is to prevent a sandbox escape. However we then get a new check, it will also fail if the process user is not the same as the impersonation user AND the impersonation token IL is < High. This is the problem. IL is not generally considered much of a security boundary as it doesn't indicate a user is an administrator, it just indicates that user has a High IL.

Confused? Well one case where a user will gain an elevated IL is in UAC elevation. While administrators will get High IL so will UI Access programs. Unfortunately UI access programs are easy for a normal user to hijack (in the general case). For example <a href="" title="" class="" rel="nofollow"></a> was never fixed down level so Windows 7 and 8.X are vulnerable to a normal user being able to get trivial UI access execution (and by extension Win2008 and 2012 servers). Even on Windows 10 where this is fixed (AFAIK) there's still alternative ways of getting UI access execution through DosDevices abuse to hijack DLL loading of a valid UI access binary.

Now of course you only get High IL when running as a split token admin (which means there's ways to just get admin on those machines anyway) but for a normal user you only get Medium + 16. However I'd draw your attention to comment 4 in the previously linked report. You can ratchet the IL up in 16 byte increments if you control the process as the logic of UI access elevation is it will increase IL if UI access is not enabled on the token. As turning off UI access is a non-privileged operation (though setting to true is privileged) then you can spawn the UI access process, turn off UI access in the token then respawn adding another 16 to the IL until you reach High IL. It's just case of doing this through whatever means are available.

Perhaps this is just due to trying to avoid some compatibility issue I don't know about, or just represents a misunderstanding of Windows security. Either way it really should probably bypass the user check only if the token has the administrators group. Ideally you'd fix the session issue itself, but that is clearly too hard a task.

Also before you say this is a UAC bypass, just don't even start on that. I warned you about this sort of behavior with things like UI access and the IL ratchet before and you ignored it.

I've not provided a PoC as imo the bug is self evident. I've proven it myself manually, at least on Windows 7. If you _really_ need me to prove it with a PoC I will.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.

Found by: forshaw


RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

Want To Donate?

Bitcoin: 18PFeCVLwpmaBuQqd5xAYZ8bZdvbyEWMmU

File Archive:

June 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    14 Files
  • 2
    Jun 2nd
    1 Files
  • 3
    Jun 3rd
    3 Files
  • 4
    Jun 4th
    18 Files
  • 5
    Jun 5th
    21 Files
  • 6
    Jun 6th
    8 Files
  • 7
    Jun 7th
    16 Files
  • 8
    Jun 8th
    18 Files
  • 9
    Jun 9th
    5 Files
  • 10
    Jun 10th
    2 Files
  • 11
    Jun 11th
    21 Files
  • 12
    Jun 12th
    32 Files
  • 13
    Jun 13th
    15 Files
  • 14
    Jun 14th
    16 Files
  • 15
    Jun 15th
    4 Files
  • 16
    Jun 16th
    1 Files
  • 17
    Jun 17th
    2 Files
  • 18
    Jun 18th
    14 Files
  • 19
    Jun 19th
    0 Files
  • 20
    Jun 20th
    0 Files
  • 21
    Jun 21st
    0 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    0 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2018 Packet Storm. All rights reserved.

Security Services
Hosting By