Slashdot Mirror

← Back to Stories (view on slashdot.org)

AMD/ATI Video Drivers: Unsafe At Any Speed

Posted by timothy on from the hey-man-we've-all-got-problems dept.

An anonymous reader writes "CERT/CC has called out AMD for having insecure video drivers. AMD/ATI video drivers are incompatible with system-wide ASLR. 'Always On' DEP combined with 'Always On' ASLR are effective exploit mitigations. However, most people don't know about 'Always On' ASLR since Microsoft had to hide it from EMET with an 'EnableUnsafeSettings' registry key — because AMD/ATI video drivers will cause a BSOD on boot if 'Always On' ASLR is enabled."

6 of 261 comments (clear)

  1. Re:There is nothing in this story connecting ATI/A by tlhIngan · · Score: 4, Informative

    The story is about DEP and ASLR effectiveness at blocking exploits. IT has nothing to do with the title or the ATI/AMD aspect.

    The CERT article mentions it, and it mentions it in that you cannot use the DEP/ASLR protections (in the kernel) because ATI/AMD make an incompatible driver. And since graphics drivers are kernel things, loading them means the kernel must disable DEP/ASLR, making your machine just that much less secure because of it.

  2. Re:AOD by noh8rz3 · · Score: 5, Informative

    aslr = a way to secure your memory so it's harder for malware to run attacks.
    EMET = a bunch of tools that windows uses to secure the machine. aslr is one of these tools
    bsod = blue screen of death. your computer is frozen
    AMD = a company that was formerly known for making computer chips, but is now in the graphics card business
    ATI = a graphics card manufacturer that AMD bought.
    DEP = another tool in the EMET toolkit.
    cert/cc = an organization that is viewed as an authority on computer stuff.

    in short, AMD drivers suck so much that microsoft has to override its own computer protections to keep AMD from crashing your machine. so the drivers are not just unstable, they make your machine more vulnerable to malware. cert says, "epic fail".

  3. Re:ASLR by blackraven14250 · · Score: 5, Informative

    Better to prevent yesterday's attacks at all than to leave the hole open for all time...

  4. Re:AMD's proprietary Linux driver is secure... by TeknoHog · · Score: 4, Informative

    $ lsmod | grep fglrx; uptime
    fglrx 3029147 144
    agpgart 26120 3 intel_gtt,intel_agp,fglrx
    22:41:37 up 76 days, 4:30, 8 users, load average: 0.00, 0.01, 0.05

    --
    Escher was the first MC and Giger invented the HR department.
  5. But it still showed you the article content! by Anonymous Coward · · Score: 4, Informative

    ... you failed to mention that. Oh, right. Your goal was to be sensational. Carry on.

  6. Re:AOD by Mr+44 · · Score: 3, Informative

    Uhh, no. Windows DLLs have always been relatively addressed, and are capable of being loaded at different locations in the virtual address space (google "rebasing"). However, for performance reasons, most DLLs specify a preferred address the loader will attempt to slot them into. All system DLLs specify this, which results in their routines being loaded at predictable addresses (even across machines).

    ASLR means that, on boot, a different location is chosen in the virtual address space to load DLLs into, so that system routines are not always at the same location, making certain types of security exploitation significantly harder.