Security Software Usage Of Mitigation Techniques With Slopfinder

I recently read a post that used static analysis of executable files to see which applications were using DEP/ASLR and to what extent. This inspired me to perform the same analysis with the same tool, but on security software.

Antivirus software runs with very high privileges on a system, and it deals directly with malicious, attacker controlled code. Ensuring that modern mitigation techniques are enabled is essential when designing security software, as your code is inherently exposed to an attacker. In other words, the code here should be held to the highest standard. A

nalysis performed in a Windows 8 64bit VM using slopfinder in Chrome Stable. Slopfinder is a tool that performs static analysis on executable files to check their security flags, whether or not they make use of DEP / ASLR.

Using Slopfinder is as simple as dragging/ dropping a folder full of executables and then looking through the results, which is what I’ve done here.

Default installations – trial software used if available for Pro versions. Some of these programs install “web guards” that are actually glorified Ask Toolbars or some other BS toolbar- these are included in results, they’re part of the ‘security’ package and they’re entirely relevant.

If I don’t specify DEP/ASLR it means both are disabled. This is the case for the majority, which I’m assuming has to do with ‘permanent’ DEP, as I’d be very surprised if DEP were really disabled so frequently – but who knows! UPDATE: Here is an explanation for the DEP.

Keep in mind that just because some files don’t support ASLR or DEP doesn’t mean you’re vulnerable. Some of these files won’t ever interact with ‘attacker code’ – there’s little reason for program uninstallers to support ASLR, for example, and the same goes for installers.

If anyone has more information to add (for example if one of these offending DLLs is particularly critical, like if it’s loaded into the browser) I’ll happily add it in.

Microsoft Security Essentials/ Windows Defender

I found no executable files not compiled with DEP/ASLR.

Avast! Pro Trial (25)
















/Avast/Setup/INF/aswTdi.sys /





















Avira Premium Trial + Toolbar (41)







/AntiVir Desktop/aecore.dll

/AntiVir Desktop/aeemu.dll

/AntiVir Desktop/aeexp.dll

/AntiVir Desktop/aegen.dll

/AntiVir Desktop/aehelp.dll

/AntiVir Desktop/aeheur.dll

/AntiVir Desktop/aeoffice.dll

/AntiVir Desktop/aepack.dll

/AntiVir Desktop/aerdl.dll

/AntiVir Desktop/aesbx.dll

/AntiVir Desktop/aescn.dll

/AntiVir Desktop/aescript.dll

/AntiVir Desktop/aevdf.dll

/AntiVir Desktop/avacl.dll

/AntiVir Desktop/avevtrc.dll

/AntiVir Desktop/aebb.dll

/AntiVir Desktop/libapr-1.dll

/AntiVir Desktop/libapriconv-1.dll

/AntiVir Desktop/libaprutil-1.dll

/AntiVir Desktop/libdb44.dll

/AntiVir Desktop/rchelp.dll

/AntiVir Desktop/unacev2.dll

/AntiVir Desktop/FAILSAFE/aebb.dll

/AntiVir Desktop/FAILSAFE/aeemu.dll

/AntiVir Desktop/FAILSAFE/aeexp.dll

/AntiVir Desktop/FAILSAFE/aegen.dll

/AntiVir Desktop/FAILSAFE/aehelp.dll

/AntiVir Desktop/FAILSAFE/aeheur.dll

/AntiVir Desktop/FAILSAFE/aeoffice.dll

/AntiVir Desktop/FAILSAFE/aepack.dll

/AntiVir Desktop/FAILSAFE/aerdl.dll

/AntiVir Desktop/FAILSAFE/aesbx.dll

/AntiVir Desktop/FAILSAFE/aescn.dl

/AntiVir Desktop/FAILSAFE/aescript.dll

/AntiVir Desktop/FAILSAFE/aevdf.dll

/AntiVir Desktop/FAILSAFE/aecore.dll

AVG Internet Security Pro (27)

/AVG Secure Search/

/AVG Secure Search_toolbar.dll (Browser componnent it would seem)

/AVG2013/HtmLayout.dll (Also possible browser component)

























McAfee All Access – Total Protection (14)

Note: McAfee became increasingly unstable on my system. I uninstalled it before I could analyze the Chrome extension that it installs.



/McAfee Online Backup/MOBKbackup.exe

