A security vulnerability report went something like this:
We have found a vulnerability in the
LogXyz
function. 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).
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.
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...
Yes, it would still be a good thing for LogXyz to validate the offsets, as a defense in depth.