Open derekbruening opened 9 years ago
NtApphelpCacheControl has never had a UNICODE_STRING for the second parameter. The API definition has never changed but the structure for the second parameter has changed significantly between versions of Windows.
XP, Vista, 7, 8 and 10 all share the same definition:
NTSYSCALLAPI
NTSTATUS
NtApphelpCacheControl (
_In_ AHC_SERVICE_CLASS ServiceClass,
_Inout_opt_ PVOID ServiceContext
);
I dont know about the structres for earlier versions of Windows but for Windows 10 you can install the Windows 10 WDK and view the following header: "C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\minwin\ahcache.h"
On Windows 10, NtApphelpCacheControl's 2nd parameter is clearly not PUNICODE_STRING as we have it listed. In the past we put little effort into this as most instances of this syscall we've seen pass NULL. It sounds like the 2nd param is very complex and varies across Windows versions and maybe across enum values (1st param).
For now we may just want to mark it UNKNOWN and let the unknown-syscall code try to figure out what's written by the kernel, at least.
False positive on Win10
Xref #1669
Shouldn't that match the blacklist? OK, the test passes -lib_blacklist_frames 0. We could add this to the default supp list. But our syscall def seems wrong: that is not a UNICODE_STRING (see below). I put in a suppression to at least avoid the false pos in 348ba7e.
Analysis: not a UNICODE_STRING
The 0x1f is hardcoded here:
The old Metasploit had this as PUNICODE_STRING. ReactOS has it as PVOID.
Further info
Xref James Forshaw's vulnerability research: https://code.google.com/p/google-security-research/issues/detail?id=118
Xref https://translate.google.co.uk/translate?hl=en&sl=zh-CN&u=http://blogs.360.cn/blog/ntapphelpcachecontrol_vulnerability_anaysis/&prev=search