Guest User

Untitled

a guest
Dec 23rd, 2014
367
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Cisco Blog > Security > Threat Research
  2. MS14-063 A Potential XP Exploit
  3. Talos Group
  4. Talos Group | December 1, 2014 at 2:01 am PST
  5. (3 Comments)
  6.  
  7. This post was written by Marcin Noga with contributions by Earl Carter and Martin Lee.
  8.  
  9. New vulnerabilities for old operating systems may not seem particularly interesting, until you consider the large number of legacy machines running outdated versions of Windows. Windows XP has reached its end of life, meaning that new vulnerabilities will not be patched. In this post we will show that a recent vulnerability can be used as a platform for exploiting Windows XP.
  10.  
  11. In October, Microsoft released a bulletin for a privilege escalation vulnerability in the FASTFAT driver that was released as:
  12.  
  13. MS14-063 — Vulnerability in FAT32 Disk Partition Driver Could Allow Elevation of Privilege (2998579), CVE-2014-4115.
  14.  
  15. Let me present some of the most interesting parts of the advisory and add some details from my own research.
  16.  
  17. When the bug kicks in…
  18.  
  19. In the advisory, Microsoft indicates that the following OS’s are vulnerable:
  20.  
  21. Microsoft Windows Server 2003 SP2
  22. Vista SP2
  23. Server 2008 SP2
  24.  
  25. The Microsoft bulletin does not mention Windows XP, since Windows XP is no longer supported. According to my research, however, this vulnerability is also present in the Windows XP FASTFAT driver.
  26.  
  27. See the following video.
  28.  
  29. This vulnerability can be exploited on Windows XP SP3 using a malicious usb stick with a malformed FAT32 partition. Let’s examine the reaction when the USB is inserted into the system.
  30.  
  31. General description
  32.  
  33. Vulnerable code existing in the FastFAT.sys driver can be exploited via an intentionally malformed FAT32 Boot sector delivered through a USB flash drive. If the field “Number of FATs” contains a value greater than 2, the driver will allocate insufficient memory. Further actions made by FastFAT.sys driver will then cause a pool overflow.
  34.  
  35.  
  36.  
  37. How it happens — code analysis
  38.  
  39. The following is an example of a malformed FAT32 Boot Sector. The “Number of FATs” field is set to 119 (0x77 in hex), instead of the normal value of 2, making the boot sector malformed.
  40.  
  41.  
  42.  
  43. Member "Value (dec)" "Value (hex)" Size
  44.  
  45. " 00000000 struct BOOTSECTOR_FAT32" {...} 00000200
  46.  
  47. " 00000000 int8 jmp[00000003]" 00000003
  48.  
  49. " 00000003 char OemName[00000008]" MSDOS5.0 00000008
  50.  
  51. " 0000000B struct BPB_FAT32" {...} 00000035
  52.  
  53. " 0000000B uint16 BytesPerSector" 512 0200 00000002
  54.  
  55. " 0000000D int8 SectorsPerCluster" 1 01 00000001
  56.  
  57. " 0000000E uint16 ReservedSectors" 36 0024 00000002
  58.  
  59. " 00000010 int8 NumberOfFATs" 119 77 00000001
  60.  
  61. " 00000011 uint16 RootEntries" 0 0000 00000002
  62.  
  63. " 00000013 uint16 TotalSectors" 0 0000 00000002
  64.  
  65. " 00000015 int8 Media" -8 F8 00000001
  66.  
  67. " 00000016 uint16 SectorsPerFAT" 0 0000 00000002
  68.  
  69. " 00000018 uint16 SectorsPerTrack" 63 003F 00000002
  70.  
  71. " 0000001A uint16 HeadsPerCylinder" 255 00FF 00000002
  72.  
  73. " 0000001C uint32 HiddenSectors" 63 0000003F 00000004
  74.  
  75. " 00000020 uint32 TotalSectorsBig" 80262 00013986 00000004
  76.  
  77. "++ FAT32 Section
  78.  
  79. " 00000024 uint32 SectorsPerFAT" 618 0000026A 00000004
  80.  
  81. " 00000028 uint16 Flags" 0 0000 00000002
  82.  
  83. " 0000002A uint16 Version" 0 0000 00000002
  84.  
  85. " 0000002C uint32 RootCluster" 2 00000002 00000004
  86.  
  87. " 00000030 uint16 InfoSector" 1 0001 00000002
  88.  
  89. " 00000032 uint16 BootBackupStart" 6 0006 00000002
  90.  
  91. " 00000034 int8 Reserved[0000000C]" 0000000C
  92.  
  93. " 00000040 int8 DriveNumber" -128 80 00000001
  94.  
  95. " 00000041 int8 Unused" 1 01 00000001
  96.  
  97. " 00000042 int8 ExtBootSignature" 41 29 00000001
  98.  
  99. " 00000043 uint32 SerialNumber" 3896654535 E8423AC7 00000004
  100.  
  101. " 00000047 char VolumeLabel[0000000B]" "NO NAME " 0000000B
  102.  
  103. " 00000052 char FileSystem[00000008]" "FAT32 " 00000008
  104.  
  105. " 0000005A blob BootCode[000001A6]" 000001A6
  106.  
  107.  
  108.  
  109. Memory corruption is a common driver problem. Activation of a special pool will help us to locate the moment when a pool overflow starts to appear
  110.  
  111. verifier /volatile /flags 0x1 /adddriver fastfat.sys
  112.  
  113. After insertion of USB flash drive with a malformed FAT32 we can examine the crash dump that occurs due to insufficient memory allocation.
  114.  
  115.  
  116.  
  117. Crash dump info
  118.  
  119. kd> !analyze -v
  120. DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6)
  121. N bytes of memory was allocated and more than N bytes are being referenced.
  122. This cannot be protected by try-except.
  123. When possible, the guilty driver’s name (Unicode string) is printed on
  124. the bugcheck screen and saved in KiBugCheckDriver.
  125. Arguments:
  126. Arg1: 8a011008, memory referenced
  127. Arg2: 00000001, value 0 = read operation, 1 = write operation
  128. Arg3: b7ae63da, if non-zero, the address which referenced memory.
  129. Arg4: 00000000, (reserved)
  130.  
  131. Debugging Details:
  132. ------------------
  133. WRITE_ADDRESS: 8a011008 Special pool
  134.  
  135. FAULTING_IP:
  136. Fastfat!FatCommonWrite+444
  137. b7ae63da 8978fc mov dword ptr [eax-4],edi
  138.  
  139. MM_INTERNAL_CODE: 0
  140. IMAGE_NAME: Fastfat.SYS
  141. DEBUG_FLR_IMAGE_TIMESTAMP: 48025b94
  142. MODULE_NAME: Fastfat
  143. FAULTING_MODULE: b7ada000 Fastfat
  144. DEFAULT_BUCKET_ID: DRIVER_FAULT
  145. BUGCHECK_STR: 0xD6
  146. PROCESS_NAME: System
  147.  
  148. TRAP_FRAME: bacdf8c0 -- (.trap 0xffffffffbacdf8c0)
  149. ErrCode = 00000002
  150. eax=8a01100c ebx=8a7ece90 ecx=00186c00 edx=00000800 esi=89a14b18 edi=00004800
  151. eip=b7ae63da esp=bacdf934 ebp=bacdfab4 iopl=0 nv up ei ng nz ac pe cy
  152. cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010297
  153. Fastfat!FatCommonWrite+0x444:
  154. b7ae63da 8978fc mov dword ptr [eax-4],edi ds:0023:8a011008=????????
  155. Resetting default scope
  156.  
  157. LAST_CONTROL_TRANSFER: from 8051cc4f to 804f8cb5
  158.  
  159. STACK_TEXT:
  160. bacdf848 8051cc4f 00000050 8a011008 00000001 nt!KeBugCheckEx+0x1b
  161. bacdf8a8 8054051c 00000001 8a011008 00000000 nt!MmAccessFault+0x8e7
  162. bacdf8a8 b7ae63da 00000001 8a011008 00000000 nt!KiTrap0E+0xcc
  163. bacdfab4 b7adab9a 89a14b18 8a7ece90 89c59020 Fastfat!FatCommonWrite+0x444
  164. bacdfaf8 804ee119 89c59020 8a7ece90 806d12a4 Fastfat!FatFsdWrite+0xad
  165. bacdfb08 8064d628 89ada170 00004000 89c59020 nt!IopfCallDriver+0x31
  166. bacdfb2c 804ef411 bacdfb68 bacdfd40 00000000 nt!IovCallDriver+0xa0
  167. bacdfb40 8050c497 89ada107 bacdfb68 bacdfbfc nt!IoSynchronousPageWrite+0xaf
  168. bacdfc24 8050ce3d e10ec820 e10ec828 e10ec828 nt!MiFlushSectionInternal+0x3bf
  169. bacdfc60 804e38a2 89c33d70 e10ec820 00000004 nt!MmFlushSection+0x1b5
  170. bacdfce8 804e3bc4 00001000 00000000 00000001 nt!CcFlushCache+0x386
  171. bacdfd2c 804e61ee 89da0290 8055b0c0 89da1da8 nt!CcWriteBehind+0xdc
  172. bacdfd74 80534c02 89da0290 00000000 89da1da8 nt!CcWorkerThread+0x126
  173. bacdfdac 805c6160 89da0290 00000000 00000000 nt!ExpWorkerThread+0x100
  174. bacdfddc 80541dd2 80534b02 00000000 00000000 nt!PspSystemThreadStartup+0x34
  175. 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
  176.  
  177. STACK_COMMAND: kb
  178.  
  179. FOLLOWUP_IP:
  180. Fastfat!FatCommonWrite+444
  181. b7ae63da 8978fc mov dword ptr [eax-4],edi
  182.  
  183. SYMBOL_STACK_INDEX: 3
  184. SYMBOL_NAME: Fastfat!FatCommonWrite+444
  185. FOLLOWUP_NAME: MachineOwner
  186. FAILURE_BUCKET_ID: 0xD6_VRF_Fastfat!FatCommonWrite+444
  187. BUCKET_ID: 0xD6_VRF_Fastfat!FatCommonWrite+444
  188. Followup: MachineOwner
  189.  
  190.  
  191.  
  192. Detailed analysis
  193.  
  194. To help debug driver memory issues, you can enable the special pool feature. This feature causes each memory allocation to be placed on a separate page. With the special pool active for fastfat.sys, you should begin executing the following when the overflow occurs,:
  195.  
  196. PAGE:0001C37A movzx edx, word ptr [eax+90h]
  197.  
  198. PAGE:0001C381 movzx ecx, cx
  199.  
  200. PAGE:0001C384 imul edx, ecx
  201.  
  202. PAGE:0001C387 mov [ebp+BytesPerFat], edx
  203.  
  204. PAGE:0001C38D
  205.  
  206. PAGE:0001C38D loc_1C38D:
  207.  
  208. PAGE:0001C38D mov cl, [eax+96h]
  209.  
  210. PAGE:0001C393 cmp cl, 2 ; cl = Number of FATs
  211.  
  212. PAGE:0001C396 jbe short RegularFATsAmount
  213.  
  214. PAGE:0001C398 push 'itaF' ; Tag
  215.  
  216. PAGE:0001C39D movzx eax, cl
  217.  
  218. PAGE:0001C3A0 push eax ; Number of FATs used as pool size
  219.  
  220. PAGE:0001C3A1 push 11h ; PoolType
  221.  
  222. PAGE:0001C3A3 call ds:__imp__ExAllocatePoolWithTag
  223.  
  224. PAGE:0001C3A9 mov edi, eax
  225.  
  226. PAGE:0001C3AB mov eax, [ebp+VCB]
  227.  
  228. PAGE:0001C3AE jmp short loc_1C3B6
  229.  
  230. PAGE:0001C3B0 ; ------------------------------------------------------------------
  231.  
  232. PAGE:0001C3B0
  233.  
  234. PAGE:0001C3B0 RegularFATsAmount:
  235.  
  236. PAGE:0001C3B0 lea edi, [ebp+var_174]
  237.  
  238. PAGE:0001C3B6
  239.  
  240. PAGE:0001C3B6 loc_1C3B6:
  241.  
  242. PAGE:0001C3B6 mov [ebp+unknow], edi
  243.  
  244. PAGE:0001C3BC and [ebp+counter], 0
  245.  
  246. PAGE:0001C3C3 cmp byte ptr [eax+96h], 0
  247.  
  248. PAGE:0001C3CA jbe short loc_1C410
  249.  
  250. PAGE:0001C3CC mov ecx, [ebp+offsetToFirstFAT]
  251.  
  252. PAGE:0001C3CF mov edx, ecx
  253.  
  254. PAGE:0001C3D1 sub edx, [ebp+StartingVbo]
  255.  
  256. PAGE:0001C3D4 lea eax, [edi+0Ch]
  257.  
  258. PAGE:0001C3D7
  259.  
  260. PAGE:0001C3D7 fillArrayLoop:
  261.  
  262. PAGE:0001C3D7 mov edi, [ebp+offsetToFirstFAT]
  263.  
  264. PAGE:0001C3DA mov [eax-4], edi
  265.  
  266. PAGE:0001C3DD mov [eax-0Ch], ecx
  267.  
  268. PAGE:0001C3E0 and dword ptr [eax-8], 0
  269.  
  270. PAGE:0001C3E4 mov [eax], edx
  271.  
  272. PAGE:0001C3E6 mov edi, [ebp+unknow3]
  273.  
  274. PAGE:0001C3EC mov [eax+4], edi
  275.  
  276. PAGE:0001C3EF inc [ebp+counter]
  277.  
  278. PAGE:0001C3F5 add ecx, [ebp+BytesPerFat]
  279.  
  280. PAGE:0001C3FB add eax, 18h
  281.  
  282. PAGE:0001C3FE mov edi, [ebp+VCB]
  283.  
  284. PAGE:0001C401 movzx edi, byte ptr [edi+96h] ; to EDI goes Number of FATs
  285.  
  286. PAGE:0001C408 cmp [ebp+counter], edi
  287.  
  288. PAGE:0001C40E jb short fillArrayLoop
  289.  
  290.  
  291.  
  292. Note: When the number of FATs is bigger than 2, the pool allocated is simply the number of FATs (instead of the number of FATs times size of a FAT entry)
  293.  
  294. PAGE:0001C39D movzx eax, cl
  295.  
  296. PAGE:0001C3A0 push eax ; Number of FATs used as pool size
  297.  
  298. PAGE:0001C3A1 push 11h ; PoolType
  299.  
  300. PAGE:0001C3A3 call ds:__imp__ExAllocatePoolWithTag
  301.  
  302.  
  303.  
  304. The Next loop appears and it iterates the number of times indicated by the number of FATs. In this loop, labeled as fillArrayLoop, the pool allocated by the code describe above is filled by an array of structures where the size of the structure equals 24 bytes (each structure consists of 6 DWORD’s). It Is easy to deduce that the iteration will lead to a pool overflow because during the pool allocation, the number of FATs was taken into account without including the size of structure element. It’s even easier to understand on pseudo code:
  305.  
  306. NumberOfFATs = *(_BYTE *)(VCB + 150);
  307. if ( NumberOfFATs <= 2u )
  308. {
  309. ptrPool = &v100;
  310. }
  311. else
  312. {
  313. ptrPool = ExAllocatePoolWithTag((POOL_TYPE)17, NumberOfFATs, 'itaF');
  314. [BUG]//NumberOfFATs !!! instead of NumberOfFATs * sizeof(SomeStructure)=24
  315. v14 = VCB;
  316. }
  317. counter = 0;
  318. if ( *(_BYTE *)(v14 + 0x96) )
  319. {
  320. v18 = offsetToFirstFAT;
  321. unknow1 = offsetToFirstFAT - unknow2;
  322. v20 = (int)((char *)ptrPool + 12);
  323. do
  324. {
  325. *(_DWORD *)(v20 - 4) = offsetToFirstFAT;
  326. *(_DWORD *)(v20 - 12) = v18;
  327. *(_DWORD *)(v20 - 8) = 0;
  328. *(_DWORD *)v20 = unknow1;
  329. *(_DWORD *)(v20 + 4) = unknow3;
  330. ++counter;
  331. v18 += BytesPerFat;
  332. v20 += 24;
  333. }
  334. while ( counter < NumberOfFATs );
  335. }
  336.  
  337.  
  338.  
  339. Exploitability
  340.  
  341. After three iterations of the loop cycle, here is how this array looks in memory:
  342.  
  343. #1
  344.  
  345. 00 48 00 00
  346.  
  347. 00 00 00 00
  348.  
  349. 00 48 00 00
  350.  
  351. 00 08 00 00
  352.  
  353. 00 02 00 00
  354.  
  355. ef ef ef ef <- not initialized
  356.  
  357. #2
  358.  
  359. 00 1c 05 00
  360.  
  361. 00 00 00 00
  362.  
  363. 00 48 00 00
  364.  
  365. 00 08 00 00
  366.  
  367. 00 02 00 00
  368.  
  369. ef ef ef ef <- not initialized
  370.  
  371. #3
  372.  
  373. 00 f0 09 00
  374.  
  375. 00 00 00 00
  376.  
  377. 00 48 00 00
  378.  
  379. 00 08 00 00
  380.  
  381. 00 02 00 00
  382.  
  383. ef ef ef ef <- not initialized
  384.  
  385.  
  386.  
  387. Which values at a particular offset are we able to control ?
  388.  
  389. Offset +0: (v20 -- 12)
  390.  
  391. For the first iteration it’s value equals offsetToFirstFAT and is the result of adding:
  392.  
  393. (v20 -- 12) = (v20 -- 12) + BytesPerFat.
  394.  
  395. Note: BytesPerFAT equals : Bytes per sector(= 512) * Sectors per fat(= 618) == 0x4D400
  396.  
  397. (316416)
  398.  
  399. Offset +4: (v20 -- 8)
  400.  
  401. Constant 0
  402.  
  403. Offset + 8: (v20 -- 4)
  404.  
  405. The value of this field always equals offsetToFirstFAT.
  406.  
  407. Note: offsetToFirstFAT : Bytes per sector * Reserved sectors == (0x4800)
  408.  
  409.  
  410.  
  411. Taking into account the information about how this bug is triggered and what portion of data we are able to control during page overflow this vulnerability appears to be hard to exploit. The most lucrative scenario for attacker would be to create a malformed FAT32 partition (that does not cause crashes after usb stick insertion) which contains an executable file with the possibility for the victim to run it.
  412.  
  413. When run, this executable, for example, would be responsible for kernel pool spraying. After that it would write any random data to the malformed partition, triggering at the same time the bug in FatCommonWrite. My observations show that when you create a nearly empty malformed partition containing a couple files, the bug only triggers when you open one of these files and try to save (write) modifications.
  414.  
  415. Even though this vulnerability seems to be hard to exploit, we should not disregard this vulnerability because history and recently Chris Evans’ write-up about off-by-one shows that any kind of scenario can become real in some circumstances.
  416.  
  417.  
  418.  
  419. Conclusion
  420.  
  421. This vulnerability is obviously a serious issue for users who are still running Windows XP. Unfortunately, due to Windows XP being no longer being supported, the vulnerability is not going to be patched. Therefore, us
RAW Paste Data