This is a response to recent Unwinder claims and behavior related to vulnerabilities found in his RTCore32/64 driver which is a part of MSI Afterburner. I almost forgot about him and his software but recently this guy reminded himself again.
RTCore overview
RTCore is a name of kernel mode driver used by MSI Afterburner software (https://www.msi.com/page/afterburner), quote "The world’s most recognized and widely used graphics card overclocking utility which gives you full control of your graphics cards". There are exist two variants of the RTCore driver, built from the same source - RTCore64.sys and RTCore32.sys, each for respective platform. This driver provides access to the physical memory, CPU MSR's, I/O ports read/write. Applications interact with driver via API layer implemented in RTCore.dll which is also a part of MSI Afterburner installation. Basically it is a simple "giveio" type helper driver.
This driver is a subject of legacy code, derived in mostly unmodified state likely from time when Windows XP (or even Windows 2k) was all new and shiny. That mean it doesn't care about security. Latest available RTCore drivers is able to run on most recent Windows 10 where enforced security was enabled. Historically RTCore is a part of RivaTuner code. In a short, RTCore is a wormhole.
Security issues of RTCore known for a long period of time, got various CVE id's and even caused author - Alexey Nicolaychuk aka Unwinder to publicly bitch about yet another publication (https://github.com/Barakat/CVE-2019-16098). TL;DR according to Alexey, no one notified him before publication, so it wasn't a "responsible disclosure".
Is that true? Of course not, he was aware of this RTCore "feature" at least from 2016, see next.
It is worth to mention that I was using RivaTuner back to the 1999 and early 200x on Riva TNT2 next GeForce 2 MX400 and GeForce 3 Ti200 and this utility was indeed very helpful at that time. Than I got enough money to buy better hardware and RivaTuner moved to the Recycle Bin.
Response to CVE-2019-16098
No doubt his code and everything based on it is still very useful for a lot of people. However Alexey attitude to security of his products can only be described as "weird". This can be described by idiom "You can't teach an old dog new tricks".
 |
| Pic 1. Unwinder response to CVE-2019-16098. |
The Jar of Worms*
*(c) Unwinder, 2019
To understand what does this mean lets take as example UnknownCheats forum (UC) - probably the leading platform for game cheats developers available today. By it impact to the game cheats it probably can be compared to the wasm.ru impact on sophisticated malware development. Here, just by using forum search, you can find a multiple vulnerable drivers (even packs of them) with some already used in game cheats to bypass anticheat software. They use this for years and most of information freely available for both cheat/anticheat developers and very well indexed by search engines. Github is full of projects (of various quality) from UC members involving usage of these vulnerable drivers - these projects are provided as-is to everyone on various programming languages. While being written by mostly kids of school or college age
 |
| Pic 2. Typical UC thread content (https://www.unknowncheats.me/forum/2111513-post8.html). |
they are usable as all you need from this is a concept.
Why there is no multiple use in malware area and where is the "jar of worms" located? So far this jar of worms exist only as Unwinder wet fantasy. If Alexey was not an amateur in the area where he is trying to picture himself as an expert (or if we go down to the Unwinder comments level - wannabeexpert) - he would know about modern Windows security boundaries and thing called practicability. Difference between intentional and unintentional/forced usage. In cheats area - game hack users are actively involved in bypassing security mechanisms because they want to play with cheats and they ultimately looking for a way to do that. In malware - users are victims and while they can be social-engineered to bypass basic Windows security mechanisms in favour of malware needs, malware still will have to deal with Windows security. That moves practical usage of this drivers to the very specific APT area.
RTCore problem
After dealing with "jar of worms" (yeah I like that) we suddenly discovering that RTCore author seems absolutely do not understand the "core" problem of his RTCore. Here is it, Alexey, specially for you - who are ignoring OS security model for decades, I'm showing you exact problem of your wormhole by design software.
 |
| Pic 3. RTCore DriverEntry. |
Quote from MSDN
IoCreateDevice can only be used to create an unnamed device object, or a named device object for which a security descriptor is set by an INF file. Otherwise, drivers must use IoCreateDeviceSecure to create named device objects.
What happens here. When MSI Afterburner loads RTCore32/64 driver, it device object will be created with a default security descriptor. Which means literally any logged user on this machine can access this driver through it device with read/write permissions.
 |
| Pic 4. RTCore64 device security permissions. |
RTCore gives you ability to read/write to the MSR's, I/O ports and memory. The first use of this RTCore "design" demonstrated by CVE-2019-16098 - elevation of privilege via typical EPROCESS structure modification. Another one (since this driver has ability to read/write arbitrary kernel memory) is driver mapping - something similar to TDL/Stryker/CapCom and multiple other mappers based on vulnerable third-party drivers. Since there is also feature to read and write to MSR's and ports - this makes RTCore awesome for exploiting.
Normally if your driver is something more complex than kernel mode "hello world" and has data read/write to user mode it must contain security checks. For example you can limit access to your driver using IoCreateDeviceSecure or/and check security context in your IOCTL handler, requester privileges etc - there are many ways to do that in the *right way*. If you for some reason cannot use shiny new APIs (for example, you are supporting Windows 2k 👻) you still can secure driver device using Rtl SD/Ace/Dacl documented APIs and ZwSetSecurityObject. It is not a problem.
The lack of security checking is a very common problem for software supposed to work with hardware. Few examples: system utilities (CVE-2017-15303), overclocking and other software from GPU/hardware vendors (CVE-2018-18536, CVE-2019-8372), hardware monitoring utilities (CVE-2018-8060, CVE-2018-8061), bios flashers (CVE-2019-5688) etc. A lot of them. Practically ALL drivers of that kind that I was investigating were vulnerable or based on vulnerable code.
 |
| Pic 5. Choose your exploits provider. |
There is a nice collection of this kind of drivers with brief descriptions made by Eclypsium, https://github.com/eclypsium/Screwed-Drivers/blob/master/DRIVERS.md Please note that some vendors already provided new versions with improved security (for example Intel) and this list is incomplete, also you still can find exact old vulnerable drivers and use them.
If you look on "giveio" drivers from various vendors you will notice - they all almost the same, they only differ little in some implementation details and internal structures used to communicate with user mode. And they all of course signed 😊
RTCore wormhole*
*(c) hfiref0x, 2020
CVE-2019-16098 was targeting exact MSI Afterburner version - 4.6.2.15658, it is Afterburner 4.6.2 Beta 2. However given exploit will work with older versions of MSI Afterburner as they include same driver. In the next Afterburner version Unwinder proposed a fix for this CVE, you can find a little about it in the changelog (https://www.guru3d.com/files-details/msi-afterburner-beta-download.html)
"Updated IO driver provides more secure MMIO and MSR access interface".
More precisely it means that memory mapping IOCTLs now work only for hardware IO reserved address ranges. And he banned arbitrary MSR read/write, setting up restrictions on their IOCTLs. Driver also got EV certificate. This interesting though this exact "fixed" RTCore present only since MSI Afterburner 4.6.2 Beta 3, while it is pretty much similar to fixes announced by Unwider three years ago in comments to the rewolf post - MSI ntiolib.sys/winio.sys local privilege escalation.
 |
| Pic 6. RTCore fix, announced in September 2016. |
Even if this is, judging from Unwinder comment, partial fix - it is notable this updated RTCore component wasn't distributed with MSI Afterburner, until Barakat published his proof-of-concept and got CVE. How much other software with bundled RivaTuner code still not updated their RTCore related code base (even if these components may have different names)? Speaking about ethics, which is mentioned by Unwinder in above response to CVE-2019-16098, how does that correlates with it too? You have extremely vulnerable driver which code base used by different products, you have produced some "security related" changes, and for three years didn't even updated your own MSI Afterburner. Just because no one gives a single fuck until you got upset with publicly available CVE forcing you to jump to the twitter/issues shitpostings. This is hilarious, Unwinder.
Okay, additions he made makes sense and question is only why there weren't here from the beginning. But seriously, is that the only problem this guy found? 😊 While Unwinder really likes to go on demagogy discussions about Windows security model, he still doesn't know how to use wdmsec.lib, maybe because MSI Afterbutner RTCore driver got compiled in something like Visual Studio 2005/2008 with DDK likely from Windows XP/Vista. No joke, just look at this driver structure. As you understand we still can use this driver for a range of bad things. For example for Denial of Service attack.
This is simple proof-of-concept code for "fixed" RTCore from MSI Afterburner 4.6.2.15745 release, it will write specific data to the I/O port to initiate immediate system reboot which can lead to data loss and/or potential hardware damage. From unprivileged, guest, whatever account. This of course will also work for previous variants of RTCore if they support required IOCTLs. That is not all - this driver still has a lot of potential, because there are multiple other IOCTLs.
The simple solution to that wormhole named RTCore is to move it into OS security boundary and stop bitching about self-made problems as Unwinder still does. Or do as I did many years ago - throw all these CD/DVDs supplied by GPU vendors with their crapware to the trashcan along with their authors as an ultimate solution to the security of this vector.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.