Support UI Automation within a Windows Defender Application Guard process by michaelDCurran · Pull Request #7600 · nvaccess/nvda

michaelDCurran · 2017-09-13T06:02:18Z

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:

currently WDAG does not change the nativeWindowHandle property and therefore that property exposes handle values from the isolated process which are completely invalid on the local machine.
The local window that hosts the entire WDAG content does not report itself as having a native UIA implementation.
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:

UIA NVDAObjects should never use their UIAElement's nativeWindowHandle as the NVDAObject's windowHandle. Rather they should always use UIAHandler.handler.getNearestwindowHandle. This was mostly already true, though sometimes nativeWindowHandle was still taking preidence if it existed.
UIAHandler.handler.getNearestWindowhandle: this function used to just find the first non-NULL nativeWindowHandle on a UIAElement and its ancestors. However now it also checks to see if the UIAElement is a WDAG UIAElement and if so then uses the root windowHandle for the process (which is the local windowHandle on this machine). In other words, all UIA NVDAObjects representing UIAElements within WDAG will now have a valid local windowHandle which is simply the root of the WDAG process.
UIAHandler.handler.isUIAWindow: if the window is a 'RAIL_WINDOW' then it should always be classed as being a UIA window. 'RAIL_WINDOW' is the window class given to the local window that hosts WDAG content.

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:

Went to Turn Windows Features On or Off, and selected Windows Defender Application Guard and pressed okay and rebooted etc.
Launched Microsoft Edge.
Whent to Settings and more -> New Application Guard window
In the new Microsoft Edge process that appeared, went to https://www.nvaccess.org/
Read the page using browse mode, tab, quick navigation etc.

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:

Support for Microsoft Edge running within Windows Defender Application Guard

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.

josephsl · 2017-09-13T06:09:43Z

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.

josephsl · 2017-09-13T06:11:13Z

CC @derekriemer who uses Windows 10 Education, functionally equivalent to Windows 10 Enterprise. Edit: Removed quoted email.

michaelDCurran · 2017-09-13T06:28:08Z

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.

feerrenrut · 2017-09-13T08:40:57Z

Is there some way that NVDA can query for the name of the WDAG process?

feerrenrut

No need for me to re-review the review actions, unless you think the changes require it.

feerrenrut · 2017-09-13T08:45:58Z

+		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':


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

michaelDCurran · 2017-09-13T08:52:36Z

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.

michaelDCurran added 7 commits September 1, 2017 11:58

* UIAHandler.isNativeUIAElement: if the processID is for the local wd…

ca70603

…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.

Merge branch 'master' into wdag

57046b5

UIAHandler.isUIAWindow: mark RAIL_WINDOW as always being native UIA. …

763c62f

…this allows screen hittesting, and allows us to remove some other code from UIAHandler.isNativeUIAElement.

remove some unneeded code

2d9b7d0

Merge branch 'master' into wdag

2d1a980

Remove more unneeded changes

d9272d5

michaelDCurran requested a review from feerrenrut September 13, 2017 06:02

feerrenrut approved these changes Sep 13, 2017

View reviewed changes

Address review actions

ea048ab

michaelDCurran added a commit that referenced this pull request Sep 13, 2017

Incubates #7600

a08f587

nvaccessAuto added the incubating label Sep 13, 2017

nvaccessAuto assigned michaelDCurran Sep 13, 2017

UIAHandler's getNearestWindowHandle: partial support for File Explore…

909cd8f

…r in WDAG by also looking for File Explorer's UIA class name.

michaelDCurran merged commit 05789d2 into master Oct 9, 2017

nvaccessAuto removed the incubating label Oct 9, 2017

nvaccessAuto added this to the 2017.4 milestone Oct 9, 2017

josephsl mentioned this pull request Oct 15, 2017

Docs17.4 #7662

Merged

aursulis mentioned this pull request Jul 18, 2023

Edge in Defender Application Guard not accessible to NVDA at all #15164

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Support UI Automation within a Windows Defender Application Guard process#7600

Support UI Automation within a Windows Defender Application Guard process#7600
michaelDCurran merged 9 commits into
masterfrom
wdag

michaelDCurran commented Sep 13, 2017

Uh oh!

josephsl commented Sep 13, 2017 via email •

edited

Loading

Uh oh!

josephsl commented Sep 13, 2017 via email •

edited by feerrenrut

Loading

Uh oh!

michaelDCurran commented Sep 13, 2017 via email

Uh oh!

feerrenrut commented Sep 13, 2017

Uh oh!

feerrenrut left a comment

Uh oh!

feerrenrut Sep 13, 2017

Uh oh!

michaelDCurran commented Sep 13, 2017 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

michaelDCurran commented Sep 13, 2017

Summary of the issue:

Description of how this pull request fixes the issue:

Testing performed:

Known issues with pull request:

Change log entry:

Uh oh!

josephsl commented Sep 13, 2017 via email • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

josephsl commented Sep 13, 2017 via email • edited by feerrenrut Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michaelDCurran commented Sep 13, 2017 via email

Uh oh!

feerrenrut commented Sep 13, 2017

Uh oh!

feerrenrut left a comment

Choose a reason for hiding this comment

Uh oh!

feerrenrut Sep 13, 2017

Choose a reason for hiding this comment

Uh oh!

michaelDCurran commented Sep 13, 2017 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

josephsl commented Sep 13, 2017 via email •

edited

Loading

josephsl commented Sep 13, 2017 via email •

edited by feerrenrut

Loading