dcwhittaker commented 1 year ago

Microsoft Security Advisory CVE-2022-41089: .NET Remote Code Execution Vulnerability

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in .NET Core 3.1, .NET 6.0., and .NET 7.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

A remote code execution vulnerability exists in .NET Core 3.1, .NET 6.0, and .NET 7.0, where a malicious actor could cause a user to run arbitrary code as a result of parsing maliciously crafted xps files.

Announcement

Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/242

Mitigation factors

Microsoft has not identified any mitigating factors for this vulnerability.

Affected software

Any .NET 7.0 WinForms or WPF application running on .NET 7.0.0 or earlier.
Any .NET 6.0 WinForms or WPF application running on .NET 6.0.11 or earlier.
Any .NET Core 3.1 WinForms or WPF application running on .NET 3.1.31 or earlier.

If the application does not utilize WinForms or WPF, it is not affected by this vulnerability.

Applications targeting Mac, Linux, Android, iOS, and other non-Windows platforms are not affected by this vulnerability.

If your application uses the following package versions, ensure you update to the latest version of .NET.

.NET Core 3.1

Package name	Affected version	Patched version
Microsoft.WindowsDesktop.App.Runtime.win-x64	>= 3.1.0, <= 3.1.31	3.1.32
Microsoft.WindowsDesktop.App.Runtime.win-x86	>= 3.1.0, <= 3.1.31	3.1.32

.NET 6

Package name	Affected version	Patched version
Microsoft.WindowsDesktop.App.Runtime.win-arm64	>= 6.0.0, <= 6.0.11	6.0.12
Microsoft.WindowsDesktop.App.Runtime.win-x64	>= 6.0.0, <= 6.0.11	6.0.12
Microsoft.WindowsDesktop.App.Runtime.win-x86	>= 6.0.0, <= 6.0.11	6.0.12

.NET 7

Package name	Affected version	Patched version
Microsoft.WindowsDesktop.App.Runtime.win-arm64	>= 7.0.0, <= 7.0.0	7.0.1
Microsoft.WindowsDesktop.App.Runtime.win-x64	>= 7.0.0, <= 7.0.0	7.0.1
Microsoft.WindowsDesktop.App.Runtime.win-x86	>= 7.0.0, <= 7.0.0	7.0.1

Advisory FAQ

How do I know if I am affected?

If you have a runtime or SDK with a version listed, or an affected package listed in affected software, you're exposed to the vulnerability.

How do I fix the issue?

To fix the issue please install the latest version of .NET 7.0, .NET 6.0 or .NET Core 3.1. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.
If you have .NET Core 3.1 or greater installed, you can list the versions you have installed by running the dotnet --info command. You will see output like the following;
If you are using one of the affected packages, please update to the patched version listed above.

.NET Core SDK (reflecting any global.json):

 Version:   6.0.300
 Commit:    8473146e7d

Runtime Environment:

 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.300\

Host (useful for support):

  Version: 6.0.5
  Commit:  8473146e7d

.NET Core SDKs installed:

  6.0.300 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:

  Microsoft.AspNetCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

If you're using .NET 7.0, you should download and install Runtime 7.0.1 or SDK 7.0.101 (for Visual Studio 2022 v17.4) from https://dotnet.microsoft.com/download/dotnet-core/7.0.
If you're using .NET 6.0, you should download and install Runtime 6.0.12 or SDK 6.0.112 (for Visual Studio 2022 v17.1) from https://dotnet.microsoft.com/download/dotnet-core/6.0.
If you're using .NET Core 3.1, you should download and install Runtime 3.1.32 (for Visual Studio 2019 v16.9) from https://dotnet.microsoft.com/download/dotnet-core/3.1.

.NET 7.0, .NET 6.0 and .NET Core 3.1 updates are also available from Microsoft Update. To access this either type "Check for updates" in your Windows search, or open Settings, choose Update & Security and then click Check for Updates.

Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.

Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.

Other Information

Acknowledgements

Eleftherios Panos with Nettitude Nick Landers with NetSPI

Reporting Security Issues

If you have found a potential security issue in .NET 7.0, .NET 6.0 or .NET Core 3.1, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime and https://github.com/dotnet/wpf/. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

External Links

CVE-2022-41089

Revisions

V1.0 (December 13, 2022): Advisory published.

Version 1.0

Last Updated 2022-12-13

bgrainger commented 1 year ago

I'd like to merge the fix into my fork, but https://github.com/dotnet/wpf/commits/release/6.0 doesn't appear to be updated with the latest code, and https://github.com/dotnet/wpf/tree/v6.0.12 "may belong to a fork outside of the repository."

Will the fix for WPF 6.0 be pushed to a branch on dotnet/wpf soon?

GrabYourPitchforks commented 1 year ago

