,
33 tweets,
6 min read
Read on Twitter
I got frustrated at Gigabyte's RGB control stuff (I just REALLY want to turn my GPU LEDs off!) so I caved in and started reverse engineering RGB Fusion and OH GOD WHY DID I DO THAT IT IS SO HORRIBLY CURSED
1) They expose PCH GPIOs so they can bit-bang WS2812B LEDs from usermode.
2) Driver also gives direct read/write access to one of the smbus ports. Actually it might be more than one.
3) They expose some sort of ICSP flashing interface to an MCU?!
4) Driver object has no DACL.
2) Driver also gives direct read/write access to one of the smbus ports. Actually it might be more than one.
3) They expose some sort of ICSP flashing interface to an MCU?!
4) Driver object has no DACL.
The latest item in their release changelog is "fix some security vulnerability" and I... I just can't. This whole thing is a gaint backdoor into your motherboard's internals.
*endless screaming* 
*screaming intensifies*
I, too, upload PIC firmware blobs to chips on my motherboard over SMBus whenever I want to change my RGB lighting pattern.
Anyway, seems the reason the RGB tooling doesn't work for me is that there's literally zero support for the card in there. There's a "generic gigabyte peripheral device" class but it doesn't recognise my GPU despite it being a Gigabyte card.
Looking at the mini-site for RGB Fusion it turns out my card isn't actually listed in the supported cards list, despite the card's marketing page having RGB Fusion advertised all over it and the Gigabyte support folks offering random (but useless) advice on making it work.
"RGB Fusion wipes my CMOS on boot"
Since this thread is now circulating outside of infosec Twitter, here's a less-technical explainer on why this is a mess...
The driver executable is placed into a writable location, meaning from a non-admin account you can replace the driver with one that you can use to leverage for gaining admin / kernel code execution, e.g. the old Asus ASMMAP driver.
The driver also doesn't set an access control list (ACL) on itself while running, which is probably on purpose so that a non-admin user can change RGB patterns. It also means non-admin users can talk to the driver and abuse its features.
The whole RGB thing works by passing some data from the application to a driver, and that driver then sends the data to physical devices on the motherboard via either smbus (a low speed hardware bus) or general purpose IO (GPIO) from the chipset (PCH).
A sane way to do this is to have the application tell the driver "hey I wanna change colours" and the driver say "ok cool I'll handle all the hardware stuff". Instead the driver just exposes all the hardware stuff to usermode and the application does all the interaction directly.
This is a problem because smbus is a shared bus and the driver is giving you access to everything on that bus. So that might include security-sensitive devices. It certainly opens the opportunity to brick your hardware.
Another thing that uses smbus is the network controller (NIC), for the purposes of out-of-band management (Intel vPro/AMT). So you could potentially use the driver to talk to the network without the OS seeing any packets.
That's what we call a covert channel. I once gave a talk on doing exactly this from a malicious stick of RAM in a supply-chain attack. It's pretty wild.
The thing I mentioned about the MCU (microcontroller) is sketchy because they're providing you with a little computer inside your computer that you can flash code to.
It doesn't have access to much (it can talk to PCI-e cards that have SMBus pins wired, and that's about it).
It doesn't have access to much (it can talk to PCI-e cards that have SMBus pins wired, and that's about it).
But it's a way of hiding data off of the machine in such a way that will persist across OS-reinstalls. It doesn't allow you to persist malware or anything like that but it's a neat covert storage location.
Having a fair bit of experience with these types of drivers, I guarantee that if I took the time to dig into it more I'd find a bunch of privilege escalation vulnerabilities in it. I may yet do this and disclose the bugs to Gigabyte. Not sure if I can be bothered.
Gigabyte are certainly not the only ones to have bad code in this space. Asus aren't very good at it either. But I have to say that Gigabyte's software is especially poorly engineered regardless of the security side of things. Just phenomenally bad and broken.
Okay I'm gonna mute this thread in a sec 'cos it's flooding my notifications tab. Just to wrap up, here's a few final tweets to cover the most common questions...
The main one: I can't just tape over the LEDs or desolder them. They put LEDs on the fan blades and the SMD ones under the backplate are soldered into the PCB. I'm not disassembling my brand new £1200 graphics card, let alone taking a soldering iron to it.
All of these issues require an attacker to already be running malicious code on your machine, albeit only at a low privilege level (non admin). So this won't magically make you insecure against an attacker on the network or internet.
The use of smbus is not a problem here. That's fine, and quite common. That how temperature and voltage sensors are connected on your motherboard. The real problem is completely exposing all smbus ports to non-admin users via the driver.
A better way to do things would be to have the driver do all the smbus/GPIO stuff and expose a limited interface/API to usermode, e.g. "enumerate devices", "set LED pattern for device", etc. rather than "here's all the smbus ports, go wild".
As for whether other vendors are just as bad... yeah, mostly.
My experience of Acer is that their drivers are full of vulns and they take many months, if not a year+, to fix them when researchers contact them. I waited two years on one bug (eventually someone else disclosed it).
My experience of Acer is that their drivers are full of vulns and they take many months, if not a year+, to fix them when researchers contact them. I waited two years on one bug (eventually someone else disclosed it).
I can't say I've looked at the rest of the vendors all that much. I don't own any MSI hardware but it seems like their software at least actually works for the most part, even on non-MSI hardware. I can't vouch for their security though.
As for why this stuff happens... time and resource pressure. Software and firmware is usually not a big budget item and they will cut corners as much as possible. Writing a "give me all access" driver and then iterating development in user software is easier than doing it right.
Anyway, muting this now, to save the notification spam.
