exploit the possibilities

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 metasploit.com

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="https://bugs.chromium.org/p/project-zero/issues/detail?id=220" title="" class="" rel="nofollow">https://bugs.chromium.org/p/project-zero/issues/detail?id=220</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

File Archive:

February 2019

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

Top Authors In Last 30 Days

File Tags


packet storm

© 2019 Packet Storm. All rights reserved.

Security Services
Hosting By