- Check that the operation succeeded prior to copying to the output buffer.
- Avoid information leaks by only copying what is necessary to the output
buffer (suggestion by Tay Kiat Loong).
The WinFsp "transact" protocol is used by user mode file systems to interface
with the FSD. This protocol works via the DeviceIoControl API and uses the
FSP_IOCTL_TRANSACT control code. The FSP_IOCTL_TRANSACT code is marked as
METHOD_BUFFERED.
When the DeviceIoControl call is forwarded as an IRP, the METHOD_BUFFERED flag
instructs the kernel to copy user mode buffers to kernel mode buffers (and
vice-versa). However when the DeviceIoControl call is forwarded via the FastIO
mechanism the METHOD_BUFFERED flag is ignored. This means that when WinFsp
added support for DeviceIoControl FastIO, the FSD started accessing user mode
buffers directly.
This means that a malicious file system could attempt exploits like changing
or freeing a buffer while the FSD is reading it. Tay Kiat Loong developed a
POC exploit which demonstrated this vulnerability.
This commit fixes the problem by patching FspFastIoDeviceControl to add the
missing METHOD_BUFFERED handling.
- This commit introduces the fsmup device, which is a major change in how
network file systems are handled. Previously every network file system's
fsvol device was directly registered with the MUP. Now there is a single
fsmup device that is registered with the MUP; network file systems' fsvol
devices register with fsmup instead. The fsmup device maintains a prefix
table which it uses to demultiplex and forward requests to the appropriate
fsvol device.
- This device change was necessatitated to fix issue #87.
Bill Zissimopoulos