얼마 전 windows media player 등 MS사 제품들이 MIDI 포맷의 확장자를
처리할 때 발생하는 보안취약점 및 패치가 공개되었습니다.

해외 보안 사이트 vupen.com에서 이에 대한 상세 분석보고서를 내놓았으며,
이에 대한 번역 및 추가설명을 다는 작업을 진행해 보았습니다.

번역문과 원문을 함께 실었으며, 빨강색으로 된 부분은
해당 부분에 추가 설명을 작성한 것입니다.
특히 MIDI 파일 포맷에 대한 내용을 많이 추가하였습니다.

이 취약점은 현재 악성코드 전파에 실제로 악용되고 있으며,
이 취약점에 대한 패치 URL은 다음과 같습니다.
http://technet.microsoft.com/ko-kr/security/bulletin/ms12-004
 

Internet Explorer 힙 오버플로우 취약점에 대한 advanced exploitation (MS12-004)

Advanced Exploitation of Internet Explorer Heap Overflow Vulnerabilities (MS12-004)

[번역 시작]

안녕하세요. 

2012년 정초부터 재미있는 CVE들이 쏟아지네요. 그 중에 하나인 CVE-2012-003을 소개하려고 합니다.

이 취약점은 윈도우 미디어 라이브러리에 영향을 받으며, MIDI 파일을 처리 하는 데서 발생합니다.
지난주에 MS에 의해서 패치가 됐습니다.(MS12-004)
매우 위험한 취약점 이기 때문에 반드시 패치 하시기를 권장합니다.

위키피디아에서 MIDI를 쳐보면, "MIDI is an industry-standard protocol, first defined in 1982" 라고 나옵니다.
고로 MIDI 포맷이 만들어진지 약 30년이 지난 지금까지도 MS같은 벤더들에게 문제를 일으키고 있습니다.

이 취약점은 흔하게 볼 수 있는 취약점 유형이지만, 이를 exploit하는 것은 쉽지 않습니다.

윈도우 미디어 플레이어나 윈도우 익스플로러가 MIDI 파일을 파싱 하는 과정에서 정적인 힙 영역이 할당되며,
최대 0x440 바이트까지 쓰기가 가능하게 됩니다. 그러나 0x440 바이트씩이나 쓰기가 가능함에도 불구하고,
일반적으로 IE쪽 취약점에 사용되는 exploit 기법들이 먹히질 않습니다.

(여기서 약간 오해의 소지가 있는데, 힙 버퍼 + 0x440이 아닌, 힙 버퍼를 포함한 0x440입니다.
아래서 보시겠지만 힙 버퍼의 크기는 0x400이므로, 실제 overwriting되는 크기는 0x40입니다.)

VUPEN 블로그에선 이 취약점을 IE9,8,7,6을 대상으로 reliable하게 exploit 함으로써 얼마나 위험한 취약점인지
보여 드릴 겁니다. 물론, ASLR과 DEP도 우회하면서 말이죠.

Hi everyone,

2012 has just begun with its bunch of very interesting CVEs. One of them is CVE-2012-0003, a critical vulnerability affecting Windows Multimedia Library and related to MIDI file handling. It was patched last week by Microsoft as part of the MS12-004 security bulletin. 

Due to the criticality of this vulnerability, we highly recommend applying the patch as soon as possible!

From Wikipedia we can read: "MIDI is an industry-standard protocol, first defined in 1982". So basically, 30 years after its creation, this format is still causing troubles to software vendors such as Microsoft.

By itself, the vulnerability is quite common but exploitation is not trivial. When an application such as Windows Media Player or Internet Explorer parses a MIDI file, a static heap buffer is allocated but up to 0x440 bytes can be written to. Nevertheless, due to the large allocation size, common exploitation techniques for Internet Explorer might not work with this vulnerability which makes exploitation really challenging.

In this blog we will demonstrates the criticality of this vulnerability by showing how it can be reliably exploited via Internet Explorer 9/8/7/6 to achieve code execution by bypassing ASLR/DEP.

1. 취약점의 기술적 분석