@bgrainger Apologies about that. I spoke with some of our servicing team and the ETA for getting the commits pushed to the existing release/* branches is after the holidays. There's a backlog the normal crew is working through and I don't want to do anything to the branches manually that might interfere with their work.

However, I plan on submitting a PR with the fix to this repo's main branch tomorrow once I'm back in the office. It's identical to the fix that was checked in to the downlevel servicing branches, so it should be good to cherry-pick. Keep an eye out for that PR.

Hope that helps!

skrysmanski commented 1 year ago

Are .NET Framework applications affected by this?

GrabYourPitchforks commented 1 year ago

Are .NET Framework applications affected by this?

@skrysmanski Yes, a patch is available for .NET Framework 3.5 and 4.x applications. See https://devblogs.microsoft.com/dotnet/dotnet-framework-december-2022-security-and-quality-rollup-updates/ for more information.

akon47 commented 1 year ago

I tried to read an XPS document with images and display it on the screen, it will not be displayed images after windows update.

WPF native controls are not visible even in the DocumentViewer.

I tried the method described at https://devblogs.microsoft.com/dotnet/dotnet-framework-december-2022-security-and-quality-rollup-updates/ but it was the same.

please help me.

singhashish-wpf commented 1 year ago

@akon47 Could you please share the xps file with us? Also please confirm if you have run the powershell script mentioned in the KB article successfully. Thanks.

akon47 commented 1 year ago

@akon47 Could you please share the xps file with us? Also please confirm if you have run the powershell script mentioned in the KB article successfully. Thanks.

test_xps.zip

It looks fine in the Windows default viewer.

akon47 commented 1 year ago

@akon47 Could you please share the xps file with us? Also please confirm if you have run the powershell script mentioned in the KB article successfully. Thanks.

more xps sample.

test2_xps.zip

martindsa commented 1 year ago

The problem is for apps built in .NET Framework, and .Net Core 3.1 on Windows 10 with kb5021088 and Windows 11 with KB5020880 and script KB5022083 installed.

I prepared simple app which generates and displays XpsDocument to reproduce this. There are 3 projects and xps file. Only project with target framework .NET 5 works fine another ones displays white page. WpfBug7357.zip Is there any option to print and display XpsDocument with image from .NET Framework app?

GrabYourPitchforks commented 1 year ago

@akon47 @martindsa The KB article was just updated with more information. The KB article provides a primary workaround which should work for most people, plus a secondary workaround which can be used in emergencies. (See the warning text which accompanies the secondary workaround.) The KB article should unblock your scenarios.

akon47 commented 1 year ago

@akon47 @martindsa The KB article was just updated with more information. The KB article provides a primary workaround which should work for most people, plus a secondary workaround which can be used in emergencies. (See the warning text which accompanies the secondary workaround.) The KB article should unblock your scenarios.

After that registry setting, the XPS document looks fine in WPF app.

Any update planned to make it work normally without registry setting?

singhashish-wpf commented 1 year ago

@akon47 Yes, an update is being planned for that. The timelines, however, are still under discussion.

martindsa commented 1 year ago

Have you decided anything about an update, when it will be available? Disabling security update on clients operating systems is not a long term solution.

cplotts commented 1 year ago

This issue (not seeing images in an XPS document) is also affecting us. The recommended workaround in KB5022083 does not help us and we don't really want to do the alternate workaround (or rather ... suggest it to our customers) since it simply rolls back the security fix.

Our customers are currently down and unable to see images in their reports. We are contemplating a reworking of our reporting engine to avoid the issue ... so it would be really nice to know the timeline of your fix. That is, is it imminent? Or is it going to be in a few weeks? More than that?

Thank you!

ajt2018 commented 1 year ago

Add me to the list of people interested in how this can be fixed securely. We have lots of WPF applications which generate reports using images inside FlowDocument and XPS and this is going to be a huge issue pretty soon. Please give us a clue as to how "The Windows XPS Viewer application provided within the Windows operating system is not affected by this issue." was implemented ? Is the problem mainly with BlockUIContainer ? How else can images be embedded into FlowDocument ? Should we be creating FixedDocument or will that get the security "fix" in the next release ? Thank you in advance

pchaurasia14 commented 1 year ago

The Windows XPS Viewer application provided within the Windows operating system is not affected by this issue

The reason XPS Viewer application provided within the Windows operating system is not affected by this issue is because it does not rely on .NET API to process XPS documents.

We're working on restoring the images rendering within XPS that were blocked by the security update so that applications that are using images don't need to make any changes.

We'll keep this thread posted.

cplotts commented 1 year ago

We're working on restoring the images rendering within XPS that were blocked by the security update so that applications that are using images don't need to make any changes.

Do you have any idea on a timeline for that fix? Or can you post here when you have an ETA?

pchaurasia14 commented 1 year ago

Sure, we'll keep this thread up to date as soon as we have more information.

rysik007 commented 1 year ago

Hello, our comany has big problem as well since mentioned update has been updated. Please be aware that a lot of our product use xps to generate reports/printouts and we hope that fix will come soon.

bluebat-swiss commented 1 year ago

We also have problems with FlowDocument/FixedDocument not showing images anymore. I can confirm that it does also happen in .NET 4.8 Framework, not only in .NET Core. Workaround KB5022083 did not solve the problem. As a temporary workaround, we changed/rewrote our reporting system "quickly" to process OpenXml-Documents (Word) instead of XAML, so that our customer can work again...

There is at least our and another stackoverflow thread about this problem:

Microsoft should solve the problem of "Code Execution Vulnerability" on it's root and not just stop processing images as a solution. Any timeline for a fix would be great.

LarsKloseV commented 1 year ago

Same situation here: app running under .NET Framework 4.8, KB5022083 doesn't solve the problem and the alternate workaround of disabling the whole security fix cannot be recommended to customers either.

Similar to some in those Stackoverflow threads, we're using FlowDocument and Pagination to produce XPS. Is there any way to find out about types being affected and extend the "AllowedTypes" list contained in the workaround script accordingly? I'd rather recommend manually adding those types to the registry than disabling the whole security update.

Frustrating that Microsoft willingly breaks production apps rather than adressing the security issue more specifically :-(

ajt2018 commented 1 year ago

Frustrating that Microsoft willingly breaks production apps rather than adressing the security issue more specifically :-(

Can you imagine trying to develop a reporting solution at this time ? Where every example on the internet will not work, how much time (and money) could be wasted on trying to solve that !?

pchaurasia14 commented 1 year ago

@lke-v If your XPS uses StaticResource markup extension for processing resources, then you may not have any option other than to use the alternate workaround as mentioned in the KB article.

We're working to ensure that we can safely re-enable the use of StaticResource but only for allowed types.

JeffKryzer commented 1 year ago

In my observations, an \<Image> was converted to a series of \<Canvas>, \<Path>, \<Glyph>, and \<StaticResourceExtension> during the report generation. (I stepped through the .NET source code.) There appears to be no way to avoid using \<StaticResourceExtension> when you just want an \<Image> because of the conversion. If I add System.Windows.StaticResourceExtension to the registry, then the generation crashes with 'Provide value on 'System.Windows.StaticResourceExtension' threw an exception.' Line number '2' and line position '330'.

I worked on this for 2 days adding 30 different types to the registry like the KB article did and could not get past this.

LarsKloseV commented 1 year ago

@JeffKryzer thanks for sharing the experiences you had with your attempts! @pchaurasia14 will rendering an \<Image> from a visual tree to XPS be re-enabled? This is a crucial feature! Customers won't let us get away with disabling a security update...

pocodicom commented 1 year ago

Why was the fix for the security issue not reverted at the first sign of trouble? There were no known active exploits of the security issue in the wild but now an important feature of our application is broken in the field. For us, this security fix has caused more damage than the security issue ever would.

In the interest of transparency, can somebody add a link to the commit that caused all this trouble?

bgrainger commented 1 year ago

can somebody add a link to the commit

https://github.com/dotnet/wpf/commit/f422ebe82449cd9af0a0ccb3247089c9ad86a708

Merged in via https://github.com/dotnet/wpf/pull/7434.

ZipitoOverkill commented 1 year ago

We have a document management system app and we're using XPS to preview the individual documents. The XPS files are generated through a background task. With this update (or let's call it bug) we no longer can use this feature and our customers can't use the PowerShell workaround suggested from Microsoft because of their security policy. So is there an alternative? Maybe convert all documents to PDF files and use a PDF viewer?

rysik007 commented 1 year ago

We have a document management system app and we're using XPS to preview the individual documents. The XPS files are generated through a background task. With this update (or let's call it bug) we no longer can use this feature and our customers can't use the PowerShell workaround suggested from Microsoft because of their security policy. So is there an alternative? Maybe convert all documents to PDF files and use a PDF viewer?

The most common way to get pdf from xaml is by XPS :) But maybe there are other options..

ZipitoOverkill commented 1 year ago

That's a bummer... But Microsoft is working on a fix? Or is the PowerShell script the fix? ;)

pchaurasia14 commented 1 year ago

@ZipitoOverkill - We are working on actually fixing the code and once the fix is available, you wouldn't need the powershell script.

cplotts commented 1 year ago

@pchaurasia14 I hate to repeat this, but do you have any idea on the ETA of a fix? We have customers broken in the field and I am getting a lot of pressure from my management to do something about it. I would rather wait for a fix from Microsoft instead of rewriting our reporting infrastructure.

pchaurasia14 commented 1 year ago

@cplotts - We are working hard to find a way to re-enable the impacted scenarios without exposing the security vulnerability.

We have a fix approach that is being reviewed and tested and the goal is to have it in the earliest servicing vehicle that it is ready for. We are also looking at ways we could potentially make a fix available earlier than the standard servicing windows for those impacted.

psmulovics commented 1 year ago

@pchaurasia14 , can you implement a 'listener/logger' mode, where for example on DebugView you would be able to see all the types you need to add to the registry keys? This seems to be a very low impact change.

JeffKryzer commented 1 year ago

@pchaurasia14 , can you implement a 'listener/logger' mode, where for example on DebugView you would be able to see all the types you need to add to the registry keys? This seems to be a very low impact change.

That's essentially what I did on my machine when I figured out that \<StaticResourceExtension> was being used for an \<Image>. See my post above about the exception.

If anyone is interested in trying that yourself, the types that it uses must go through the RestrictiveXamlXmlReader.IsAllowedType() method. That's where it is checking the registry entries.

PeterLewisKSCLOUD commented 1 year ago

When it's fixed. Will the fix be released for Windows 8.1 or is that a no as it's out of support now?

cplotts commented 1 year ago

@pml-rbk the fix would have to be applied where they broke things (i.e. in WPF itself) ... so I would have to imagine that the fix would be for all operating systems. @pchaurasia14 ... correct me if I'm wrong.

pchaurasia14 commented 1 year ago

@cplotts - Yes, the fix will be in framework and will be rolled out as security update.

cplotts commented 1 year ago

We are at a point where we absolutely need an ETA of the fix ... our customers have been broken for 6 weeks! If you cannot provide an ETA, I will have to abandon our usage of XPS reports which I am loathe to do.

Please provide an ETA! Is it imminent? Is it another six weeks out?

LarsKloseV commented 1 year ago

I can only stress what @cplotts said. Having no ETA after weeks and no other sign that Microsoft takes this serious is simply unacceptable. However, I hear that a "private fix" (beta or what?) was delivered a few days ago to some large companies for testing? @pchaurasia14 would you please make some statement about the progress?

rbqm commented 1 year ago

If I understand the CVE correctly then:

The alleged security issue can only be triggered in WPF applications that read untrusted XPS files
Requires the user of such WPF application to be tricked into opening a specially crafted XPS file
Only affects the security of the involved WPF application

I don't know about other posters here, but our application does not read XPS files, let alone untrusted ones, and yet it is broken. I am willing to bet that most WPF applications that are broken by the security fix did not suffer from the security issue in the first place.

Please, Microsoft, in the future, do not take the same sledgehammer approach to fixing security issues as you have done in this case.

pchaurasia14 commented 1 year ago

UPDATE - We've released an OOB package that should address the XPS compatibility issues. You may refer to this link for more information on installing the fix.

We will continue to refine our approach on handling such vulnerabilities in future releases so as to avoid inconveniences to our customers.

Thank you for all your patience and feedback.

rbqm commented 1 year ago

Thanks for the update, the fix works for me.

Can you confirm that this fix will be rolled up in the next regular Windows update for the .NET Framework?

cplotts commented 1 year ago

Thank you, thank you, thank you ... for releasing the out-of-band update package! We have tried the update on Windows 10 22H2 .NET 4.8 and Windows 11 21H2 .NET 4.8 ... and both of those worked.

This gives me the confidence to continue with our usage of XPS reports.

Also, I want to reiterate @rbqm's question: when will this update be pushed out to everyone?

mailtoatique commented 1 year ago

Thanks for the update, this out-of-band update works for me.

pchaurasia14 commented 1 year ago

@rbqm @cplotts - Details of this OOB update shipping with regular Windows updates are under discussion. Once we have clarity on it, we'll update this thread.

cplotts commented 1 year ago

Another question @pchaurasia14. We do have users on other operating systems like Windows 7 and Windows 8. And I just tried to apply the out-of-band update for .NET 4.7.2 to a Windows 8 machine (after confirming that the issue is present on Windows 8).

What is the plan for applying the update to these older operating systems? Will that happen when the normal Windows update happens?

cplotts commented 1 year ago

@pchaurasia14 can you please provide an update?! It has been two weeks since my last question!

We have customers on older operating systems that are unable to apply the out-of-band update as I mentioned above.

We are now seeing situations where the out-of-band update is either getting rolled back or uninstalled when IT departments roll out the latest Windows updates ... causing the issue to surface again ... and the need to re-apply the out-of-band update.

What is the plan? When is Microsoft going to fix this in an at-large Windows update?

Microsoft's lethargy to fixing this ... is making us, your customers ... look bad to our customers. :(

pchaurasia14 commented 1 year ago

@cplotts - We are working to rollout the patch along with the next available security update. Currently, under review & testing.

rysik007 commented 1 year ago

Hello, is the fix included in latest windows update?

dotnet / wpf