Microsoft Windows Kernel – Registry Hive Loading Relative Arbitrary Read in nt!RtlValidRelativeSecurityDescriptor (MS16-123)
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=876 We have encountered a Windows kernel crash in the nt!RtlValidRelativeSecurityDescriptor function invoked by nt!CmpValidateHiveSecurityDescriptors while loading corrupted registry hive files. An example of a crash log excerpt generated after triggering the bug is shown below: --- KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e) 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. Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but ... If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is happening. Arguments: Arg1: c0000005, The exception code that was not handled Arg2: 81815974, The address that the exception occurred at Arg3: 80795644, Trap Frame Arg4: 00000000 Debugging Details: ------------------ [...] STACK_TEXT: 807956c4 81814994 a4f3f098 0125ffff 00000000 nt!RtlValidRelativeSecurityDescriptor+0x5b 807956fc 818146ad 03010001 80795728 80795718 nt!CmpValidateHiveSecurityDescriptors+0x24b 8079573c 8181708f 03010001 80000560 80000540 nt!CmCheckRegistry+0xd8 80795798 817eafa0 80795828 00000002 00000000 nt!CmpInitializeHive+0x55c 8079585c 817ebd85 80795bb8 00000000 807959f4 nt!CmpInitHiveFromFile+0x1be 807959c0 817f3aae 80795bb8 80795a88 80795a0c nt!CmpCmdHiveOpen+0x50 80795acc 817ec3b8 80795b90 80795bb8 00000010 nt!CmLoadKey+0x459 80795c0c 81682dc6 002afc90 00000000 00000010 nt!NtLoadKeyEx+0x56c 80795c0c 77066bf4 002afc90 00000000 00000010 nt!KiSystemServicePostCall WARNING: Frame IP not in any known module. Following frames may be wrong. 002afcf8 00000000 00000000 00000000 00000000 0x77066bf4 [...] FOLLOWUP_IP: nt!RtlValidRelativeSecurityDescriptor+5b 81815974 803801 cmp byte ptr [eax],1 --- The bug seems to be caused by insufficient verification of the security descriptor length passed to the nt!RtlValidRelativeSecurityDescriptor function. An inadequately large length can render the verification of any further offsets useless, which is what happens in this particular instance. Even though the nt!RtlpValidateSDOffsetAndSize function is called to sanitize each offset in the descriptor used to access memory, it returns success due to operating on falsely large size. This condition can be leveraged to get the kernel to dereference any address relative to the pool allocation, which may lead to system crash or disclosure of kernel-mode memory. We have not investigated if the bug may allow out-of-bounds memory write access, but if that is the case, its severity would be further elevated. The issue reproduces on Windows 7 and 8.1. In order to reproduce the problem with the provided sample, it is necessary to load it with a dedicated program which calls the RegLoadAppKey() API. Attached is a proof of concept hive file. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40601.zip |