이 취약점의 핵심적인 부분부터 보여드리겠습니다.
MIDI 파일은 크게 두 개의 chunk 타입을 가집니다. 하나는 MThd고 다른 하나는 MTrk입니다.
아래 보시는 표가 이 두 chunk들의 구조입니다.

1. Technical Analysis of the Vulnerability

Here are the key points of this vulnerability. A MIDI file mainly contains two types of chunks, one named MThd and the other MTrk. Here follow the structures of both chunks:
 

MIDI 포맷에 대한 설명이 좀 부족한 것 같아 내용을 추가합니다
이 포맷을 이해하기 위해서 MIDI parser를 한번 돌려보면 좋습니다.
그래서 괜찮은 parser가 없는지 찾아보다가 웹 기반 MIDI parser를 발견했습니다.

http://phpmidiparser.com/

좌측의 Generate a Report를 클릭하면 내 컴퓨터의 MIDI 파일을 선택하여 서버로 보낼 수 있고요
parsing 결과를 HTML report 형태로 되돌려줍니다. 
참고로 출력된 report가 짧아 보이는데요, 우측 상단에 page(예> page 1/35)로 나뉘어져 있기 때문입니다.
이 page를 이동하시면서 남은 것들을 보실 수 있습니다.
 

내 컴퓨터에 있는 MIDI 파일을 하나 올리거나(*.mid로 검색하면 기본으로 깔린 것들이 있습니다)
혹은 이 사이트에서 다른사람들이 올려놓은 MIDI 파일에 대한 보고서를 보시면 됩니다.

다음 report들 중 하나의 MThd 청크를 가져와 본 것입니다.

보시면, 파일의 첫 12바이트인 MThd 청크는 MIDI 포맷의 시작을 알리는 부분으로서,
맨 앞의 4D 54 68 64(MThd)는 MIDI 포맷의 signature, 그 다음의 00 00 00 06은 뒤에 따라오는
value들의 길이를 나타냅니다.  (항상 6입니다.)

그리고 그 뒤의 value들인 00 00 / 00 01 / 01 80은 각각 다음을 의미합니다.

- 싱글트랙인지 멀티트랙인지 (0 = 싱글, 1 = 멀티, 2 = 비동기 멀티)
- 트랙의 수
- time division 값  (초당 프레임 수)

(보시다시피 MIDI 파일 내의 값들은 BIG ENDIAN입니다.)

그리고 이 MThd 청크 다음엔 MTrk 청크들이 존재합니다.
MIDI로 음악을 만들 때, 여러 트랙을 생성한 후 각 트랙별로 다른 악기의 연주를 넣을 수 있는데,
이 각각의 트랙이 바로 MTrk 청크가 됩니다. 즉, 10개의 트랙이 있다면 MTrk 역시 10개가 됩니다.

그리고 각각의 MTrk 청크들은 MTrk 헤더 + MIDI Command들로 이루어져 있습니다.
MTrk 헤더엔 signature인 4D 54 72 6B가 있고, 그 뒤에 이 헤더를 제외한 청크의 크기가 4바이트로 따라옵니다.

각 Track 내의 주요 값들을 살펴보면, 일단 건반이 눌렸을 때인 Note On 커맨드가 가장 많이 사용되고요
그 뒤로 어떤 음표(Note)인지에 대한 값이 따라옵니다.
그 외 좌우 pan을 조절한다던지, 강약(velocity)을 조절한다던지하는 값들 및 음악에 대한 부가적인 정보들,
예를 들면, 곡명, 작곡가 정보, 악기명 등이 포함될 수 있습니다.

하나 예를 들어 보자면,

이 역시 위 사이트에 올라온 어떤 report의 Track 2 중간부분을 긁어 온 모습인데요,

첫 번째 줄에선 Pan 값을 조절하네요. 좌우스피커 중 어디로 더 많은 소리를 낼지를 결정하는 값입니다.

해당 값은 64인데요, 16진수로는 0x40이고, 좌측의 00 0A 40 세 번째 값입니다.
가운데의 0x0A는 "Pan"임을 나타내는 define 된 값입니다.

