Google researcher team contacted Microsoft regarding the bug on the same day as the flaw was discovered but there are no indications of any action being taken in the matter Forshaw has also stated in the mailing list that he has tested the PoC only on 8.1 and doesnt know whether Windows 7 is vulnerable. The vulnerability is identified in the function ahcache.sys/AhcVerifyAdminContext. The proof of concept includes two program files and a set of instructions for executing it which result in the Windows calculator running as Administrator. Forshaw states that the bug is not in UAC itself, but that UAC is used in part to demonstrate the bug. Microsoft has big problem on hand with this vulnerability as it releases its main patches on the second Tuesday of the month. As of now Microsoft has two choices :
Fix it in time for the second patch tuesday. Issue an out-of-band patch (usually a bad sign of 0day).
The next Patch Tuesday is due on 13.1.2015 and if releases a patch before that, it can be assumed that this is a Zero day vulnerability. The entire thread is reproduced below : Another user has claimed that Windows 10 is not vulnerable to this vulnerability while another has question the Google policy of making such a bug public without Microsoft’s approval. The Thread and PoC can be accessed here. On Windows 8.1 update the system call NtApphelpCacheControl (the code is actually in ahcache.sys) allows application compatibility data to be cached for quick reuse when new processes are created. A normal user can query the cache but cannot add new cached entries as the operation is restricted to administrators. This is checked in the function AhcVerifyAdminContext. This function has a vulnerability where it doesn’t correctly check the impersonation token of the caller to determine if the user is an administrator. It reads the caller’s impersonation token using PsReferenceImpersonationToken and then does a comparison between the user SID in the token to LocalSystem’s SID. It doesn’t check the impersonation level of the token so it’s possible to get an identify token on your thread from a local system process and bypass this check. For this purpose the PoC abuses the BITS service and COM to get the impersonation token but there are probably other ways. It is just then a case of finding a way to exploit the vulnerability. In the PoC a cache entry is made for an UAC auto-elevate executable (say ComputerDefaults.exe) and sets up the cache to point to the app compat entry for regsvr32 which forces a RedirectExe shim to reload regsvr32.exe. However any executable could be used, the trick would be finding a suitable pre-existing app compat configuration to abuse. It’s unclear if Windows 7 is vulnerable as the code path for update has a TCB privilege check on it (although it looks like depending on the flags this might be bypassable). No effort has been made to verify it on Windows 7. NOTE: This is not a bug in UAC, it is just using UAC auto elevation for demonstration purposes. The PoC has been tested on Windows 8.1 update, both 32 bit and 64 bit versions. I’d recommend running on 32 bit just to be sure. To verify perform the following steps:
- Put the AppCompatCache.exe and Testdll.dll on disk 2) Ensure that UAC is enabled, the current user is a split-token admin and the UAC setting is the default (no prompt for specific executables). 3) Execute AppCompatCache from the command prompt with the command line “AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll”. 4) If successful then the calculator should appear running as an administrator. If it doesn’t work first time (and you get the ComputerDefaults program) re-run the exploit from 3, there seems to be a caching/timing issue sometimes on first run. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.
