iPrint Client: nipplpt.sys Error Logging Handle Use After Free
Platform: iPrint Client 5.99, tested on Windows 8.1 Update 32
Class: Elevation of Privilege/Denial of Service

Summary:
The nipplpt.sys driver doesn’t check the return code when creating a log file during error logging leading to reusing a kernel handle. This can lead to elevation of privilege or local denial of service.

Description:

The  nipplpt.sys driver logs errors in its own thread using a simple linked list to pass new log strings. Each time the log file is to be written to it opens the log file for exclusive access. The return code from the create file call isn’t checked to ensure the file was opened and the handle value is never cleared so by locking the log file as a user process and causing a log event to occurs it’s possible to get the driver to reuse the last value stored in the handle variable. 

This has a number of consequences. If a new handle is opened with the same value by another kernel component then it can cause file corruption due to the errant write call. Also the call to ZwClose could fail due to an invalid handle leading to a bug check or it could close another system’s handle which that then fails. Finally it could allow a handle to be closed which the kernel assumes was opened then another handle opened in its place which could lead to elevation of privilege through a user after free scenario. 

The handle variable should be cleared after close and the result of the create file call checked before reuse. 

The code looks something like:

HANDLE FileHandle;

while(true)
{
	// Wait for new log event
	CreateLogFile(L"\\??\\C:\\NDPS\\DOSBOX\\NIPPLPTS.LOG", &FileHandle); <- No check made on result

	ZwWriteFile(FileHandle, …); <- FileHandle uninitialized or same as last value
	ZwClose(FileHandle); 
}

Proof of Concept:

I’ve provided a PoC as source code, it will need to be compiled with something like Visual Studio. It will typically demonstrate a kernel bug check. Note that it does use one of the other bugs to guarantee a log message is written however this isn’t required, for example it would be possible to cause a write failure through using up disk space temporarily or other resource constraints. This has only been tested on 32 bit Windows platforms, it should be run as a normal privileged user and not as an administrator. I’ve attached as well an example crash from an invalid handle being closed. 

Expected Result:
The log event should fail gracefully

Observed Result:
Typically a bug check occurs. 

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.