Author

James Forshaw

Risk

[

Security Risk Critical

]

0day-ID

0day-ID-28134

Category

remote exploits

Date add

14-07-2017

CVE

CVE-2017-0298

Platform

windows

Windows: Bad Fix for COM Session Moniker EoP 

CVE-2017-0298


Windows: Bad Fix for COM Session Moniker EoP

So....

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 
  && (imp_token_il >= SECURITY_MANDATORY_HIGH_RID 
  || 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.

#  0day.today [2024-11-16]  #