It rather involved being on the other side of this airtight hatchway: Producing malicious data in a kernel driver
A security vulnerability report went something like this:
We have found a vulnerability in the
LogXyzfunction. If the packet being logged contains malicious field lengths, the function can read past the end of the buffer and log data from its process space, resulting in information disclosure. Attached is a sample driver that triggers the overflow.
Okay, that sounds bad. This is the sort of thing that led to Heartbleed.
But a closer look at the LogXyz function shows that the packet it is logging came from a driver. So this attack presupposes that a malicious driver has been installed on the system.
If you have a malicious driver on your system, you have bigger problems than a buffer overflow in a logging function.
What we have here is a bug, but not a security vulnerability. The LogXyz function should be more resilient to malformed data, but any such malformed data came from kernel mode, which already has the power to do anything it wants to user mode. The driver could just access the LogXyz function’s memory directly and get whatever it wants, no need to trick it into writing the information to a log (and then having to go dig it out of the log).
Light
Dark
3 comments
Surely this also leaves you at the mercy of merely buggy drivers as well though, does it not? If an attacker can find a buggy driver that triggers this behaviour, they can then look for systems with that driver installed and attempt to exploit it. And given what you’ve posted previously about driver shenanigans I’m sure there are a lot of buggy drivers out there, so it wouldn’t surprise me if at least one is passing incorrect field lengths to LogXyz. There might not technically be a security boundary in between the driver and the data, but that doesn’t mean it’s not a security risk. (As are all drivers, which is why we’re pretty much doomed.)
The other consideration, I suppose, is where the logged infomation goes. Presumably it will, in the end, be accessible to user mode (I’m guessing the kernel isn’t that interested in inspecting logs). So is the leaked information crossing a security boundary in that direction? (Genuine question, I am not a programmer of any sort and only have a fuzzy picture of the security model.)
Yes, it would still be a good thing for LogXyz to validate the offsets, as a defense in depth.
Reading this article again a week later feels a bit different, having just spent a day and a half trying to help identify and patch all the products and systems our company uses that are affected by the newly announced log4j exploit nicknamed “Log4Shell”.
Not that that exploit has anything to do with incorrect field lengths. But it serves as a reminder that even a generic logging function can be a huge security risk.