This is almost a virus! You can’t just sideload apps onto users’ systems as you would in a corporate environment! I am really surprised and annoyed when I found this! The ‘embarrassingly bad’ is for both Microsoft and Adobe!Update: I misunderstood how the app was sideloaded. See my further investigation and I apologise for the wrong blames. Hands down! The usage is legitimate and a perfect example of installation on demand (advertisement).
Quick navigation:
Reproduction
- Open ‘Settings | Update & Security | For developers’, and make sure you use the option ‘Microsoft Store apps (Only install apps from the Microsoft Store.)’.
- Make sure User Account Control Setting is at the highest level ‘Always notify’.
- Install Adobe Reader DC with the installer ‘Reader_DC_2019.008.20081_English_for_Windows’ from get.adobe.com/reader, which gives you Adobe Reader DC ‘Continuous Release | Version 2019.008.20081’. Do not open Adobe Reader at the end of installation.
- Open PowerShell as administrator, and navigate to C:\Program Files\WindowsApps, and type
Get-ChildItem ReaderNotificationClient*and press Enter. You will see nothing. Do not close this PowerShell window. - Search ‘Notification’ in Cortana, you will not see an app called ‘Notification Manager for Adobe Reader’.
- Open Adobe Acrobat Reader DC you just installed, and sign in with your Adobe ID.
- Go back to the PowerShell window, type
Get-ChildItem ReaderNotificationClient*and press Enter. You will see one entry that looks like ReaderNotificationClient_1.0.4.0_x86__e1rzdqpraam7r. - Search ‘Notification’ in Cortana, you will see the ‘Notification Manager for Adobe Reader’ app listed as a ‘Windows app’. See [Sideloaded] for a screenshot.
- Search any usual app you install from Microsoft Store, you will see it displayed as a ‘Trusted Microsoft Store app’. See [WSApp] for a screenshot.
- Go back to the PowerShell window, type
Get-AppxPackage ReaderNotificationClient, you will see the excerpt at [AppxPkgInfo].
Screenshots and information
The screenshot ↩[Sideloaded] illustrates what ‘Notification Manager for Adobe Reader’ looks like.
The screenshot ↩[WSApp] illustrates what a normal Store app looks like.
The excerpt ↩[AppxPkgInfo] contains information about the application package sideloaded by Adobe Reader DC:
Name : ReaderNotificationClient
Publisher : CN=Adobe Systems Incorporated, OU=Adobe Systems, O=Adobe
Systems Incorporated, L=San Jose, S=California, C=US,
PostalCode=95110, STREET=345 Park Avenue,
SERIALNUMBER=2748129,
OID.1.3.6.1.4.1.311.60.2.1.2=Delaware,
OID.1.3.6.1.4.1.311.60.2.1.3=US, OID.2.5.4.15=Private
Organization
Architecture : X86
ResourceId :
Version : 1.0.4.0
PackageFullName : ReaderNotificationClient_1.0.4.0_x86__e1rzdqpraam7r
InstallLocation : C:\Program Files\WindowsApps\ReaderNotificationClient_1.0.4
.0_x86__e1rzdqpraam7r
IsFramework : False
PackageFamilyName : ReaderNotificationClient_e1rzdqpraam7r
PublisherId : e1rzdqpraam7r
IsResourcePackage : False
IsBundle : False
IsDevelopmentMode : False
Dependencies : {Microsoft.VCLibs.140.00_14.0.26706.0_x86__8wekyb3d8bbwe}
IsPartiallyStaged : False
SignatureKind : Developer
Status : Ok
Note that SignatureKind being Developer means the app is not from Store.
Analysis, who to blame and what to do
Application packages are a new way to package and deploy Windows applications since Windows 8. Day-to-day users consume system apps and Microsoft Store apps (formerly known as Windows Store apps). Printer drivers might help user install utility apps from Store. Corporate users might consume apps sideloaded by their company. Theses are usually line-of-business apps. Finally, developers produce apps and debug them by sideloading them onto their PC.
These apps are supposed to provide a streamlined experience of installing, using, updating and uninstalling. Most of these apps use WinRT and are Windows Runtime apps (not Desktop apps). WinRT is supposed to provide users confidence in their control of what the app can/cannot do. By default, these apps do not even have programmatical access to the file system (such an app can open/save files by using a system-provided user experience, namely the file picker APIs). Arbitrarily sideloading apps onto the system certainly demolishes this image.
Settings app, a system app in Windows, allows users to choose the source of (application-packaged) apps. The most narrow and default choice is to install apps only from Microsoft Store. Corporate employees that perform their daily duty with an app internal to their workplace (not submitted to Store) can choose the second option, ‘Sideload apps’. Only apps with valid, trusted signatures will be installed. The most loose option, ‘Developer mode’, allows a developer to install the app (usually, by Visual Studio) he/she is working on.
Blaming Adobe
One party to blame in Adobe. Adobe introduced their notification capability to the Windows version of Reader DC a while ago. In a post in their official forum, an Acrobat Team member mentioned:
We have added a UWP app named "Notification Manager for Adobe Reader" to support push notifications on Win 10 environment. It supports all types of notifications about any change in the status of the documents that you shared for viewing, reviewing and signing. More info is available at Document Cloud notifications.
This is not a valid justification to sideload apps onto users’ system. To show notifications, Adobe can simply consume the desktop notification API.
Further investigation shows that ‘Notification Manager for Adobe Reader’ creates a push notification channel and stores the channel URI as an entry called CURI in local settings (see the AppData\Local\Packages\...\Settings\settings.dat file).
This still is not a valid justification to sideload apps. Adobe isn’t broken enough to not be able to have their own notification service. OneDrive sync engine for Windows 10, a desktop app, shows push notifications for someone starting to edit your shared file seamlessly. Adobe could just as well have a process in the background as a notifier.
Remarks. Using Windows Push Notification services is valid for an enterprise LOB app. But this scenario is quite different. Users do not expect their system to be sideloaded with things designed to be found in a business environment.
Blaming Microsoft
There are some problems involved in this issue. Perhaps that doesn’t qualify as a security vulnerability, but still is surprising users and considered harmful to the Windows (Runtime) ecosystem.
Changing the level of sources allowed for application packages in Settings app requires administrative privilege. However, Adobe Reader can effortlessly sideload an app onto the users’ system when the setting says ‘Microsoft Store apps’. The process of sideloading does not really involve changing the settings, but that this worked means the setting is not in effect. It perhaps just suggest the programs against sideloading apps, instead of forbidding that. The (evasive) app will even be sideloaded onto a protected place, namely C:\Program Files\WindowsApps.
Even if the app is sideloaded, it should not run. I recall that in Windows 8, if you change the setting to allow only Windows Store apps, any previously sideloaded app will stop to activate. This should also be the case now, because ‘Notification Manager for Adobe Acrobat’ is not installed from Store, and its SignatureKind is Developer, not Store or System!
Again, this might not be a security vulnerability, but surely is a problematic bug. Though the app Adobe Reader sideloads is benign, the capability to sideload apps when the user doesn’t want them, if not removed, will be abused to the nines in a foreseeable future. That just defeats one major selling point of Store apps (that they give back the control to users as in mobile platforms). Technically, they are not Store apps, but most users do cannot and do not want to tell the subtle technical difference of whether the app is sideloaded or from Store. They use ducking typing on types of Windows apps.
What to do
Adobe should stop sideloading apps. This is to respect both the user and the supposed usage of appx. Adobe could either ask the user to download a companion app from Store, or implement their own push notification service and consume notification API for desktop apps (like OneDrive already does).
Windows should check the validity of source/signature before activating an app. Windows should reject sideloading apps into protected locations when settings do not permit doing so. (Note that tricking Windows to believe a user has sideloaded a certain app at a certain unprotected location is not any problem, because such information is per-user. But again, it should not activate.)
Reply from Microsoft
I reported the concern to MSRC when I created (but did not publish) this entry. This entry is only published after Microsoft said the behaviour was by design and that they did not expect further actions (which I read as a release of holding back information to the public). An excerpt of the reply from MSRC:
Additionally, this only applies to applications installed using the modern Appx / MSIX install pipeline. It will not impact installation of classic MSI packages, nor will it preventing directly running executable files on local drives or networks shares.
‘This’ refers to the setting in step 1. Microsoft says the setting doesn’t apply to running executables, so they say that any executable runnning as current user can sideload apps to the machine for the user, as long as the app is signed by a trusted entity (which, in this case, is Adobe).
I still consider this harmful to Windows Runtime ecosystem, though I said this might not qualify as a security issue (as in its strict definition), because the mechanism doesn’t allow a user to install apps for other users, nor does it elevates privilege beyond what has been there for the running executable.
Bottom line: if you try to reset the app via Settings app without allowing sideloading apps, the app will be gone, presumably because the resetting uses modern Appx pipeline. That means Adobe’s sideloading an app is not reliable and might well be disrupted by normal user behaviour. So Adobe should consider using other mechanisms to deliver notifications (e.g., using a daemon to receive notifications from their own servers and convert it to local, desktop-app notifications).
Further investigation
Suggested by David Huang, I investigated how the app was installed using procmon.
Upon logging in with Adobe ID, Adobe Reader checks registry key HKCU\Software\Adobe\Acrobat Reader\DC\Installer\NotificationAppx. If it determines the appx package needs to be deployed, it launches msiexec /i {AC76BA86-7AD7-1033-7B44-AC0F074E4100} REINSTALLMODE=omus DISABLE_FIU_CHECK=1 IGNOREAAM=1 REPAIRFROMAPP=1 INSTALLUWPAPP=1 /qn, which will sideload the app.
Here, {AC76BA86-7AD7-1033-7B44-AC0F074E4100} is the product identifier of Adobe Acrobat DC. Since the MSI package is advertised (since Adobe Reader was first installed by an administrator), this is just an example of installation on demand. MsiExec.exe hands the information to the msiserver (Windows Installer) service, which runs with system privilege, and waits for it to perform the installation. By design, advertised product can be installed with administrative privilege by a normal user, this is perfectly legitimate. (This is the same design that allows an admin-installed MSI package to be repaired by non-admin users.) It is an ingenious example of the installation-on-demand feature.
How does the MSI package deploy the app? It temporarily tweaks values under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock (this is where administrative privilege is required), deploys the package (using the appxsvr, AppX Deployment, service) and reverts the values back (so the setting is in effect). Not a neat trick (because between tweaking and reverting, another app might have changed the values, which creates a race condition; see also this), but still.
Blaming myself!
Please enable JavaScript to view the comments powered by Disqus.