In a bit of an odd move, the Carnegie Mellon's Computer Emergency Readiness Team (CERT/CC) has posted a vulnerability report and a blog post taking AMD to task over their drivers and the impact on system security. As the major partner in the United States’ internet security agency US-CERT and de-facto coordinator for the international CERTs, CERT/CC is both a front-line organization for developing responses to cybersecurity threats and on a more typical day is responsible for organizing and publishing reports and notices about computer system vulnerabilities. So while it’s common for CERT/CC to publish information regarding specific vulnerabilities, it’s less common for them to get involved with general security weaknesses in this manner.

So what has drawn CERT/CC’s attention? It turns out that AMD’s drivers don’t properly behave with/support a vulnerability mitigation feature called Address Space Layout Randomization (ASLR). ASLR serves to make it harder for software vulnerabilities to be exploited by randomizing certain program structures in memory, so that the addresses of these structures cannot reliably be predicted and attacked. Although not undefeatable, ASLR can reduce a number of different types of attacks from a system-owning exploit into a program crash that keeps the system secure. In other words ASLR can’t fix the underlying vulnerabilities in programs, but it can help mitigate the problem so that a proper fix can be instituted.

Because of the chaotic nature of ASLR not every program (particularly legacy programs) can work with it, and for that reason since its introduction in Windows Vista in 2006 ASLR has been a per-program feature that is only enabled with applications that are flagged as being compatible. However because most applications can handle it just fine, systems requiring higher security can use the Enhanced Mitigation Experience Toolkit (EMET) to enable ASLR across the system, which forcibly activates ASLR for all programs.

It’s this last bit that has caught CERT/CC’s attention. As it stands AMD’s video drivers are not ASLR compatible. Turning on ASLR will cause AMD’s drivers to crash, making always-on ASLR unusable on systems using AMD’s drivers.

From a practical perspective this isn’t an issue that affects more than a handful of users. Unlike DEP it’s not something that can be turned on from within Windows, so even technical users like ourselves almost never have ASLR in always-on mode. However for governments and other high value institutions this means they’re forced to choose between AMD hardware and ASLR, which is not something they want to be worrying about. Furthermore it’s been the long-standing goal of computer security organizations to get OSes and programs to a state where ASLR can be enabled globally for every user, a very messy transition that is held back by programs and drivers that are still not ASLR compatible.

Drivers in turn are of particular concern here because of how they interact with the Windows kernel, with video drivers in particular having high access levels for performance purposes, a position that will only become more entrenched as GPUs continue to become more CPU-like and more important to even fundamental computing. All of this is compounded by the fact that AMD in has already been in the spotlight for security vulnerabilities as their drivers were found to have a security exploit in 2007.

Ultimately CERT/CC is looking to apply pressure to AMD to get them to finally make their drivers ASLR compatible, even going so far as to specifically testing and naming Intel and NVIDIA as having ASLR compatible drivers in the vulnerability note. Because of their relationship with US-CERT this is akin to having an arm of the US Government breathing down your neck, which does tend to get results, doubleplus so since the US Government is also a massive IT buyer. In the meantime typical computer users have nothing to be concerned about – and this is the important part for most of us – but it’s unfortunate that AMD has let themselves end up in this situation in the first place.

Source: Slashdot

Update: CERT/CC contacted us this afternoon to clarify who originated the vulnerability report in question. It is technically CERT/CC who published it (in spite of it appearing on US-CERT), so we've corrected the article accordingly.

Update 2: AMD has issued a formal statement in response to CERT/CC's report. In it they assert that the specific condition CERT/CC specifies (modifying a registry key) was not reported in advance, and go on to reiterate that regular users (even those using EMET) are not impacted by this. Furthermore AMD states that they are working on a driver that corrects the issue CERT/CC has discovered. We have republished the full response below

CERT recently approached AMD with information pertaining to what they believed to be a possible video driver vulnerability exposed by non-default settings of the Microsoft Enhanced Mitigation Experience Toolkit (EMET). EMET is a security test tool that allows system administrators to create test conditions to validate correct behavior of system components or indicate potential weak points. The presence of an issue does not necessarily mean that this issue can be exploited in regular operation of a system. The default safety settings of the EMET do not cause the issue in question to occur.

The non-default settings used to produce the system crash at start-up as reported by CERT require changing a System Registry key for the tool (named "EnableUnsafeSettings"), which was not documented until the CERT report was published, and is not accessible through the EMET tool itself.

Given that the conditions created by CERT are a departure from the default safety settings of the Microsoft EMET, users of AMD graphics products will face the problem outlined by the CERT report if their EMET settings are modified, and will otherwise not experience the issue in question. Shortly, AMD will release a driver designed to ensure that a crash does not take place under the conditions outlined by CERT.

Comments Locked