/McAfee Online Backup/MOBKconf.exe

/McAfee Online Backup/MOBKshell.dll

/McAfee Online Backup/MOBKstat.exe

/McAfee Online Backup/backup.dll

/McAfee Online Backup/oem.dll

/McAfee Online Backup/MOBK.sys

/McAfee Online Backup/librs2.dll





Norton (17)

/Norton 360/Engine/

/Norton 360/Engine64/

/Norton 360/Engine64/

/Norton 360/Engine64/

/Norton 360/Engine/

/Norton 360/Engine64/

/Norton 360/MUI/

/Norton 360/Branding/ NO ASLR

/Norton 360/Engine/

/Norton 360/Engine/

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/Norton 360/MUI/ NO ASLR

/2013.1.0.32_0/npcoplgn.dll NO ASLR (browser plugin)

Sophos Antivirus (No Firewall) (F-)

It doesn’t seem that any of the executable files support ASLR. Many do not support DEP as well, including quite a few that seem to interact with the web. When your “xmlparser.dll” doesn’t show DEP/ASLR support… yikes. There’s no point listing them all. Sophos gets an F- here.

Panda Cloud AV Pro (42)

/pandasecuritytb/pandasecurityDx.dll (Possibly part of the browser extension)

/pandasecuritytb/pandasecuritytb.dll (Possibly part of the browser extension)

/Toolbar Cleaner/ToolbarCleaner.exe


/Toolbar Cleaner/uninstall.exe

/Panda Security/Panda Cloud Antivirus/cc3290mt.dll

/Panda Security/Panda Cloud Antivirus/bcbie120.bpl

/Panda Security/Panda Cloud Antivirus/MiniCrypto.dll

/Panda Security/Panda Cloud Antivirus/PAV2WSC.exe

/Panda Security/Panda Cloud Antivirus/Pavsddl.dll

/Panda Security/Panda Cloud Antivirus/PSBoot.dll

/Panda Security/Panda Cloud Antivirus/PSBoot.sys

/Panda Security/Panda Cloud Antivirus/pskmad.sys

/Panda Security/Panda Cloud Antivirus/PSUAAlerts.dll

/Panda Security/Panda Cloud Antivirus/PSUNConsole.dll

/Panda Security/Panda Cloud Antivirus/PSUNCtrl.bpl

/Panda Security/Panda Cloud Antivirus/PSUNFwConfig.dll

/Panda Security/Panda Cloud Antivirus/PSUNMsg.dll

/Panda Security/Panda Cloud Antivirus/PSUNPnlConfig.dll

/Panda Security/Panda Cloud Antivirus/PSUNProcMon.dll

/Panda Security/Panda Cloud Antivirus/PSUNReports.dll

/Panda Security/Panda Cloud Antivirus/PSUNScan.dll

/Panda Security/Panda Cloud Antivirus/PSUNSuspects.dll

/Panda Security/Panda Cloud Antivirus/putczip.dll

/Panda Security/Panda Cloud Antivirus/putsig.dll

/Panda Security/Panda Cloud Antivirus/puturar.dll

/Panda Security/Panda Cloud Antivirus/putuzip.dll

/Panda Security/Panda Cloud Antivirus/borlndmm.dll

/Panda Security/Panda Cloud Antivirus/RKPavProc64.sys

/Panda Security/Panda Cloud Antivirus/rtl120.bpl

/Panda Security/Panda Cloud Antivirus/SetupUI.dll

/Panda Security/Panda Cloud Antivirus/bspatch.exe

/Panda Security/Panda Cloud Antivirus/USBVacineDLL.dll

/Panda Security/Panda Cloud Antivirus/vcl120.bpl

/Panda Security/Panda Cloud Antivirus/vclactnband120.bpl

/Panda Security/Panda Cloud Antivirus/vclie120.bpl

/Panda Security/Panda Cloud Antivirus/vclx120.bpl

/Panda Security/Panda Cloud Antivirus/WinSkinc2009.bpl

/Panda Security/Panda Cloud Antivirus/xmlrtl120.bpl

/Panda Security/Panda Cloud Antivirus/DG/MsiZap.Exe

/Panda Security/Panda Cloud Antivirus/DG/PAV2WSC.exe

/Panda Security/Panda Cloud Antivirus/Tools/PandaSecurityTb.exe

Panda left its god damn blekko crapware in my browser.

Comodo CIS (71)

.cav files are definition files, they shouldn’t matter. I realized this partway through and stopped logging them.



/COMODO/COMODO GeekBuddy/uninstall.exe

/COMODO/COMODO Internet Security/cmdagent.exe

/COMODO/COMODO Internet Security/cmdcomps.dll

/COMODO/COMODO Internet Security/cmdhtml.dll

/COMODO/COMODO Internet Security/cmdinstall.exe

/COMODO/COMODO Internet Security/crashrep.exe

/COMODO/COMODO Internet Security/framework.dll

/COMODO/COMODO Internet Security/cfpupdat.exe

/COMODO/COMODO Internet Security/inspect.sys

/COMODO/COMODO Internet Security/msica.dll

/COMODO/COMODO Internet Security/platform.dll

/COMODO/COMODO Internet Security/cfpconfg.exe

/COMODO/COMODO Internet Security/cfp.exe

/COMODO/COMODO Internet Security/cavshell.dll

/COMODO/COMODO Internet Security/signmgr.dll

/COMODO/COMODO Internet Security/cavscan.exe

/COMODO/COMODO Internet Security/7za.dll

/COMODO/COMODO Internet Security/scanners/pe32.cav

/COMODO/COMODO Internet Security/scanners/dosmz.cav

/COMODO/COMODO Internet Security/scanners/dunpack.cav

/COMODO/COMODO Internet Security/scanners/extra.cav

/COMODO/COMODO Internet Security/scanners/gunpack.cav

/COMODO/COMODO Internet Security/scanners/heur.cav

/COMODO/COMODO Internet Security/scanners/mach32.dll /

COMODO/COMODO Internet Security/scanners/mem.cav

/COMODO/COMODO Internet Security/scanners/pe.cav

/COMODO/COMODO Internet Security/scanners/common.cav /

COMODO/COMODO Internet Security/scanners/pkann.dll

/COMODO/COMODO Internet Security/scanners/rkdenum.dll

/COMODO/COMODO Internet Security/scanners/rkdhive.dll

/COMODO/COMODO Internet Security/scanners/rkdntfs.dll

/COMODO/COMODO Internet Security/scanners/script.cav

/COMODO/COMODO Internet Security/scanners/white.cav

/COMODO/COMODO Internet Security/repair/guard32.dll

/COMODO/COMODO Internet Security/repair/7za.dll

/COMODO/COMODO Internet Security/repair/cavscan.exe

/COMODO/COMODO Internet Security/repair/cavshell.dll

/COMODO/COMODO Internet Security/repair/cfp.exe

/COMODO/COMODO Internet Security/repair/cfpconfg.exe

/COMODO/COMODO Internet Security/repair/cfpupdat.exe

/COMODO/COMODO Internet Security/repair/cmdagent.exe

/COMODO/COMODO Internet Security/repair/cmdcomps.dll

/COMODO/COMODO Internet Security/repair/cmderd.sys

/COMODO/COMODO Internet Security/repair/cmdGuard.sys

/COMODO/COMODO Internet Security/repair/cmdhlp.sys

/COMODO/COMODO Internet Security/repair/cmdhtml.dll

/COMODO/COMODO Internet Security/repair/cmdinstall.exe

/COMODO/COMODO Internet Security/repair/common.cav

/COMODO/COMODO Internet Security/repair/crashrep.exe

/COMODO/COMODO Internet Security/repair/default.set

/COMODO/COMODO Internet Security/repair/dosmz.cav

/COMODO/COMODO Internet Security/repair/dunpack.cav

/COMODO/COMODO Internet Security/repair/extra.cav

/COMODO/COMODO Internet Security/repair/framework.dll

/COMODO/COMODO Internet Security/repair/guard64.dll

/COMODO/COMODO Internet Security/repair/gunpack.cav

/COMODO/COMODO Internet Security/repair/heur.cav

/COMODO/COMODO Internet Security/repair/inspect.sys

/COMODO/COMODO Internet Security/repair/mach32.dll

/COMODO/COMODO Internet Security/repair/mem.cav

/COMODO/COMODO Internet Security/repair/msica.dll

/COMODO/COMODO Internet Security/repair/pkann.dll

/COMODO/COMODO Internet Security/repair/platform.dll

/COMODO/COMODO Internet Security/repair/rkdenum.dll

