Dec 14 2021 10:07 AM - edited Dec 14 2021 10:53 AM
Dec 14 2021 10:07 AM - edited Dec 14 2021 10:53 AM
I just found out that users can no longer install my MSIX from my website. This is a WPF application packaged with "Windows Application Packaging Project" (wapproj). When users click the "Get the app" button they now see the error below saying the protocol has been disabled. Why is this? Is this permanent? Is there a way to enable it?
There's a short mention of this in the docs but it doesn't mention why this is happening or how to enable it.
Is this no longer supported?
<html> <body> <h1> MyApp Web Page </h1> <a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubApp.msix"> Install app package </a> <a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppBundle.msixbundle"> Install app bundle </a> <a href="ms-appinstaller:?source=http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a> </body> </html>
The ms-appinstaller protocol has been disabled. Please ask the vendor to update the weblink. For more information go to aka.ms/ms-appinstaller-disabled
Dec 15 2021 04:31 AM
Dec 15 2021 06:55 AM
Dec 15 2021 07:29 AM - edited Dec 15 2021 03:49 PM
This broke the installation and update process for my commercial Windows app overnight because some hacker used a legitimate, documented "this is how you publish Windows apps" to distribute malware?
How is this considered an acceptable mitigation?
I have a $3k Extended Identity certificate that I sign my installer packages with, but now it's illegitimate to install it because a malicious payload was discovered somewhere else?
Dec 15 2021 07:54 AM
Dec 15 2021 10:33 AMSolution
@bvenhaus Thank you for your question. We removed the ms-appinstaller custom scheme due to a security vulnerability. We do intend to bring this back, and are working on it. For now, you can update the link on your website by removing 'ms-appinstaller:?source='
<html> <body> <h1> MyApp Web Page </h1> <a href="http://mywebservice.azureedge.net/HubApp.msix"> Install app package </a> <a href="http://mywebservice.azureedge.net/HubAppBundle.msixbundle"> Install app bundle </a> <a href="http://mywebservice.azureedge.net/HubAppSet.appinstaller"> Install related set </a> </body> </html>
Dec 15 2021 10:53 AM
@Aditi_Narvekar Do you have a timeframe on when it will come back?? Removing the ms-appinstaller prefix doesn't really work as it then asks the user to download the file. Once downloaded they have to chose to run it which is a complete deviation from what ms-appinstaller did. Also you can not pass parameters on to the application with a direct link, ms-appinstaller allowed for that. Unfortunatly this has completly brought down our distribution system.
Dec 15 2021 12:22 PM
Dec 15 2021 03:40 PM
@Aditi_Narvekar could you please restore this functionality ASAP? This was a major sweeping break of what must be thousands of apps, if not more.
If the issue is unsigned apps using ms-appinstaller and carrying a malicious payload, please mitigate by disabling unsigned apps. If the issue is an EV certificate signed app using ms-appinstaller and carrying a malicious payload, please use certificate revocation to address the vulnerability.
I switched my application to use MSIX and an EV certificate because this is the best practice and most up to date tooling (via Visual Studio) for distributing a Windows app outside of the MS Store. This action has revoked, without notification, the proper way to securely distribute non-public Windows apps.
The cure is more harmful than the disease in this case.
Dec 16 2021 12:48 AM
Dec 16 2021 09:43 AM - edited Dec 16 2021 09:44 AM
@Aditi_Narvekar - As MSIX is the flagship technology for deploying and updating Microsoft applications, I hope M$ is taking what amounts to a service outage as a very high priority. This issue has broken our entire devops workflow and is affecting user confidence in the solution. The additional manual steps required as a workaround at the moment are not appropriate for our user base.
Dec 21 2021 08:35 AM
The security team declined to investigate the issue, citing this thread as the official guidance.
If you have a support channel through MSFT from your business, please open and escalate an issue. It doesn't feel like the people engaged in this conversation realize the implication of their actions and I haven't yet found someone to take responsibility for fixing it.
Received via email:
Thank you for contacting the Microsoft Security Response Center (MSRC). We appreciate the time taken to submit this issue.
We are aware of the issue you have reported regarding the MSIX installer. While this issue doesn't meet the definition of a vulnerability that MSRC can help with, we are aware that the issue is being supported through the following resources:
<"https://docs.microsoft.com/en-us/windows/msix/app-installer/installing-windows10-apps-web"> -> "The ms-appinstaller scheme(protocol) has been disabled."
<"https://techcommunity.microsoft.com/t5/msix-deployment/the-ms-appinstaller-protocol-has-been-disable..."> where Aditi_Narvekar from Microsoft has replied.
and you may also contact support for more information:
Contact Us - Microsoft Support
We have also shared your feedback with the engineering team who own the ms-appinstaller scheme(protocol).
As such, this MSRC thread is being closed and no longer monitored. We apologize for any inconvenience this may have caused. More information on reporting a security vulnerability can be found at <"https://www.microsoft.com/msrc/faqs-report-an-issue.">
Dec 21 2021 08:49 AM
@Aditi_Narvekar Could you provide us any additional information on this? This has serious implications on how we distribute certain apps.
Can you at least confirm at least if it will eventually be restored? I understand if you cannot provide a timeline yet but we would like to know so we can plan accordingly. I would hate to go through the trouble of implementing an alternative (albeit less effective) approach only to have it restored shortly afterwards.
Dec 21 2021 09:50 AM