그리고 첫 바이트인 0x00이 중요한데, 앞 이벤트 발생 후 몇 tick 후에 이 이벤트가 발생할지를 정합니다.
여기선 00이 사용되었으므로, 곧바로 이 이벤트가 발생됩니다. 
여기서 tick이란, 상대적인 시간 값으로서, 앞서 MThd에서 정한 초당 프레임 수에 따라 실제 시간이
계산됩니다. 예를 들어, 초당 프레임 수가 60이고, tick이 60이 되면, 실제로는 1초가 됩니다.

다음 줄은 볼륨을 조정하는 부분으로서, 위와 동일한 포맷이고요
07이 볼륨 조정을 의미하는 defined 값임을 알 수 있습니다.

세 번째 줄은 이 Track에서 사용 할 악기를 선택하는 부분입니다. Fretless Bass가 선택되었네요.

마지막 두 개는 Note On인데, 가장 많이 쓰이는 커맨드로서, 건반을 누르는 것에 해당합니다.
그리고 실제 취약한 커맨드이기도 합니다.

D2에서 D는 "레"를 나타내는 define 된 값이고요, D 뒤의 2는 옥타브를 의미합니다.

그 뒤의 velocity 는 건반을 누를 때의 강약을 표시하는 값입니다.

[43 ticks]을 16진수로 바꿔보면 0x2B고요, 그러므로 마지막 줄  2B 26 00 의 의미가 명확해집니다.
즉, "0x2B ticks 후에 2옥타브의 레를 0x00의 세기로 연주해라" 라는 커맨드입니다.

근데 그 바로 윗줄을 보면, 82 20 90 26 6E와 [288 ticks]이 서로 매치되지가 않습니다.
288을 16진수로 바꾸면 0x01 0x20인데요, 보여지는 HEX 값은 0x82 0x20이기 때문입니다.

생각해보면 tick에 해당하는 hex 값이 1바이트일 때와 2바이트일 때를 구분해야하는 bit masking 값이
있어야 할 것 같습니다. tick의 값이 255보다 작다면 한 바이트, 크다면 그 이상의 바이트가 필요하기 때문입니다.

맨 앞 0x82를 2진수로 보면 10000010인데, 최상위 비트(MSB) 값이 바로 bit masking 값입니다.
이 bit masking 값이 1일 때의 tick 계산 방법은 살짝 복잡한데, 정리하면 다음과 같습니다.

- tick 정보의 첫 바이트를 읽어와 bit masking이 1인지 확인합니다.
- 1이라면, 다음 한 바이트를 추가로 읽어옵니다. 그리고 여기서도 bit masking가 1인지 확인합니다.
- 1이라면, 또 다음 바이트를 읽어와서 역시 bit masking을 비교합니다.
- 마지막 바이트의 bit masking은 항상 0이 됩니다.

이런 식으로 최대 4바이트의 tick 값을 가져올 수 있습니다.
그리고 만약 도중에 bit masking 0을 만나게 되면, 더 이상 값을 가져오지 않습니다.
그러므로 tick의 크기는 1바이트~4바이트 사이가 됩니다.

그리고 다음이 중요한데, 이렇게 읽어온 바이트들 중 모든 bit masking 값을 제거한 후 주욱 이어야
실제 값이 나오게 됩니다.

즉, 위의 예제인 82 20 90 26 6E을 대상으로 보면,

- 0x82 => 10000010 => bit masking이 1이므로 다음 바이트를 더 읽어옵니다.
- 0x20 => 00100000 => bit masking이 0이므로 더 이상 읽지 않습니다.
- 읽어온 값들을 주욱 잇습니다. 1000001000100000
- 이 값들 중 위 형광색 bit masking을 제거합니다. 00000100100000
- 이 값을 10진수로 바꿉니다. => 288 ticks == [288 ticks]
 

tick 값은 이런식으로 계산하면 되고,
(사실 취약점과 이 tick 사이에는 관련이 없습니다. 다음 바이트가 중요합니다.)

세 번째 바이트인 0x90은 event type과 channel을 동시에 나타내는 값으로서, 4비트씩 끊어 읽어야 합니다.
=> 0x9, 0x0 (취약점 발생원리 분석에 있어 중요한 부분입니다.)

앞의 0x9는 note on event를 의미하고, 뒤의 0x0이 channel을 의미합니다.
여기서 channel이란, MIDI 장비의 어떤 포트로 소리를 출력할지 정하는 것입니다.