/COMODO/COMODO Internet Security/repair/rkdhive.dll

/COMODO/COMODO Internet Security/repair/rkdntfs.dll

/COMODO/COMODO Internet Security/repair/signmgr.dll

Webroot SecureAnywhere Complete

ASLR/DEP seem to be enabled on all three executable files (including the Chrome extension). Can’t seem to find any others.   If anyone has more info please share.

Bruteforcing 64bit ASLR

A lot of times we hear that it’s impractical or even impossible to brute force 64bit ASLR. It’s been the general consensus that the address space is too large and therefor any attack would be unreliable. On a vanilla implementation of ASLR I think it has become clear that, on its own, a 64bit address space is not enough to prevent bruteforcing ASLR.

A paper recently set out to attack 64bit ASLR to see how effective bruteforcing can be. It’s important to note that they don’t take any other modern mitigation techniques into account, such as NX.

The paper shows a primitive attack against 64bit ASLR on their Linux system can take as few as 1.3 hours but as many as 34.1 hours. They note that they could optimize and improve the performance quite a bit. To me I think it’s really important to note that there’s significant variability here – an attacker can not rely on bruteforcing to be done in 1.3 hours, they could potentially have to wait quite a lot longer. That variability and uncertainty is important.

The paper then goes on to mention PaX ASLR, which introduces far more entropy into the system. Due to the papers very narrow focus on ASLR it, again, leaves out other mitigation techniques, such as the Grsecurity patchset’s Exploit Bruteforce Prevention. There are actually numerous PaX and Grsecurity mitigation techniques that could be implemented to prevent these attacks but the focus is less about “real world” and more about proving that 64bit ASLR on its own is not enough to prevent bruteforce attacks.

So while it’s clear that on a process that doesn’t use NX or modern mitigation techniques other than ASLR that bruteforcing is potentially possible, it’s incredibly unlikely that you’re running any programs that don’t use those techniques. Anyone who uses PaX ASLR with Grsecurity likely has multiple mitigation techniques designed to prevent these attacks. These attacks also would likely cause program instability, and are still somewhat impractical even if they can be optimized. But, to say that ASLR can not be bruteforced only due to a 64bit address space would be incorrect.

Windows 8 Takes ASLR To The Next Level

Microsoft has recently released the latest version of Windows dubbed Windows 8. The operating system features, among other things, a new user interface called Metro, which has been fairly controversial. On top of the user interface Microsoft has taken serious efforts to improve security – Windows 8 includes a far stronger implementation of ASLR.

ASLR (Address Space Randomization)

Address Space Randomization, or ASLR for short, is an exploit mitigation technique invented by the PaX team. The idea is that attackers generally need to know where code is in a processes address space in order to carry out attacks. ASLR, as the name, randomizes the address space and makes it more difficult for attackers to exploit programs.

More Areas Randomized

One of the issues with ASLR is that if any area of address space isn’t randomized it can mean a full bypass for an attacker. Windows 8 now randomizes many new areas of the address space. Most significantly, all bottom up allocations (VirtualAlloc() VirtualAllocEx()) are now randomized, which closes up holes like this one. All bottom up and top down memory allocations being random makes the implementation of ASLR far better than in Windows 7.

One bypass of EMET 3.5 relied on a universal ASLR bypass using predictable pages and an information leak. Those (specific ones) are now gone.

Higher Entropy

ASLR randomizes allocations but if those randomized areas of memory are predictable an attacker can bruteforce their way to a useful area. Windows 8 has added significantly greater entropy to top down allocations and also added an opt-in feature titled High Entropy ASLR, which increases entropy across the board for all areas of address space. On a 64bit system it becomes unlikely that an attacker will bypass ASLR through  bruteforcing as the address space is much larger – though this large address space is not necessarily enough.

Force ASLR

Another very significant feature of Windows 8 is native support for Force ASLR. As I stated above a single area of address space being predictable is often enough for an attacker to bypass ASLR entirely and Force ASLR is built to ensure that no areas can be predictable. Often times when we run a program we add plugins or third party extensions – a web browser binary extension for example, or a program that adds a context menu to explorer.exe – and these third parties may not have enabled ASLR on their software. On Windows 7 and previous this would have meant an attacker could predict that area of address space and bypassed ASLR but not on Windows 8. With Force ASLR enabled all non-ASLR modules injected into a process are forced to use ASLR as wellm thus ensuring the entire process is randomized.

