Friday, January 24th 2020
AMD Quietly Patched Four Major GPU Security Vulnerabilities with Radeon 20.1.1 Drivers
If you haven't updated your AMD Radeon drivers in a while, here's one major reason to. The company secretly patched four major security vulnerabilities affecting Radeon GPUs, in its recent Adrenalin 20.1.1 drivers, with no mention of doing so in its changelog. Talos Intelligence reports four vulnerabilities, which are are chronicled under CVE-2019-5124, CVE-2019-5146, CVE-2019-5147 and CVE-2019-5183. This class of attacks exploits a vulnerability in the AMD Radeon driver file ATIDXX64.dll, which can lead to denial of service or even remote code execution. What makes things much more serious is that this attack vector can be used to exploit the host machine from a VM (tested with VMWare). It even seems possible to trigger the vulnerability from a web page, through WebGL (which allows running 3D applications on a remote website). The vulnerabilities were tested on Radeon RX 550 / 550 Series VMware Workstation 15 (15.5.0 build-14665864) with Windows 10 x64 as guest VM, but there is no reason to assume that the issue is limited to just RX 550 as the AMD shader compiler shares a common code basis for all recent DirectX 12 GPUs.
All vulnerabilities rely on a common attack vector: specially crafted shader code that exploits bugs in the shader compiler. Even though HLSL shader code looks similar to assembly, it actually is a relatively high-level language that gets optimized and compiled by the graphics driver. VMWare's graphics acceleration lets you run 3D graphics in virtual machines, by passing along rendering info to the host GPU and then funneling the output back into the VM. Since the shader code gets compiled using the graphics driver of the host OS, this creates interesting opportunities for attacks.Normally you'd expect the shader compiler to properly check all code it compiles and simply reject things that aren't supposed to work.
The last vulnerability is more serious, because it potentially allows remote code execution. If you pass a properly crafted shader, you can execute vTable methods, which give you control over code flow, instead of crashing with an error. With further bug exploitation that would let you execute arbitrary code that you supply.
All four vulnerabilities have been patched with Adrenalin 20.1.1 drivers. AMD rival NVIDIA also battles security vulnerabilities in secret, but the company tends to be more transparent in mentioning vulnerabilities patched in its driver release-notes. AMD's release notes for 20.1.1, in contrast omit any mention of the vulnerabilities, so most people aren't even aware that they should update their drivers to fix a security issue.
Sources:
Talos Intelligence 1, 2, 3, 4
All vulnerabilities rely on a common attack vector: specially crafted shader code that exploits bugs in the shader compiler. Even though HLSL shader code looks similar to assembly, it actually is a relatively high-level language that gets optimized and compiled by the graphics driver. VMWare's graphics acceleration lets you run 3D graphics in virtual machines, by passing along rendering info to the host GPU and then funneling the output back into the VM. Since the shader code gets compiled using the graphics driver of the host OS, this creates interesting opportunities for attacks.Normally you'd expect the shader compiler to properly check all code it compiles and simply reject things that aren't supposed to work.
- The first vulnerability, CVE-2019-5146, is briefly described as "AMD ATI Radeon ATIDXX64.DLL MAD shader functionality denial-of-service vulnerability."
- CVE-2019-5147 describes "AMD ATI Radeon ATIDXX64.DLL MOVC shader functionality denial-of-service vulnerability."
- CVE-2019-5124 points to "AMD ATI Radeon ATIDXX64.DLL shader functionality constant buffer denial-of-service vulnerability."
- CVE-2019-5183 talks about "AMD ATI Radeon ATIDXX64.DLL shader functionality VTABLE remote code execution vulnerability."
The last vulnerability is more serious, because it potentially allows remote code execution. If you pass a properly crafted shader, you can execute vTable methods, which give you control over code flow, instead of crashing with an error. With further bug exploitation that would let you execute arbitrary code that you supply.
All four vulnerabilities have been patched with Adrenalin 20.1.1 drivers. AMD rival NVIDIA also battles security vulnerabilities in secret, but the company tends to be more transparent in mentioning vulnerabilities patched in its driver release-notes. AMD's release notes for 20.1.1, in contrast omit any mention of the vulnerabilities, so most people aren't even aware that they should update their drivers to fix a security issue.
41 Comments on AMD Quietly Patched Four Major GPU Security Vulnerabilities with Radeon 20.1.1 Drivers
AMD has a very Bad reputation of doing such things and this is Not new for experienced IT professionals. Just read this, please...
One important thing to keep in mind when hearing about vulnerabilities and claims of "arbitrary code execution", is that in most cases it only means they have found a buffer overflow problem, which in theory can lead to arbitrary code execution without protections, therefore concluding that this vulnerability can do that as well. All modern desktop operating systems and hardware have "NX bit" to stop this from happening. There may be embedded systems which lacks this kind of protection, but PC owners should not worry about getting compromised, in worst case they will get stability issues from the kernel terminating the processes, which would of course be annoying.
I would like to know more details about what the underlying problem in the compiler was, and how it was fixed. If this was a concrete logical mistake in the compiler which was properly solved, then all should be good. But if all they did was to add a detection of an edge-case, then they really didn't fix anything, leaving the possibility for a chain of new related problems. (Think of the Spectre bug; the first mitigations only targeted a specific condition, not the underlying cause) HLSL prior to compilation is pretty close to the C language. Compiled HLSL is an assembly-like intermediate representation (which is what you see in the examples from Talos), which is then compiled yet again for specific GPUs by the driver.
The classification as a "high level language" depends on your convention. Back in the 60s and 70s a "high level language" usually meant anything that was not architecture specific assembly. When programmers today talk about "high level languages", they think of languages like Java, C#, JavaScript etc., and by that standard HLSL would be a "low level language", just like C.
So it could be of you are running edge, in windows 7 with hardware that has X spec them certain websites running malicious code in hardware accelerated code...
So like .0005 percent of all users.
But from your own admission, issues are disclosed upon discovery, so why weren't these vulnerability fixes disclosed? Isn't that the highest form of negligence?
best way to handle such comments is leave them unanswered.
Attention to
OpenCL ( Open Compute Language ) software developers
AMD's CEO and CTO
We regret to see that AMD quietly stopped supporting CPU-type Compute Devices for OpenCL based Hybrid ( aka Heterogeneous ) processing.
The problem was detected in December 2019 on ASUS TUF FX505DU Gaming Notebook with AMD Ryzen 3750H CPU. Initially, it was considered as a problem of ASUS but actually this is Not the case. During recent visit to a nearby BestBuy store the problem was easily seen on MSI, Lenovo, Acer Gaming and HP Envy Notebooks with AMD Ryzen Mobile CPUs.
We contacted AMD's Technical Support and all our attempts to bring attention of that problem to AMD's Software Engineers failed. Technical Support from AMD's Level 1 couldn't reproduce the problem and responded in a very disrespectful way:
"...Since we can't reproduce the problem this is Not our problem...".
It means, that in case of OpenCL based Hybrid processing on computing systems with:
- AMD Ryzen Mobile CPUs up to 0.5 TFLOPs of processing power is Not used
- AMD Ryzen Desktop CPUs more than 2 TFLOPs of processing power is Not used
- AMD Epyc Server CPUs more than 4 TFLOPs of processing power is Not used
That's a Lot of Processing Power Not used for Hybrid processing ( HPC, gaming, etc ) and, unfortunately, AMD doesn't care about it!
Quality of OpenCL support from AMD is at the lowest level since 2015-2016 years and a recent AMD Display driver 26.20.11016.1 disabled NVIDIA's OpenCL Client Driver on an ASUS TUF Gaming system. AMD's Display driver 26.20.11016.1 was rollbacked to a driver from AMD Radeon Adrenalin 19.9.2 package.
Also, AMD stopped supporting AMD Accelerated Parallel Processing SDK ( aka AMD APP SDK ) and the SDK was quietly removed from the AMD's website. All attempts to bring back The Best SDK for OpenCL programming failed.
At the same time NVIDIA and Intel continue to support OpenCL.
For example, on Dell Precision Mobile workstations with Intel CPUs and NVIDIA GPUs all types of OpenCL Compute Devices are available for OpenCL based Hybrid processing.
We really wanted to upgrade current computing systems with Intel CPUs to systems with AMD CPUs ( a resolute departure! ) but due to these problems related to OpenCL support on systems with AMD CPUs all upgrades are on hold...
and is this laptops,desktop or server ? you said laptop,and then mention epyc.
either be more coherent or just leave it. wat ?
no mention of doing so in its changelog
refers to
do people read the OP these days or just the title ?