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 - Monday, June 11, 2012 - link

    Yeah, sure amd fan boy
  • CeriseCogburn - Monday, June 11, 2012 - link

    Intal and nVidia didn't have a problem, they handled it - there would be no problem if amd didn't fail yet again this time.

    It's amd, amd fan boy. Race up to it, be a man.
  • greylica - Monday, June 11, 2012 - link

    You're making a great confusion, perhaps because you haven't been in the Image industry or because you never study GPU driver problems.

    *Intel - poor OpenGL device drivers all over the entire line up ( I don't know for HD 4000/5000, not tested yet ),
    *Nvidia - create artificial limitations on hardware to sell Quadro, overbloated drivers, with lot's of specific hacks to diminish OpenGL performance.
    *AMD - the worse driver install in the linux world, and at every new line of cards, they drop support for a bunch of them, leaving users with no choice.

    May be you're biased guys, I'm not talking about AMD, I'm talking about a general situation about GPU device drivers and you're trying to corrupt the texts. You're the real biased, not me.
  • CeriseCogburn - Tuesday, June 12, 2012 - link

    No you're the one complaining that "gpu makers" don't give you every intricate detail of source so in an article of AMD failure, you forget that entirely and blame it on the way the "industry" does business.

    Well Intel and nVidia did industry business just fine with ASLR, and amd the failure did not. AMD has to make the driver fix, and it appears they still won't be compliant.

    I'm sure you'd love all their code so you could (or other dream entities you may choose) create the driver that is always good and always gets fixed by yahoos such as yourself or the great unwashed free coders of the world, huh. Then you can have something much better than the companies themselves, or so you appear to think. WHO CARES.

    AMD has FAILED, that's what matters - and Intel and nVidia have not - but if they'd only listen to you there would be no virus issues and security issues that aren't fixed pronto, by you and your imaginary workforce.

    Intel and nVidia don't need you or your imaginary workforce, only AMD does.

    Have fun moaning, amd fan.
  • triarii - Friday, June 8, 2012 - link

    so basically, by finding and flipping one bit a virus writer can bring down all machines with AMD drivers. brilliant.
  • DaveSimmons - Friday, June 8, 2012 - link

    If they have that level of access they can just format your hard drive instead.

    But most malware writers these days do it for the money, to add your PC to their botnet. They have no interest in petty vandalism.
  • Penti - Friday, June 8, 2012 - link

    You can crash any driver risking the machine going down mostly without any privilege-escalation so that is nothing new. ASLR don't protect against bugs and built in vulnerabilities, it only addresses buffer overflow attacks. Not all exploits is based on those scenarios. It also doesn't mean you can't conduct buffer overflow attacks successful. There are still vulnerabilities in OS and software.

    I do see why the government and authorities wants it enabled, it does reduce the chance for some attacks, make those attacks harder, but I more see it as just another deficiency for AMD in the enterprise market where they are pretty weak. It's mostly populated by Intel desktops and notebooks any way, AMD don't have a chance, but it will be a problem for workstations and notebooks with AMD graphics. More lost opportunities for AMD. I think they should take the market serious and have clients that can compete with say Intel AMT (VNC/KVM over SOL, and other management features) DASH isn't there as it is implemented and pair it with AMD graphics (or APUs.). As long as I don't see any AM3+ systems I'm happy with that and some better support any way.
  • Wreckage - Friday, June 8, 2012 - link

    Amd drivers are so bad... bad are they?
    They are so bad that if you try to enable security your system
  • eachus - Saturday, June 9, 2012 - link

    Read the article before posting, including the AMD response:

    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.

    An undocumented Registry key named "EnableUnsafeSettings," really sounds like something you want to use on a secure system...

    Now worry about something that you can do something about. CERT/CC (not US/CERT) broke lots of rules publishing this in this way. Yes, this is a non-issue which would normally be deal with in the normal course of business. There is no security risk, serious or otherwise, with AMD drivers, except in some tester's head. There is a serious issue when undocumented security tool settings get generally published. Just because this one is a non-issue, doesn't mean the next one will be.
  • Solidstate89 - Saturday, June 9, 2012 - link

    The only thing that registry key does is enable the option to make ASLR Mandatory instead of just Opt-in. So if you want the highest security levels possible, than yes, that would make for a secure system.

Log in

Don't have an account? Sign up now