CVE-2020-12138

AMD ATI atillk64.sys 5.11.9.0 allows low-privileged users to interact directly with physical memory by calling one of several driver routines that map physical memory into the virtual address space of the calling process. This could enable low-privileged users to achieve NT AUTHORITY\SYSTEM privileges via a DeviceIoControl call associated with MmMapIoSpace, IoAllocateMdl, MmBuildMdlForNonPagedPool, or MmMapLockedPages.

Recent assessments:

bwatters-r7 at October 14, 2020 10:28pm UTC reported:

From my reading of <https://h0mbre.github.io/atillk64_exploit&gt;, this reminds me a bit of heartbleed, though in addition to a read tool, this also allows for writing. . The atillk64.sys driver is vulnerable to abuse of a function that maps physical memory into a process’s virtual memory space. The relative gist of the vulnerability is that you can trick the driver into mapping kernel memory into your unprivileged process’s space to read or write. It reminds me of heartbleed because there’s some guesswork involved, and there is some searching required as an attacker will not know exactly what memory they want to map.
Mapping kernel memory into a arbitrary, unprivileged process is bad because fundamentally, all memory is kernel memory, and being able to change kernel memory allows someone to alter the function of the operating system.
In the case of the above blog, the author maps the kernel’s metadata for processes (the EPROCESS kernel structure) into a user-level process they control. In doing so, it allows them to copy the permission token from a high privileged process into their own low-privileged process, affecting a privilege escalation.
That’s not the limit to this particular exploit. There are a lot of valuable things that could be accessed and this could be easily converted to a code execution vulnerability by overwriting a memory block with executable code and then adjusting a driver dispatch table. Such an action would allow an attacker to patch in their own dispatch handlers. The authors did not do that because token stealing is simpler, easier, and there are far fewer protections against it than patching in code, but as a thought exercise, it is possible with this vulnerability.
Mitigations include updating the driver or removing it from your system. The vulnerable version is 5.11.9.0, so defenders can check to see if it is present on systems.

Assessed Attacker Value: 4
Assessed Attacker Value: 4Assessed Attacker Value: 3