0

I have a UMDF driver that provides IOCTL commands to be accessed by the UWP application. The UWP application is submitted to the store, complete with the appropriate custom capability and signed SCCD in order to access the UMDF driver.

What I understand from the SCCD MS documentation is that this allows the UWP app to access the driver and its IOCTLs, so when other UWP apps try to gain access, they would be rejected. However, the SCCD does not explicitly state that Win32 applications are still able to access the IOCTLs, which I think defeats the purpose of having the custom capability and SCCD.

Given this problem, I understand I have to reject requests coming from Win32 apps in another way.

There is this GetApplicationUserModelId function that we wanted to use to determine if the app is not a UWP app. This requires the pID, and we can get it using WdfRequestGetRequestorProcessId. However, obtaining a process handle for this pID requires accessing the memory of other processes. With the UMDF driver having no privilege because it does not own the process, an ERROR_ACCESS_DENIED is being returned when trying to to call OpenProcess, even with an access right of PROCESS_QUERY_LIMITED_INFORMATION.

OpenProcess documentation suggests that in order to open a handle to another local process and obtain full access rights, we must enable the SeDebugPrivilege privilege. I believe doing this puts the driver into a greater security risk and because of this, it may not be a good idea to push through.

Should there be another alternative to this approach, or another type of descriptor, or anything similar that could support the goal of restricting win32 apps from using the IOCTLs?

Jer Yango
  • 582
  • 2
  • 8
  • 22
  • 1
    Since Win32 apps are medium IL, they have the ability to debug and inject code into low IL apps (like UWP apps), so any roadblock you set up can be driven around: A Win32 app could launch a UWP app that has the SCCD, and then modify its code to do whatever the Win32 app wants. – Raymond Chen Sep 16 '20 at 12:49
  • Thank you for your insight, I understand. But given the big difference with and without this restriction, there is still defense-in-depth value in adding something as it increases the required complexity of the attack. Therefore, I think this is still a valid option that would lower the risk (but not eliminate it as you point out). – Jer Yango Sep 16 '20 at 23:56

1 Answers1

0

For a UMDF driver, it is possible to use the WdfRequestImpersonate function. This function creates an event callback function that the UMDF could use to impersonate the access rights of the requesting process.

Note that the Impersonation level should be SecurityImpersonation. This needs to be declared in the INF file, as well as supplied in the WdfRequestImpersonate function parameters. OpenProcess can now be called from within the callback function.

Do note that WdfRequestImpersonate will not return until the callback function ends, and that the impersonation is limited to the contents of the callback function only.

Jer Yango
  • 582
  • 2
  • 8
  • 22