The improvements don’t end there but those three have the largest impact (as well as no more USER_SHARED_DATA bypasses). It’s clear that Microsoft has put effort into making Windows 8 their most secure operating system yet. When mainstream programs begin to make use of these mitigation techniques attackers are going to be forced to start finding other avenues of attack.

ATI Drivers 12.6 Support ASLR!

I’m very pleased to announce that ATI is now supporting ASLR for its 12.6 beta drivers. This is great news as I’ve blogged about this stupid design decision in the past.

Thanks commenter tedbrogan for bringing this to my attention.

With the GPU Drivers now supporting ASLR many systems will be able to enable ASLR system wide. ASLR depends heavily on all areas of an address space being randomized so this is fairly significant.

Get your ATI Drivers here:

Another Universal ASLR Bypass Demonstrated

I’ve talked about ASLR issues in the past due to Windows/Linux implementation issues. It’s become more common to see these issues get exploited lately, though still surprisingly few times.

The most recent bypass was with Adobe Reader X and you can read about it here.

Basically some address doesn’t get randomized (VirtualAllocEx maps don’t randomize for some reason) and so they can insert their own ROP code.

There is no way to solve this without Windows picking up slack and randomizing more areas of address space/ specific calls (ie: what PaX does for mmap() base addresses and the hardened toolchain.)

Thankfully this shouldn’t bypass the Reader sandbox and it should be avoidable without Javascript enabled. EMET users are also safe against ASLR bypasses because they’ll benefit from EAF, though EAF is trivially bypassed.

A reminder that implementation flaws in something like ASLR are still around today even though it’s been years since PaX demonstrated the technique.

This vulnerability is pretty interesting and actually makes use of an issue in the sandbox having to do with the IPC handling of syscalls. For more on that you can read the actual post. While the way the sandbox is handled provides an avenue of attack the fault here is most definitely on Windows.

New Anti-ROP From Microsoft

Microsoft held a contest for computer scientists to come up with new ways to stop Return Oriented Programming (ROP) – a  technique used by hackers that allows them to easily bypass Data Execution Prevention (DEP.) Currently the most common anti-ROP technology is ASLR, headed by PaX. ASLR attempts to randomize as much of the address space as possible, which makes it difficult for hackers to find code that they can use for ROP. ASLR leaves much to be desired as if any part of the address space is not randomized it’s enough for an attacker to craft a ROP attack. There will always be static areas of address space.

Other techniques like EAF aren’t great, better for legacy exploits. And I’ve written before about techniques for defeating ROP.

Microsoft’s competition yielded three ‘top’ contributions and while the details aren’t entirely revealed I’m gonna comment on each based on the very tiny amount of information provided.

First is Jared DeMott’s /ROP.

To understand it you should know that ROP basically works by taking the compiled library and controlling the order that it executes… sorta. It means that absolutely no new code needs to be added to exploit the system.

The idea of /ROP is to check return instructions. This seems like a great idea, after all, return oriented programming without the return… just doesn’t work.

Without details it’s hard to criticize except that you don’t need return instructions for ROP. You can use ‘return-like’ instructions, which can do the same thing and create exploits just as well. What about jmp?

It’s also a detection system and only works on *known* areas of ROP. That doesn’t sound like such a big deal but it really is. It doesn’t stop anything fundamental, not really, and it’s reactive.

 Ivan Fratric

Ivan’s works by labeling specific functions as critical for ROP. And when those functions are called a check is made.

This reminds me a lot of EAF. We’ll see how it works and if it works in the real world.

Again, detection.

Vasilis Pappas

No clue how this one will work out, not enough detail given at all to make any kind of statement.

If one could simple remove the ability to ROP with magic or some such thing it would force attackers to come up with entirely new methods of exploitation. ROP is the way to get into a system right now. Hopefully one of these really does the trick. Personally I don’t quite understand why specific libraries aren’t compiled without gadgets – there are a few universally static areas of the Windows OS, why not just remove the gadgets? I really don’t know, probably some patenting bullshit.

Hopefully one of these actually drives up the cost. There just isn’t a ton of information out there right now.

I’d love to see more of these types of bounties in the future. Not patches, actual new techniques.

Looks Like CERT Reads InsanityBit

Only joking, of course but coincidentally has written a post highlighting something I’d mentioned a few days ago. There’s the bit about EMET for Full ASLR, which I wrote about here and AMD/ATI using a hardcoded address space, which I wrote about here.

I’m really happy to see this getting attention from CERT, which is just way more legit than my blog. Hopefully they’ll get ATI to fix their crap.

P.S. CERT, tell them to fix the overflow in 12.3 as well. It’s annoying.

Universal ASLR Bypasses And How To Solve Them

Address Space Layout Randomization is an exploit mitigation technique that focuses on preventing Return Oriented Programming attacks. It’s become one of the “must have” tools for a secure program (like DEP) and it’s preset in all modern user-oriented operating systems.

Mitigating ROP is pretty important as most modern exploits take advantage of it. And ASLR would be entirely effective in an ideal world where every single part of address space is randomized and 64bit address space is impossible to bruteforce and heapspray doesn’t exist. We don’t live in that world and there are universal ASLR bypasses for Windows and Linux, heapspray does exist, and the majority of users are stuck in a 32bit address space (and 64bit vanilla ASLR isn’t necessarily impossible to bruteforce).

Windows is actually pretty on top of things with ASLR (as of Windows 8) and /FORCEASLR but there’s always going to be a way around it (unless some things seriously change.)

So what’s the answer?

Well, for non-performance critical applications perhaps a solution like Gadgetless Binaries would be a viable option. Gadgetless binaries would compile code in such a way that an attacker would be unable to make use of static address space instructions to form their attack.

There is a performance hit here so I’m not saying to compile everything with it, but for security critical applications why not? There are specific areas of Windows address space that are loaded in the same exact place every time – why not compile that area with gadgetless binaries and avoid situations like this?

There’s also a somewhat less effective In-Place Code  Randomization technique and even less effective (though still welcome) EAF, which is what Microsoft has implemented.

Perhaps I’m just missing something. Maybe this would require paying out or some such thing but it seems like a great idea to me as ASLR isn’t going to solve every problem. At least not with current implementations (outside of PaX ASLR, which makes use of many other features via Grsecurity to prevent attacks against ASLR).


A Tip For Those Looking To Lock Down Windows

In my last post I explaining why I won’t be buying ATI until they fix their insecure drivers. This reminded me that Windows does actually have a little-known ability to run the entire system with ASLR enabled. Of course, this can lead to instability and in the case of those of you running ATI cards you will BSOD immediately but if you’re willing to take the risk it’s one more way to lock down Windows.

First, I suggest you take a look at this guide for securing Windows and this guide for setting up EMET.

This short guide will get your ASLR Always On setting enabled in the EMET User Interface.

If you’ve followed the guides you can:

1) Open Regedit


3) Change ‘EnableUnsafeSettings’ to ‘1’

4) Go to your EMET GUI and System Settings – turn ASLR to Always On. If it isn’t there you may need to reboot first.

5) Reboot

Your system might crash in which case you need to go into Safe Mode and disable this. It should go without saying that this risk falls on you, I’ll feel pretty bad if I break your computer but there’s fair warning here.

So now instead of applications having to explicitly opt into using ASLR on Windows your entire system should be running with it. This will probably break a few programs but if it works, great, you’re somewhat potentially more secure.

Why I Won’t Be Buying ATI Again

I run a nice midrange laptop with a nice i5 520m, 8GB of RAM, a hybrid drive, and an ATI 5650.

The performance is really exactly as I’d expect, I can play the games I want to play and I can watch HD videos while I browser and talk to friends all at once without a stutter and without my computer burning up.

The GPU has performed admirably and I’m entirely happy with its performance.

But AMD for whatever reason (I guess performance) will not work with PAX or full system ASLR. There are actually buffer overflows in the code that prevent me from turning ASLR on to the full extent that I’d like and because of the hardcoded address space I can’t (at least on Windows) turn ASLR to anything other than “Application Opt-In.”

That’s really not acceptable. GPU security issues aren’t super new and they’re plenty talked about. I get that in the past it wasn’t a priority, of course. But things have changed. We have OpenGL now and we have the GPU integrated into virtually every process. The GPU isn’t just about games (which are also now online) it’s used in everything… like my browser (or this?), like Flash, my UI, and multiple other programs.

AMD/ATI, step it up. I may not be buying another system for years but if I were buying one tomorrow I’d go nVidia.