Symbolic Link racing

Don’t Open the Door to Vulnerable Drivers

Let’s say that you’ve defined a policy in which drivers of your choice should not be loaded onto any of the machines, or that you don’t need those drivers, or just you want to prevent the exploitation that we’ve demonstrated, for this option we’ve created the following type of mitigation based on how drivers located for passing them an I/O request (IRP), using a symbolic link (you can get further information about symbolic links on MSDN).

Once an application in user-mode sends an I/O request to a specific driver/device, it uses the symbolic link of the driver to specify the driver for handling the request, and the object manager resolves the symbolic link (or devices named) provided by the user-mode application to a registered and loaded driver that receives the request and handle it.

Remember the following, every application, even in user-mode can register a symbolic link, not just drivers, and duplications of the symbolic link are not allowed (mean registering another device with the same symbolic link). so what happened if I register a symbolic link that will lead the object manager to an empty/invalid location? We answered with code.

The following mitigation technique is registering a fake symbolic link of a vulnerable driver to the machine is running on, without the driver being loaded or registered already (remember, this is user-mode code XD ):

The function DefineDosDeviceW is used to create a fake symbolic link of a device in the Object Manager, and as explained by Microsoft: “Defines, redefines, or deletes MS-DOS device names”. Now that we’ve created a fake device called “DBUtil_2_3” at the path “\\Device\\DBUtil_2_3”, the real driver cannot assign himself to this path, therefore it cannot be registered and installed on the system.

Know that MS-DOS device names are some types of symbolic links that are used only by drivers that are in use by user-mode applications. Further information about MS-DOS Device Names can be found at MSDN.