그리고 앞의 event type으로는 다음과 같은 것들이 올 수 있습니다.

근데 이 바로 전에 보았던,

에선 Note On임에도 불구하고 0x90 값이 보지지 않습니다.

아마 MIDI 파일의 용량을 줄이기 위해 경우에 따라선 생략도 가능한 값인 것 같습니다.

그리고 다른 report의 Track 1에서 다음과 같은 라인을 하나 가져와 봤습니다. 
(취약점과는 관련 없는 부분입니다. 기왕 보는 김에.. 그리고 새로운 취약점 발견에 도움이 될 것 같아서 넣습니다.)

Track Name을 나타내는 부분인데요, 구조를 보시면..

[0x43] [0x6F] .... [0x72] 이 부분은 "Come Together" 문자열에 해당하고요,
이 문자열의 길이를 세보면 13인데, 이 값이 0D 에 해당합니다.

이제 남은 건 FF 03인데, [0xFF]는 "부가 정보(metadata) event"를 의미하며, 
[0x03]은 "Track Name"을 의미합니다.

이 필드에 해당하는 다른 값들은 다음과 같습니다.

좀 허접한 MIDI 프로그램이라면 이 metadata를 parsing할 때에도 충분히 취약점이 발생할 수 있을 것
같습니다. 시간날 때 fuzzing을 한번 해봐야겠네요ㅋ

MIDI 포맷 추가 분석은 이정도로 마치겠습니다. 
이처럼 대충 이런 구조로 돌아간다~를 알고 있으면 취약점 분석에 도움이 될 것입니다.

이제 다시 번역으로 이어집니다.

MIDI 파일을 처리하기 전에 윈도우 미디어는 winmm.dll 에 있는 mseOpen() 이라는 함수를 이용해서
두개의 버퍼를 할당합니다.

Before processing the file, Windows Media allocates two buffers in "mseOpen()" in winmm.dll:
 

두번 째 할당되는 버퍼는 앞으로 B1 이라 부르겠습니다. (앞으로 이 버퍼 + 0x40바이트 만큼 bof 가능해집니다)
이 취약점은 MTrk chunk가 파싱되는 과정에서부터 시작됩니다.
Quartz.dll 에 있는 smfReadEvents() 라는 함수에서 처음으로 읽혀집니다.

The second buffer will be noted b1 in the following. This specific vulnerability lies in the way certain events from the MTrk chunk are parsed. These events are first read in "smfReadEvents()", defined in quartz.dll:

이 event는 해당 값의 첫번째 바이트들을 통해 식별되고 앞으로 각각의 값들을 e1 , e2, e3 라고 
부르겠습니다. Ecx=0x00e3e2e1 

예를 들어 첫 바이트가 0x90라면 note on event로 식별된다는 말입니다.
Ecx가 언급되는 이유는 smfGetNextEvent로 가져온 값을 ecx에 넣기 때문입니다.
(.text:74903498 mov ecx, [ebp+var_8])

그리고 Ecx=0x00e3e2e1의 맨 앞 바이트가 0x00인 이유는, 0xFF 이벤트를 제외한 다른 이벤트들의
최대 값이 3바이트이기 때문인 것 같습니다.

앞서 보여드렸던 표를 다시 보시면 이해가 가실 겁니다.

그리고 앞에서 보았던 report로 예를 들면,

여기서 0x90 0x26 0x6E 이렇게 3바이트가 이벤트입니다. 

E1 < 0xF0 인 event가 눈여겨 볼만 합니다. 

윗 코드의 아래에서 2번째 줄을 말하는 겁니다
이는 meta data event가 0xFF가 아닐 때에 발생하는 취약점임을 의미합니다.


다음 코드들에서 event는 기존에 할당되어 있었던 배열의 8번째 offset에 씌여집니다.

An event is identified by its first byte and noted e1 e2 e3 in the following, so that ECX = 0x00e3e2e1. 
Only events where e1 < 0xF0 are of interest. 
In the next piece of code, the event is written at offset 8 in an array previously allocated:

이 배열은 winmm.dll의 midiOutPlayNextPolyEvent() 함수에 의해 나중에 처리됩니다.

