Your drivers may have an open Web server exposing you to attacks
During pentests performed by SecuRing we sometimes deal with applications that interact with hardware. Quite often they need custom drivers which may result in serious consequences. The biggest threats include the fact that drivers are usually run in a kernel space. That means not less than gaining root and full control of the victim’s machine when you take over the driver! For some people that may be obvious, since exploiting drivers is as old as the invention of SQL Injection.
Topic overview
During pentests performed by SecuRing we sometimes deal with applications that interact with hardware. Quite often they need custom drivers which may result in serious consequences. The biggest threats include the fact that drivers are usually run in a kernel space. That means not less than gaining root and full control of the victim’s machine when you take over the driver! For some people that may be obvious, since exploiting drivers is as old as the invention of SQL Injection.
Before the “Web server drivers” era, exploiting drivers on a machine was usually used for local privilege escalation. You needed to execute code on a machine, import some header “.h” files and abuse the driver’s logic.
But things have changed… In 2018 we observed that interacting with modern drivers currently means communication with fully featured web server using REST API, Websockets or other typical web technologies.
Classic drivers
Let’s summarise our knowledge about classic drivers. Take a look at a simplified diagram shown below.
An application usually runs in a user space that communicates with a driver using a defined IPC mechanism. The driver placed in a kernel space does its job and passes messages directly to a device through hardware I/O. To simplify the example, the above diagram doesn’t include shared libraries, /dev/mem, etc.
Web server drivers
The diagram for this kind of drivers looks a bit different. There’s one additional block:
Now, the application is using web technologies to communicate with the driver’s server, then the message is passed to the driver and then to a device. The server may be also embedded into the driver.
Why do developers choose such an architecture?
There are many reasons. Firstly, this architecture is easier to maintain when you have to write a cross-platform driver. You develop one web-based API and the communication problem disappears.
Secondly, this architecture is also simple to extend. If you plan to create something extendable , that users will be writing plugins to — you may choose this solution. I’m pretty sure that nowadays there are far more people that understand straight REST API calls better than interacting with complicated C++ functions.
Thirdly, again, times are changing. We are used to having apps in our web browsers. Rich clients are not sexy anymore. With this solution, you can control your hardware directly from your browser! Convenient, but… what about #security?
Things go wrong
“Controlling your hardware directly from your browser”. The point is that maybe it’s not you who’s in control.
