Sedating the Watchdog: Abusing Security Products to Bypass Mitigations

TL;DR: Design issues in various security products, such as anti-virus, make it significantly easier for threat actors to bypass exploit mitigations. As part of our ongoing goal of complete endpoint security, we found a prevalent flaw where anti-virus products allocate memory with RWX permissions at a predictable address.


Back in March we disclosed a flaw in AVG which makes exploit-mitigation bypass significantly easier. Bypassing mitigations was possible due to allocation of memory with RWX permissions in a predictable address.

After we discovered this flaw to AVG we decided to check if other anti-virus products are vulnerable to similar issues. Indeed, we found similar design issues at a few other vendors and we have disclosed these issues to them.

Due to the prevalence of this issue, we can assume that this flaw resides in other intrusive applications such as application monitoring programs and other security products such as DLP.


Upon the creation of a user-mode process, the affected program injects from the kernel a small hooking code stub. In order to inject this stub, the program allocates a memory page with RWX permissions at a constant/predictable address.

Since this address is constant, a threat actor developing an exploit can leverage this vulnerability in order to remove any guesswork about the address space layout of the process. Consequently, a threat actor that has exploited a vulnerable third-party application and has gained control of that application’s instruction pointer, can then copy the malicious code to the program’s allocated RWX page and directly execute the malicious code.

In particular, when testing the affected anti-virus, we used as a Proof of Concept example a PDF application, vulnerable to CVE-2010-0188.

It is important to note that in order to leverage this vulnerability there was no need to bypass the underlying Windows ASLR and DEP. Effectively, the vulnerability acted as the conduit to defeating these defenses.

A technical breakdown of the vulnerability can be found in our March blog post following AVG’s fix.

Vulnerable Products

At the time of this release, we found the following anti-virus products vulnerable to this flaw.

  • McAfee Virus scan Enterprise version 8.8. This vulnerability appears in their Anti Malware + Add-on Modules , scan engine version (32 bit) 5700.7163 , DAT version 7827.0000 , Buffer Overflow and Access Protection DAT version 659 , Installed patches: 4. We have notified McAfee and they have silently fixed it in their patch dated Aug. 20, 2015.
  • Kaspersky Total Security 2015 – – kts15.0.2.361en_7342. . We have notified Kaspersky and they have silently fixed it in their patch dated Sept. 24, 2015,
  • AVG Internet Security 2015 build 5736 + Virus database 8919. As mentioned above, AVG has released their patch on March 12th.


We’d like to point out that these types of vulnerabilities are not just potentially exploitable. On September 22 Tavis Ormandy from ProjectZero wrote a very interesting post, “Kaspersky: Mo Unpackers, Mo Problems., about a vulnerability he discovered in Kaspersky that showed that these threats are real.

To exploit the vulnerability he found, Tavis used a second flaw in Kaspersky which was the allocation of RWX memory in a predictable address. To quote from Tavis’s blog Kaspersky have enabled /DYNAMICBASE for all of their modules which should make exploitation unreliable. Unfortunately, a few implementation flaws prevented it from working properly.”


To help test whether your computer is likely to be vulnerable to exploitable constant, RWX addresses, we released a AVulnerabilityChecker which can be found here –


Run the tool, you should get the following screen:


Open a browser (Chrome, Firefox or Internet Explorer) with at least two tabs open and press any key.

What the tool does next is to scan the address space of all open browser process while looking for memory regions with RWX permissions. The reason we require more than one open tab is to avoid false-positives. The tool marks a RWX memory region as a candidate only if it was mapped by more than one process, or if its address is below 0x50000.

After the scan has finished the following screen should appear:


As instructed, close the reopen browser process and press any key.

Next, the tool will re-run the initial scan and compare the results to the first scan. Any memory region that exists in both scans it very likely to be a predictable RWX region. In case your computer is vulnerable the following screen should appear:


In case your computer was found vulnerable, the next step is to research which product this memory region actually belongs to. In most cases it can be done simply by attaching a debugger to one of affected process’ pid and view the relevant region. Normally, the dll name or the address of the relevant module will be found in that region. For example, in the case of AVG it was trivial to spot:


Beyond Browsers

Since we wanted to keep the tool as simple as possible we wrote the tool to scan only browser processes.

However, this issue is not confined just to browser processes. As we have shown in AVG’s case (where the exploit was demonstrated through Acrobat Reader) many other processes may be affected as well.

As such, we’ve also provided the security analysts with the script code, also found in BreakingMalware’s GitHub. The code can be easily modified to test other processes as well.


Update: This blog has been updated to reflect that we were notified that McAfee silently patched the vulnerability appearing in McAfee Virus Scan Enterprise 8.8.

Endpoint security is what enSilo does. Check us out!

Sign Up for a Demo Today


Related Blog Posts