This array is next handled by "midiOutPlayNextPolyEvent()", in winmm.dll:

아래 부분에서 프로그램은 e1이 0x7F보다 큰지 아닌지를 분별하게 됩니다.

위에서 보여드린 표에 나타나있듯이 e1는 0x80부터 시작하기 때문입니다.

At this moment, the application distinguishes whether or not  e1 > 7Fh: 

아래 코드에서 볼 수 있듯이,
윈도우 미디어는 e1 & 0xF0 의 결과가 0x80 혹은 0x90일 때 각각 특별한 루틴을 호출합니다.

즉, Note On(건반 누름) 혹은 Note Off(건반 뗌) 이벤트에 해당하는 부분입니다.

As we can see in the following lines, Windows Media specifically processes events where e1 & F0h = 80h or 90h:
 

각 경우에 위쪽에서 할당됐었던 힙의 B1 버퍼에 데이터를 쓸 오프셋을 계산하기 위해서 e1과 e2를 사용합니다.

즉, channel 값과 note(음표) 값을 연산에 사용합니다.

For such cases, an offset is computed according to e1 and e2 to write data to the buffer b1 allocated above:

결과적으로 EAX = ((e1 & 0x0F) * 2^7 + e2) / 2가 됩니다.

예를 들어, E1이 0x9F 일때,
((0x9F & 0x0F) * (2의7승) + e2) / 2 = 0x780 + e2가 됩니다.

여기서 복사 대상이 되는 버퍼가 2차원 배열 형태이며, 배열 하나의 크기는 2^7인, 0x80인 것으로 추정됩니다.
위 0x9x에서 x는 channel 값을 의미하므로, 채널 하나당 어떤 정보를 담을 수 있는 공간이 0x80인 것이고,
결국 이 x값과 0x80값이 곱해져서 2차원 배열참조가 되는 형태인 것으로 보입니다.
 

여기서 만약 e2가 0x7F 이상이라면 e1+e2는 0x800이상이 되고 나누기 2에 의해 최종적으로 EAX가
0x400 이상이 될 수 있습니다. 고로 프로그램은 기존에 할당된 버퍼영역 뒷쪽에 쓰기를 시도할 것입니다.

ex> 0x0000889F
=> 9F & 0x0F = 0xF
=> 0xF * 0x80(2^7) = 0x780
=> 0x780 + 0x88 = 0x808
=> 0x808/2 = 0x404

e1 & 0xF0이 0x90이냐 0x80이냐 혹은 e3이 1인지에 따라 특정 바이트값을 증가시키기도, 감소시키기도 합니다.

e1 & 0xF0이 0x90일 때,

At the end, EAX = ((e1 & 0Fh) * 2^7 + e2) / 2. 

This is where the data in b1 is going to be altered. Note that for particular values of e1 and e2, it is possible to get EAX > 400h. For example, e1 = 9Fh => 0Fh * 2^7 = 780h. Then if e2 > 7Fh, e1 + e2 > 800h which makes EAX >= 400h and the program writes past the bounds of the allocated buffer.

Depending on whether e1 & F0h = 90h or 80h, or even e3 = 1, it is possible to increment or decrement an arbitrary byte. For example with e1 & F0h = 90h:

E1 & 0xF0 이 0x80일 때, 

If e1 & F0h = 80h:
 

B1이 0x400 바이트의 크기를 가지기 때문에,
E1이 0x8F나 0x9F이면서 동시에 e2가 0x7F 이상일 때 힙 오버플로우가 발생합니다.
실제로, B1 영역 뒤쪽의 최대 0x40 바이트만큼을 덮는 것이 가능하고,
이는 악의적인 코드를 실행하기에 충분합니다.

Since b1 is 0x400 bytes long, a heap overflow occurs when e1 = 8Fh or 9Fh and when e2 > 7Fh. In practice, it becomes possible to corrupt the 0x40 bytes following b1, which is enough to achieve arbitrary code execution.

여기서 0x80 == 128이란 숫자는, 표현할 수 있는 Note들의 최대수에 해당하는 값으로 추정됩니다.
다음 표를 보시면 왜 이렇게 생각하는지 이해가 되실 겁니다.

결국, Note 값을 의미하는 e2 값이 최대 값인 127을 넘어버리면서 다른 엉뚱한 곳에 접근하게 되는
Array index overflow 취약점인 것으로 보입니다.

참고로 e1 값은 잘못이 없습니다. 제대로 배열의 시작 부분을 pointing하고 있으며,
e2 값이 그 배열의 scope를 넘어버리면서 발생하는 취약점입니다.

몇가지 의문 사항이 남아있긴한데.. 일단은 메모만 해놓도록 하겠습니다.
- 총 16개의 채널을 선택할 수 있으므로 b1 버퍼의 크기는 16*0x80인 0x800이 되어야하는 것 아닌가?
- note의 최대값인 127을 벗어나 최대 255까지 접근할 수 있으므로 overwriting 가능한 영역은
0x40이 아닌 0x80이 되어야하는 것 아닌가? 
- 덮어쓰기되는 src 값은 무엇인가?

2. ASLR / DEP 우회기술

취약한 모듈이 Internet Explorer 안에 로드되어 있기 때문에, 이 취약점을 reliable하게 exploit하는 것이
가능합니다.

힙 오버플로우 유형의 취약점들은 보통 인접한 vftable을 덮어쓰기한 후, 그 vftable에 소속된
메서드를 호출함으로써 쉘코드가 실행되도록 합니다. 하지만 그냥 windows media player를
exploit한다고 치면, vftable을 인접한 곳에 위치시키는 것도 어렵고, 그렇게하여 overwriting에
성공했다하더라도 해당 메서드를 호출할 수 있는 방법이 있어야하므로 성공 확률이 매우 낮습니다.

반면, Internet Explorer는 java script를 이용하여 어느정도 heap을 자유롭게 컨트럴 할 수 있으므로
이처럼 reliable exploit이 가능하다고 말하는 것입니다.

Winmm.dll의 DllProcessAttach() 함수와 mshtml.dll의 _DllMainStartup().
두 함수에서 동일한 힙 영역을 사용하여 할당을 수행합니다.

만약 취약한 함수가 사용하는 heap과 java script가 사용하는 heap이 서로 다른 영역이었다면
힙 컨트럴이 무의미해지게 됩니다. 

2. Advanced Exploitation With ASLR/DEP Bypass

Since the vulnerable module can be loaded in Internet Explorer, it is possible to achieve a reliable exploitation of this flaw.

As we can see in "DllProcessAttach()" in winmm.dll and "_DllMainStartup()" in mshtml.dll, both libraries use the same heap for their allocations:

In "DllProcessAttach()":

In "_DllMainStartup()":

결과적으로 이 취약점을 이용하여 IE 객체를 변조하는 것이 가능합니다.

보통, 이런 류의 취약점을 exploit 하기 위해서는 취약한 버퍼의 사이즈와 동일한 사이즈를 갖는 객체를 찾습니다. 그럴 때 다음과 같은 과정이 진행됩니다.
- 취약한 버퍼와 인접한 곳에 스트링과 오브젝트를 할당합니다.
- vTable 을 드러내고, mshtml.dll의 베이스 어드레스를 알아내기 위해서 스트링의 길이를 덮어씁니다.

As a result, it is possible to exploit this vulnerability to corrupt an Internet Explorer object. 

Usually, exploitating such vulnerabilities consists in finding an object whose size is equal to the vulnerable buffer's size. In that case, exploitation can be achieved in the following way: allocate contiguously the vulnerable buffer, a string and an object. Once done overwrite the string's length to disclose the vTable and deduce mshtml.dll's base address:

새로운 버퍼를 할당하고 취약점을 두번 발생시키면 객체의 vTable을 덮는게 가능해집니다.

Allocate then a new buffer and trigger the vulnerability a second time to overwrite the object's vTable:

이 과정에서 ROP 코드들을 힙에 spraying 시키고 변조된 객체로부터 함수를 부르게 되면 프로그램 흐름을 
바꿀 수 있습니다.

다행인지 불행인지 모르겠지만, 이러한 방식은 취약점을 두 번 발생시킬 수 있어야 하며, 주어진 사이즈만큼
객체를 할당할 수 있어야만 성공합니다.

