Support UI Automation within a Windows Defender Application Guard process #7600
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
changes: * UIAHandler.getNearestWindowHandle: If this UIAElement's processID is for a local WDAG container process, jump up to its root (UIA className of "ApplicationFrameWindow") and use that element's windowHandle. Any windowHandle from UIAElements below this root are not valid on this machine. However before we check for the WDAG process, if the processID of the original element is 0, search up for the first valid one (Known WDAG bug) * UIAHandler.IsNativeUIAElement: If the processID is 0 (such as with UIAElements currently in WDAG), treat this UIAElement as having a native UIA implementation * UIA NVDAObject: don't get the processID of the UIAElement, instead fallback to getting it off its window. Currently a UIAElement in WDAG may have a processID of 0. This is a known bug. It should be the processID of the local container process.
…ag container process, then this element should be classed as being native. * Ensure IUIAutomationElement.cachedNativeWindowHandle is never used when it is not local -- needs to be rethought a bit.
…this allows screen hittesting, and allows us to remove some other code from UIAHandler.isNativeUIAElement.
|
Hi,
For anyone commenting on this pull request, WDAG was announced in 2016, and introduced in Version 1709 (Fall Creators Update). Thus, tests should be done by other Windows Insiders running Windows 10 Enterprise or Education Version 1709 Preview. Thanks.
|
|
CC @derekriemer who uses Windows 10 Education, functionally equivalent to Windows 10 Enterprise.
Edit: Removed quoted email.
|
|
It is also worth noting that several major UI Automation bugs in WDAG
were fixed and are only available as of build 16288. In fact running
WDAG with or with out this code on prior builds may cause hangs or crashes.
|
|
Is there some way that NVDA can query for the name of the WDAG process? |
feerrenrut
approved these changes
Sep 13, 2017
source/_UIAHandler.py
Outdated
| appModule=appModuleHandler.getAppModuleFromProcessID(processID) | ||
| # WDAG (Windows Defender application Guard) UIA elements should be treated as being from a remote machine, and therefore their window handles are completely invalid on this machine. | ||
| # Therefore, jump all the way up to the root of the WDAG process and use that window handle as it is local to this machine. | ||
| if appModule.appName==u'hvsirdpclient': |
There was a problem hiding this comment.
I think it might be handy to pull the process name out and store it in a class or module level constant. The name might be handy when someone searches for WDAG_PROCESS_NAME or similar
|
We can query the name of (a given) process. A WDAG process will have a
name of "hvsirdpclient".
There is no other way I know of to identify a process as a WDAG process
apart from checking the name.
Simply, I believe this UI Automation implementation is flawed as the
nativeWindowHandle property does not expose a valid windowHandle as the
spec promises.
|
…r in WDAG by also looking for File Explorer's UIA class name.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of the issue:
On Windows 10 Enterprise, it is now possible to run Microsoft Edge within Windows Defender application Guard (WDAG). WDAG is a stripped-back version of Windows running in a special virtual machine that can securely isolate a process from the rest of the system.
The only way that an asistive technology can talk to the isolated process is via UI Automation. Nothing else can cross the machine boundary.
WDAG perfectly forwards the UI Automation implementation from the isolated process, but changes the processID property on each UIA element to expose the local WDAG process ID rather than the process ID inside the VM. However, the following two problems exist:
These problems together mean that NVDA pretty much stays silent when focus is within a WDAG process and therefore if a user decides to run Microsoft Edge in this fassion it is completely inaccessible.
Description of how this pull request fixes the issue:
These changes make NVDA function with Microsoft Edge in WDAG exactly the same way it would if Edge was running locally. The only difference being a noticeable drop in responsiveness.
Testing performed:
On a windows 10 Enterprise machine:
Known issues with pull request:
If the name of the WDAG process ever changes (it is currently hvsirdpclient), not only will the WDAG process be inaccessible, but most importantly NVDA and or other parts of the system may experience hans or crashes due to the use of a nativeWindowHandle from a remote machine that is not valid locally. I have suggested to Microsoft that this is a major risk. Note though that without this PR the risk still remains the same.
Change log entry:
New features: