Previously, the Rootshell Security team discovered several flaws in DESkey’s hardware kernel drivers.
A further issue affects drivers associated with the DK[23]USB/B and DK[23]USB/D devices, and potentially others.
The root cause of the issue is in the lack of validation of the contents of the buffer sent from the user to the kernel driver. The implementation trusts a userland-supplied pointer read from the userland buffer (userland refers to all code that runs outside an Operating System’s kernel). The implementation subsequently writes to the pointer, enabling it to point to invalid/un-paged memory. This causes the driver to either page-fault or write to arbitrary memory.
It appears that the functionality seeks to write the 4-bytes (offset 0x0E) from a structure stored in a singly linked list, the head of which is at qword_1D238. The value matched is taken from the user supplied buffer (0x16A85).
The disassembly for the affected function is given below:
The instructions at addresses 0x16A9B contain ‘arbitrary pointer writes’, which is a type of vulnerability that enables local attackers to write data to arbitrary memory locations. This could facilitate arbitrary code execution within the context of the kernel, namely ring zero, and the compromise of the host.
The following pseudo-code will result in a blue-screen with a page fault on the 0xDEADBEEF address:
This begs the question, why do Windows Kernel driver programmers still insist on trusting user controllable pointers?
An interesting prospect for addressing this and improving the future security of the Microsoft Windows Kernel is the Vulnerable and Malicious Driver Reporting Centre, which allows potentially vulnerable drivers to be submitted to Microsoft for analysis.
It remains to be seen what the impact of restricting signing certificates for third-party developers that write insecure or malicious code will be, but we suspect it can only be positive.
Catch up on more of our bug-related news below:
Subscribe So You Never Miss an Update