MIDI event를 parsing할 때마다 취약점이 발생할 것이므로, 여러번 취약점을 발생시키는 것이 가능합니다.

버퍼의 사이즈가 0x100 바이트보다 작다면, IE는 위와 같은 방식으로 공격할 수 있을 만큼 충분한 객체를
제공하지만, MS12-004 (우리가 현재 공략하려는 취약점) 에서는 0x400 바이트만큼의 버퍼를 가지면서
mshtml.dll에서 0x3FC나 0x400에서 XREF 를 수행하기 때문에 뭔가 조작할 껀덕지가 없습니다.

하지만, 이 취약점을 reliable하게 공략할 수 있는데, 바로 CImplAry 라는 특수한 객체를 이용하는 것입니다.
0x400 바이트만큼의 배열을 생성하고, 이 배열내의 값들을 정확하게 변조 함으로써 vTable을 알아낼 수 있고,
프로그램 흐름을 변경할 수 있게됩니다.

CImpAry가 바로 힙 컨트럴의 key가 되는 객체인 것입니다. 

이런 배열은 요소가 복제될 때 인스턴스 내에서 생성될 수 있습니다.
CElement::Close() 메소드는 CElement::CloneAttributes()를 호출하고, 속성을 복사하기 위해서 최종적으로 CattrArray::Clone()이 호출됩니다. 아래는 CAttrArray::Clone() 의 코드입니다.

At that point, spray the heap with a dynamic ROP for mshtml.dll and call a function from the corrupted object to redirect the execution flow.

(Un)fortunately, this method requires the vulnerability to trigger twice and only works as long as it is possible to allocate an object of a given size. For sizes < 0x100 bytes, IE provides enough objects for that method to work but in the particular case of the MS12-004 vulnerability, the buffer is 0x400 bytes long, and doing an XREF on 3FCh or 400h in mshtml.dll does not provide any interesting object allocation.

A reliable exploit for this vulnerability can however be created by taking advantage of a particular CImplAryobject. The idea consists in creating an array of size 0x400, and precisely altering its content to disclose an arbitrary vTable and redirect the execution flow.

Such an array can be created for instance when an element is cloned. As we can see, "CElement::Clone()" leads to call "CElement::CloneAttributes()" and eventually "CAttrArray::Clone()" to clone the attributes. The following lines belong to "CAttrArray::Clone()":
 

이 과정에서 프로그램은 원래의 요소가 속성을 가지고 있는지 체크합니다.

At that point, the application checks whether the original element contains an attribute:
 

속성번호가 0이 아니라면 IE는 0x10 * (CImplAry::EnsureSizeWorker()의 속성값) 만큼 할당합니다.
결과적으로 원본 엘리먼트가 0x40이라는 속성값을 가진다면 IE가 정확히 0x400 만큼의 배열을 생성한다는
소리입니다. 이러한 속성값은 나중에 CAttrValue::Copy()에 의해 복사됩니다.

If this number is not NULL, IE allocates 10h * #attributes in "CImplAry::EnsureSizeWorker()". As a result, if the original element has 0x40 attributes defined, IE allocates exactly 0x400 bytes for the new array. These attributes are next copied by "CAttrValue::Copy()":

다음 스크립트는 Selet 엘리먼트를 생성하고 여러 속성을 지정한 뒤 복사합니다.

Consider now the following script, which creates a new Select element, associates various attributes and clones the node:

복사가 되고 나면 CImplAry 는 아래와 같이 됩니다.

Once cloned, the CImplAry looks like this:

Actually an attribute is identified by three fields and uses 0x10 bytes in memory. Pay attention to the bytes in red on Figure 3. They represent the variant types as defined in MSDN: 0x08 indicates a string, 0x09 an object, 0x03 an integer etc.

The following figure shows obj0, obj8 and obj12 as represented in memory:

Since the application specifically relies on the variant type to determine the type of the attribute, it becomes possible with a heap overflow to corrupt the array and force the browser to confuse types. Figure 5 shows the CImplAry after incrementing and decrementing two bytes:

