Work around start-up crash in Adobe Reader protected mode #13413
Conversation
… app container process token as this can crash apps such as Adobe Reader.
This comment was marked as outdated.
This comment was marked as outdated.
feerrenrut
left a comment
There was a problem hiding this comment.
Generally this looks like big improvement!
|
I've kicked off the build again due to the intermittent chrome test failure. |
This comment was marked as outdated.
This comment was marked as outdated.
… and compaire egainst 0 to create the return bool.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@feerrenrut I did not quite follow your request about making a helper function that returns std::optional. Note that kernel32Handle has to remain valid from when looking up the function, until after actually executing it. So really that is the entirety of isSuspendableProcess. I could rename the function to hasApplicationUserModelID? But that is all that whole function does. |
Ah, I didn't realize that, let me take another look at it. |
This comment was marked as outdated.
This comment was marked as outdated.
feerrenrut
left a comment
There was a problem hiding this comment.
I've kicked off the build again. The code and PR description look good.
Link to issue number:
Fixes #11568
Partial fix for #12920
Summary of the issue:
Recent versions of Adobe Reader introduced a Protected Mode, where by the Adobe Acrobat process has less privileges and is sandboxed. This ensures that insecure PDFs do not have a chance to affect the rest of the Operating System.
By default Adobe Reader is configured to enter its Protected mode on start-up, and to set the 'isAppContainer' attribute on its process token.
There seems to be a bug however, either in Adobe Reader, the Windows OS, or NVDA (NV access and Adobe cannot be sure) that causes the Adobe Reader process to become unstable when NVDA tires to register IAccessible2. Specifically, the call to CoGetPSClsid seems to start making things unstable. The further call to CoRegisterPSClsid fails, and then eventually the process completely crashes randomly in places such as TSF initialization.
The upshot is that If Adobe Reader is started when NVDA is running, many errors are written to NVDA's log, and Adobe Reader closes straight away.
Description of how this pull request fixes the issue:
NVDAHelper's IAccessible2 registration code now checks if the process token has the 'IsAppContainer' attribute, and of so refuses to install IAccessible2 support.
Note that Adobe Reader itself does not require IAccessible2 to function.
Also, the 'IsAppContainer' is only set on very heavily sandboxed sitations, and is not the same as the app container that is used for Windows Desktop Bridge apps. Thus, refusing to install IAccessible2 into processes with the 'IsAppContainer' attribute has no other known side affects.
Testing strategy:
Known issues with pull request:
Note that this pr does not address the crashes in Adobe Reader 64 bit when trying to read a PDF. This is a very separate issue.
Change log entries:
New features
Changes
Bug fixes
For Developers
Code Review Checklist: