CVE-2012-4792와 함께하는 희망찬 새해! 새해가 밝았습니다. 조금 늦은감이 없잖아 있지만 산타할아버지가 외교협회 (공격당한 사건. 이 포스팅에서 다루는 제로데이로 인해 공격당함 ) 에 준 선물을 제가 풀어볼 기회가 있었네요. Microsoft를 비롯해서 몇몇 해커들이 블로그에 이번에 이슈가 된 CVE-2012-4792 에 대해서 포스팅을 했습니다. 하지만 저도 빠질 수 없죠. 최대한 제가 분석했던 모든 내용들을 순차적으로 담아내려 노력했으니 잘 읽어보시면 여러분도 똑같이 따라해 볼 수 있을겁니다. 저같은 경우에는 윈도우 XP 상에서 돌아가는 IE8 에서 분석했으나, 윈도우 7 에서도 잘 될겁니다. 저의 mshtml 버젼은 8.0.6001.19393 이였습니다. * 분석 제가 가장 첫번째로 한 일은 metasploit 익스플로잇에서 힙스프레이 부분과 다른 잡다한 것들을 빼버리고 취약점을 발생시키는 가장 심플한 코드를 만드는 것이였습니다. 그 결과물은 다음과 같습니다. 그 다음으로는 iexplorer.exe에 glags 를 이용하여 pageheap 과 user stack trace 기능을 켜고 위에서 만든 심플한 poc 를 실행시켜 취약점이 발생하는지를 지켜보는 것이였습니다. 그 결과 아래와 같은 windbg 로그를 볼 수 있었습니다. 위 결과를 통해서 알 수 있는 사실은 , free된 오브젝트는 CButton 오브젝트였으며, onload핸들러가 완전히 끝날 때 이 해제된 오브젝트를 다시 사용한다는 것입니다. poc 코드를 다시 살펴보면 이러한 동작과 연관있는 코드를 볼 수 있습니다. 아래 코드는 해제될 CButton 오브젝트를 생성하는 코드입니다. 어떤 타이밍에 오브젝트가 해제되고 재사용되는지 한번 알아봅시다. poc코드에 약간의 자바스크립트 코드를 추가해서 내부적으로 어떤일이 일어나는지 디버깅을 해보겠습니다. 또한 CButton 오브젝트가 생성되고 해제되는 것을 알기 쉽게 생성과 해제를 담당하는 루틴에 각각 브레이크 포인트를 걸겁니다. CButton 오브젝트를 생성하는 것은 CButton::CreateElement 메소드입니다. HeapAlloc에 브레이크 포인트를 걸고 지켜보면 어떤 주소가 CButton으로 할당되는지 알 수 있습니다. 해제되는 곳 역시 windbg 로그를 통해 알고 있으므로, 해제하는 곳에도 브레이크 포인트를 겁니다. poc코드에 Math.atan2 와 같은 자바스크립트 코드를 집어 넣으므로써 poc코드가 실행되는 과정에서, 순차적으로 어떠한 일이 일어나는지 디버깅해볼 수 있습니다. 실행해보면 아래와 같습니다. sxe ld:jscript 를 해 놨기 때문에 jscript.dll이 로드되면 브레이크 포인트가 걸립니다. 이 때 자바스크립트 로그 메세지를 보기 위해 브레이크포인트를 걸면 됩니다. CButton 오브젝트는 CollectGarbage 가 호출되는 동안 삭제되지만 해당 call이 끝나기 전까지 재사용되지 않습니다. 그렇기 때문에 이 타이밍에 정확한 크기로 데이터를 할당한다면 프로그램 흐름을 제어할 수 있게됩니다. 이 부분은 뒤에서 자세히 살펴보도록 하겠습니다. 다음 해야 할 일은 정확히 왜 use-after-free가 일어나는지 알아보는 것입니다. Microsoft 측에서 이미 그들을 블로그를 통해 이 부분에 대한 상당한 힌트를 제공하고 있습니다. 크래시가 나는 곳으로 다시 돌아가 edi 가(해제된 메모리를 가리키는 레지스터) 어디서 부터 흘러오는지 확인해 보겠습니다. ( mov eax, [edi] ; blah..; call [eax+0xdc] ) 살펴보니 CElement::FindDefaultElem 함수가 이미 해제된 CButton 엘리먼트를 리턴하는 것 같습니다. 해당 취약점에 대한 패치에서 이 함수를 패치하는 것으로 보아 저희가 제대로 분석하고 있다는걸 알 수 있습니다. 이 함수는 프로세스가 crash되기 전에 몇번 호출됩니다. 고로 스트레스 받지 않고 제명까지 살려면 이 함수에 브레이크 포인트를 걸면 안되고 이 함수를 호출하는 CMarkup::OnLoadStatusDone 함수에 브레이크 포인트를 걸어야 합니다. 한마디 덧붙이자면 사실 이 해제된 오브젝트를 통해서 EIP 컨트롤 하는건 매우 쉬운 일입니다. 확연하게 해제된 오브젝트의 vftable 을 조작할 수 있고 이 vftable에서 메소드가 호출되기 때문입니다. 어쨋든 이제 CButton오브젝트가 생성되고 해제되는 곳에 브레이크 포인트를 걸었기 때문에 해제된 CButton 오브젝트의 주소를 알 수 있으며, CElement::FindDefaultElem 이 호출되기 전에 CMarkup::OnLoadStatusDone 함수에 브레이크포인트를 걸었습니다. 아래 로그파일은 읽기 쉽게 약간 수정한 것입니다. 이 로그에서 얻을 수 있는 정보는 CButton 오브젝트가 해제되었음에도 불구하고 CDoc element 에 레퍼런스 되고 있다는 점입니다. 다음으로 할 일은 poc코드를 다시 실행하는겁니다. ( 이미 엄청 많이 다시실행 하고 있지만요 ) 이제 왜 해제된 오브젝트의 레퍼런싱이 남아있는지 알아봐야 합니다. 그 이유를 알기 위해선 mshtml!CDoc::operator new 함수에 브레이크 포인트를 걸고 CDoc 오브젝트+0x1A8 위치에 메모리 브레이크 포인트를 걸어서 어떤 함수가 이 위치에 데이터를 쓰는지 알아보는 겁니다. CElement::SetDefaultElem 함수가 메인 CDoc 오브젝트에 레퍼런스를 추가하기 전에 AddRef함수를 호출하는 것을 "까먹은" 것 같습니다. 이런 오브젝트는 다른 오브젝트에 대한 레퍼런스를 제거함으로써 해제될 수 있지만, CDoc 오브젝트의 Default Element 레퍼런스를 통해서 여전히 접근이 가능합니다. 이제 우리는 PoC를 조금 더 심플하게 만들 수 있습니다. 제 나름의 방식대로 poc를 심플하게 만들고 얼마 후 BinVuln.com 에 h4ckmp 님이 올린 포스팅을 보니 저와 거의 동일한 아이디어를 사용하여 poc를 심플하게 만들었더군요. 이제 PoC 코드를 한줄한줄 보면서 주석을 달아보겠습니다. e0 = document.getElementById("a"); body의 form 오브젝트로 부터 레퍼런스를 얻어옵니다. e1 = document.getElementById("b"); body의 dfn 오브젝트로 부터 레퍼런스를 얻어옵니다. e2 = document.createElement("q"); q 라는 엘리먼트를 생성합니다. e1.applyElement(e2); Q 엘리먼트를 DFN 객체의 부모객체로 설정합니다. 여기까지 DOM 트리는 이런 모양이 될겁니다. Q->DFN e1.appendChild(document.createElement('button')); Button 엘리먼트를 생성하여 DFN 오브젝트에 추가합니다. DOM 트리는 다음과 같이 변합니다. Q->DFN->BUTTON e1.applyElement(e0); form 엘리먼트를 DFN 엘리먼트의 부모객체가 되게 함으로써 Q와 DFN 객체 사이에 Form 객체를 삽입합니다. DOM 트리는 최종적으로 이런 모습이 됩니다. Q->FORM->DFN->BUTTON e2.outerText = ""; 이제 가장 상단에 있던 Q 를 날려버림으로써 DOM 트리가 Q 엘리먼트만 레퍼런싱 하고 있게 만들었습니다. CButton 오브젝트를 가리키던 모든 레퍼런스를 날려버린거죠. e2.appendChild(document.createElement('body')); 이 코드는 use-after-free를 유발하기에 꼭 필요한건 아니지만 유발을 좀더 쉽게만들어줍니다. 하지만 왜인지는 저도 잘 모르겠습니다. 코드를 좀 더 살펴보니 취약점을 유발하는 코드를 좀 더 심플하게 만들 수 있을 것 같습니다. DFN이나 Q 오브젝트는 필요하지 않을 것 같습니다. Button 을 document에 추가하고 Form 오브젝트에 이 Button 오브젝트를 할당하기만 해도 취약점을 유발하기에는 충분합니다. 아래가 좀 더 짧아진 PoC 코드입니다. 역시나 동일하게 취약점을 유발시키며 아래가 그 결과입니다. 위 코드 역시 DIV 엘리먼트를 쓰지 않고, Button을 직접적으로 document.body에 할당하는 방식으로 더 짧게 줄일 수 있으나, 그렇게 하면 값들이 약간 달라지게 되고 exploit 하는게 조금 더 어려워집니다. 이제 우리는 exploit 하기 위한 대부분의 사실을 알고있습니다. free 된 오브젝트의 사이즈와 언제 free 되는지를 말이죠. 그렇기 때문에 해당 사이즈만큼 우리가 원하는 값을 할당해서 해제된 메모리를 바꿔치기 하는 것은 매우 쉬운 일입니다. 먼저 우리는 Low Fragmentation Heap에 의해 할당된 CButton Object가 사용한 메모리 영역을 확인해야 합니다. 왜냐하면 이 해제된 영역을 원하는 값으로 바꾸는 작업을 확실하게 확인하기 위해서 입니다. 이게 확실한 이유는 LFH는 free block들을 합치거나 나누지 않고 정해진 사이즈만큼의 block 을 재사용하는 방식이기 때문입니다. 해제된 CButton 오브젝트는 0x58 의 크기를 갖습니다. 그렇기 때문에 이제 해야 할 일은 0x58만큼 메모리를 할당하고 그곳에 원하는 값을 채우는 것입니다. LFH를 확실하게 사용하게 하는 방법은 Valasek 님이 쓰신 phrack문서에 나와있습니다. 바로 동일한 크기로 16번 연속으로 할당하는 거죠. 테스트에 앞서 iexplorer.exe의 pageheap 을 꺼야하며 windbg에 iexplorer가 attach 되어 있을 때 debugheap을 사용하지 말아야 합니다. 기존 poc코드에 LFH를 사용하기 위한 코드와 해제된 영역을 대체할 만한 코드를 추가했습니다. 실행하게 되면 다음과 같은 크래시를 확인할 수 있습니다. 레지스터가 원하는 값으로 바뀌었고, 바뀐 값을 참조하여 eip가 변조될 수 있으므로, 이제 완벽한 exploit을 만들 수 있다는 것이 확실해 졌습니다. register에 offset을 더한 곳을 참조하여 call을 하는게 아니라 EIP 를 곧바로 직접적으로 바꿀 수 있다면 더 멋지지 않을까요? 대부분의 exploit 제작자들은 힙스프레이를 사용했을겁니다. 하지만 IE8 에선 힙스프레이가 반드시 필요하진 않습니다. ASLR을 우회하기 위해서 memory leak 을 유발하지 않아도 되며 ASLR이 걸리지 않은 모듈이 로드되어 있을 필요도 없습니다. 이 방법은 새로운 기법이라고 생각하고 있습니다만 IE9 에서는 적용되지가 않기 때문에 이번 기회에 공개하도록 하겠습니다. IE8 은 SMIL 를 기반으로 한 HTML+TIME을 지원합니다. IE9와 더 높은 최신버젼에서는 지원하지 않습니다만 IE8에선 충분히 재미를 볼 수 있습니다. 정확히 말하자면 우리가 컨트롤 할 수 있는 문자열을 가리키는 임의의 크기의 포인터 배열을 만들 수 있게 해줍니다. 그렇게 하면 free된 0x58 사이즈 만큼의 메모리를 컨트롤 할 수 있고, vftable이 조작된 문자열을 가리키게 만들어서 call [eax+0xdc] 명령어가 힙스프레이없이 우리가 원하는 주소를 호출하게 만들 수 있습니다. 위 방법을 가능하게 하기 위해서는 몇가지 재밋는 구문을 html에 추가해야 합니다. 세미콜론으로 분리된 문자열로 t:ANIMATECOLOR element 의 'values' 속성을 세팅함으로써 우리는 문자열의 각각의 요소를 가리키는 포인터들의 배열을 만들 수 있습니다. 고로 우리는 0x58/4 0x22 값을 가지는 문자열을 사용할 필요가 있습니다. 이제 우리는 값 속성을 이 문자열로 둘 수 있습니다. 보세요, EIP를 직접 조작합니다. values 안에 들어가야 하는 색상 값이 정상적인 값이 아니면 exception이 나서 poc코드가 종료되기 때문에 try except 구문을 사용해서 넣어줘야 합니다. 이 코드를 수행하면 추가적인 할당이나 해제가 있을 수 있지만 공격에 큰 영향을 미치진 않습니다. EIP가 변경되었기 때문에 XP라면 일반적인 ROP 를 하면 됩니다.