Figure5에서 obj0은 객체가 되었고 , 반대로 obj1은 스트링이 되었습니다.
이것은 ASLR과 DEP를 우회하기 위해서 객체의 vTable을 다음과 같이 자바스크립트로 찍어보는게 가능하죠.

On Figure 5, obj0 is now an object while obj1 is a string. It is then possible to bypass ASLR/DEP by leaking the object'svTable using JavaScript. This gives the following result:

Then the corrupted string is used to trigger the vulnerability in "CAttrValue::GetIntoVariant()" and reach a CALL instruction leading to arbitrary code execution despite ASLR/DEP:

두 바이트를 변조하는 것만으로도 위 방법이 잘 적용됩니다. 만약에 한 바이트만으로 가능하다면
알려주세요.

또한 이 방법은 IE9/8/7/6 에서 전부 reliable하게 적용됩니다. (모두 할당된 힙사이즈가 0x230이상)
이렇게 본 블로그에서 보여 드린 바와 같이 매우 위험한 취약점이므로 반드시 패치하시길 바랍니다.

Two bytes need to be altered for that method to work. If you manage to do it with only one, please let us know! Note also that this method works reliably with all Internet Explorer versions including 9/8/7 and even IE6, since heapAlloc is used for sizes > 0x230. 

As demonstrated in this blog, this vulnerability is really critical thus we highly recommend applying the patch as soon as possible!

위에서 설명하고 있는 ASLR/DEP 우회 원리를 간략하게 정리하면 다음과 같습니다.

[overflow되는 버퍼] [STRING 오브젝트] [VFTABLE을 가진 오브젝트]

일단 이런 모양의 힙이 ALLOC되도록 의도적으로 만든 후, (힙 풍쒜이!)

overflow되는 버퍼를 overflow시켜서 STRING 오브젝트의
NULL을 없애버리던지, 혹은 STRING 오브젝트 구조 내의 LENGTH
값을 늘려버립니다. (유니코드냐 ASCII냐에 따라, 그리고 APP 환경에 따라 달라집니다.)

이렇게 한 후, 이 STRING을 자바스크립트 등으로 출력을 시키면,
뒷쪽의 VFTABLE 값들까지 함께 튀어나와버립니다

그럼 이 VFTABLE 주소값들을 보고 DLL의 시작주소를 알 수 있습니다
- VFTABLE엔 주로 DLL의 메서드 주소들이 들어가 있으므로
- DLL의 시작주소는 얻어낸 주소 - 메서드의 OFFSET을 하면 됩니다
- 어떤 DLL의 주소가 튀어나올지는 대상 APP이 뭐냐에 따라 다릅니다

다음으로 실제 EXPLOIT할 때엔,

[overflow되는 버퍼] [VFTABLE을 포함한 오브젝트]

이렇게만 메모리 구성을 하고, VFTABLE의 값을 0x41414141로
바꾸면 나중에 그 메서드를 호출할 때 EIP가 0x41414141이 됩니다

이 때 앞서 얻어온 DLL의 주소를 활용하여 ROP 대여정을 시작할 수 있습니다.

이상으로 MS12-004에 대한 번역 및 부가설명을 마칩니다.
요약을 하자면.. e1에 해당하는 값이 0x8F이거나 0x9F 일 때 배열의 마지막 요소를 가리키게 되고,
동시에 e2 값이 0x7f보다 커야 이 배열 scope를 넘어서 다른 곳을 건들 수 있는 취약점입니다.

만약 Fuzzing을 통해서 이 취약점을 찾는다고 가정하면, 동시에 두 offset을 건드려야하고,
또 극히 제한된 값을 사용해야 취약점을 유발시킬 수 있는, 게다가 일반적인 상황에선 overflow가
발생해도 crash 없이 종료될 것이기 때문에(vftable 문제) 임의로 재현하는 것조차 힘들 것입니다.
취약점 발견자인 IBM Security System's X-Force Research의 Shane Garrett은 완전 노가다 리버싱을 했거나,
e1과 e2 값에 대한 taint analysis로 힌트를 얻었을 것 같네요. 

추가적으로 궁금했던 부분들은 기회가 되면 추가하도록 하겠습니다.
잘못 번역된 곳이나 틀린 설명이 있으면 알려주세요!