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

51 Comments

View All Comments

  • _vor_ - Tuesday, June 12, 2012 - link

    Seriously guy, find a different hobby already. I grow tired of your exaggerated and panicked trolling propaganda.
  • CeriseCogburn - Sunday, June 10, 2012 - link

    Since out US government never responds, as most republics of it's nature, until after an enormous problem comes crashing down on their heads and everyone else's - it is clear a huge security breach hole already occurred.

    I'm sure it's national security information so we won't be hearing about it right away if ever, but the unusual nature of the warning and posting indicates we've already lost a motherlode.

    NOTE: THE major partner
    " As the major partner in the United States’ internet security agency US-CERT and de-facto coordinator for the international CERTs.."

    NOTE: Unusual involvement

    " 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 ... "

    So what we have here is a major US take down, and the reaction... from the "bungling bureaucrats" to plug the open hole that has existed for a long, long time... and now it's important because someone (foreign gov crackers no doubt) USED IT...

  • Taft12 - Friday, June 8, 2012 - link

    Interesting article, thanks for the summary Ryan. This doesn't affect you or I but it could cost AMD some gargantuan GPU computing project contracts within the governments of the US and other countries too. Consider the notice served.
  • CeriseCogburn - Sunday, June 10, 2012 - link

    Amd is "open source" so this isn't a problem for them. They like being an "open system" with open source drivers ...

    Par for the fail course amd
  • greylica - Friday, June 8, 2012 - link

    Free drivers can solve the problem for all manufacturers. Closed source drivers allowing DEP won't solve the problem, or the flaw (they could only cover them for a brief period).
    Closed source drivers will only help manufacturers to spread more FUD using patent excuses until a cracker touts the damn closed thing to discover a ''special'' function that was never exploited, because it was never published, and then, more virus and exploits for Windows, Mac and probably causing also causing victims in Linux users of those ''proprietary drivers''...

    Do you see how closed source drivers are unsafe ?
    No one could prevent when a function we don't know will be used against users...

    Free drivers are the only solution for any of the Oses.
    Publish the command table for the cards and the community will help you address those flaws forever. The free software community has been asking for free drivers (or a list for the cards commands and capabilities) for a long time...

    ;)
  • Senti - Friday, June 8, 2012 - link

    Agreed. Closed source OR security – choose one.
    I don't quite get what they fear not opening driver sources. That people will find out that all major games have dozens of hacks for them to not only work faster but just work at all? What a surprise, who could thought! That competitors will copy the same hacks? I'm sure they reverse engineer others' drivers anyway and will get the same information, just maybe some days later.

    The worst is when they decide that some hardware is now "deprecated" and won't be supported. It doesn't bother them that it works just fine and do the required job – no support, no (security) updates.
  • JarredWalton - Saturday, June 9, 2012 - link

    The problem the GPU makers imagine is that drivers access the hardware at a very low level and thus only work optimally if they have complete knowledge of the caching system, instruction latencies, etc. Basically, the only way to create a good driver is to post detailed information about every piece of the hardware architecture. That would expose all the strengths and weaknesses, and potentially allow a competitor to take advantage of the information.

    Now, the flip side is that the CPU people have basically been doing this for years, because you can't make a good compiler for an architecture without such details. So far, I don't know that anyone has really tried to clone Intel or AMD hardware because of the information.
  • greylica - Saturday, June 9, 2012 - link

    By the updated response, they will create another driver. It shows that the GPU manufacturers insists to maintain the root cause for PC troubles and unsafe operation nowadays.
  • CeriseCogburn - Saturday, June 9, 2012 - link

    Wait a minute, it's the gpu makers - it's AMD - can't you say it ? AMD is failing her - I swear to god you people do it every time - if amd fails, it's "the industry" or "gpu makers" - it's really sad the bias is so deep.
  • greylica - Sunday, June 10, 2012 - link

    No it's not the bias, there are lot's of things wrong with GPU makers. Why they still refuse to give informations for simple things as GPU commands ?

    When you buy a product, you have the right to know how to use it.
    Why can't we have the information of the GPU commands ?
    This is what we are talking here, most of the card makers and CPU makers in the world give the programmers, a manual of how to work with their equipment.
    GPU makers insists in covering things from coders...
    That's what we are talking here.
    If you trust them blindly, go ahead saying that this is ''bias''...

    I can't share the same opinion about this.

Log in

Don't have an account? Sign up now