View All Comments

  • CeriseCogburn - Tuesday, June 12, 2012 - link

    ROFL - another amd apologist. Way to go know it all. Yes, the government should be doing what you say. LOL
  • Beenthere - Friday, June 8, 2012 - link

    Like I'm sure most PC users are worried about their AMD GPU drivers being hacked to bring the U.S. to it's knees by some rogue (Nvidia employee) hacker... PLEASE?
  • whatthehey - Saturday, June 9, 2012 - link

    Go away, AMD toolboy; the adults are trying to have a discussion. Only a seriously stupid person would take information released by CERT/CC showing a minor issue with AMD and turn that into an anti-NVIDIA comment. Good thing most US employees are likely using Intel or NVIDIA GPUs anyway. For most, it will be Intel IGP solutions while for higher end users it will be NVIDIA Quadro (which smokes the shorts off of AMD's FireGL stuff). And if you have a laptop that for some reason has a discrete GPU it will have NVIDIA as well.
  • gordon151 - Saturday, June 9, 2012 - link

    You seem more delusional than you accuse him of. AMD graphics is a huge part of enterprise systems on the private and government level. Both on desktops and laptops. I think AMD would have to start bundling viruses with their drivers for the market to shift to scenario such as what you claim.
  • CeriseCogburn - Sunday, June 10, 2012 - link

    Well if amd is a huge part of the government level, then they had better get off their dead fail bottom and bring it up about 5 notches.

    Thanks at least we now know how China stole all the MIRV secrets and everything else besides the fraudulent cisco router back doors.

    I appreciate that amd fan - yes it's a huge part of government enterprise with it's cavernous gaping vulnerability - way to go, you're a great amd spokesperson, while the other person likely wanted to calm his patriot nerves, you sure wrote the book straight for him....

    AMD has sold crap to our government and cost us taxes while our secret info bled forth...

    Love it, I'm so glad amd is a huge part of the government enterprise space-- thanks so much mr amd know it all.
  • whatthehey - Sunday, June 10, 2012 - link

    Directed at gordon151:

    Do you actually work for the government? Because I'd really like to know what they're doing with all those AMD graphics in their enterprise systems. Are you talking about the old Rage IIc chipsets used on many servers, which really aren't used 99% of the time because the servers are headless? Or are you talking about all the rank and file employees with desktops and laptops that do basic office tasks and for some reason apparently have AMD GPUs?

    I work in IT for a large corporation, and the US government is the largest corporation in the country. I can count the number of systems in our datacenter and location that have discrete GPUs on my two hands (eight, if you're wondering). Out of nearly 500 laptops and desktops and servers, we have eight systems right now with discrete graphics. They're all in one department that uses Photoshop and some other professional apps.

    Everyone else is running Core 2 or first generation Core i-series processors, with a few select people having been upgraded to second generation Core i-series systems in the last six months. They're all running Office applications for the most part, with some in-house software that basically requires no resources (think text-based interfaces and telnet sessions). We did make the migration to Windows 7 during the past year (having skipped Vista completely), which was a ton of work for our department. There are still plenty of people not happy with the change from XP.

    THAT is what IT is like in the real world for 99% of large businesses and corporations. Sure, there are some companies that specialize in areas that need graphics and they'll have GPUs, but the government? What are they doing precisely that AMD GPUs are such a "huge part of enterprise systems" for them?

    But this is all beside the point. The original comment was directed at Beenthere with his stupid ass attempt to shift an article about a security flaw in AMD's drivers and create a subject about how NVIDIA is desperate and maybe hiring hackers. You can't seriously think such a tangent is anything but idiotic and fanboytastic, can you?

    PS: All the government offices I've been to in the past year or two (DMV, a court house, post office, etc.) are running basic PCs from HP or Dell, and I'll bet my SSD not a single one of those systems is using a discrete GPU.
  • Solidstate89 - Friday, June 8, 2012 - link

    Thanks to this article/report I just checked out EMET as I've never heard of it before.

    Very neat piece of software and piss-easy to use. Thanks for (inadvertently) pointing out such an awesome utility by reporting on this. I definitely plan on using this on my desktop.
  • Beenthere - Saturday, June 9, 2012 - link

    SOS, DD.
  • Ryan Smith - Saturday, June 9, 2012 - link

    No, it's still important. Always-on ASLR isn't commonly used (or even uncommonly used), but it is used.
  • CeriseCogburn - Sunday, June 10, 2012 - link

    Nice response amd...I'm sure you'll get all those big dollar government and large dollar institution sales now...

    That's nice amd - amd says amd will do something so their driver doesn't crash when always on everything mode is selected, but they won't be making their driver ASLR compliant any time soon, as it was only desired since Vista was released so many years ago...

    Some amd cheapo hack trick should do, instead, so their crapster driver doesn't take down the whole system...

    ROFL - they so suck

    I thank CERT CC for pointing out nVidia and Intel are already fully ASLR complaint. Someone needed to kick the traitor amd company.... amd loved by crackers and terrorists and espionage worldwide.

Log in

Don't have an account? Sign up now