Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixing Microsoft Security Advisory CVE-2020-0605 : .NET Core Remote Code Execution Vulnerability (3.1 Fixed PR) #2428

Merged
merged 8 commits into from
Jan 15, 2020

Conversation

rladuca
Copy link
Member

@rladuca rladuca commented Jan 14, 2020

This PR addresses issues #2424, #2425

arpitmathur and others added 8 commits November 27, 2019 00:34
…ternal overloads of XamlReader.Load to use RestrictiveXamlXmlReader

Bugs:

- Bug [1006083](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1006083): MSRC 54120: XAMLReader.Load used by `GetFixedDocumentSequence` method which could lead to code execution [.Net Core 3.1]
- Bug [1006086](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1006086): MSRC 54179: Code Execution using Malicious Annotation Files for Sticky Notes in WPF apps [.Net Core 3.1]

###Description

Loose xaml can contain executable payload e.g. `ObjectDataProvider`. This Xaml can be included as part of `XpsDocument`s or base-64 encoded and then included in `StickyNote`s' annotation xml files.

In WPF, we were allowing `XpsDocument`s and `StickyNote`s' annotation xml files to be loaded freely via `XamlReader.Load`.

This exposes an attack vector - when a user downloads an XPS file from the internet for *viewing*, they could end up executing untrusted code.

The fix is to identify known dangerous types and limit them from being deserialized during XAML loading.

In order to accomplish this, we add new _non-public_ overloads to the `XamlReader.Load` method to enable the use of `RestrictiveXamlXmlReader`. `RestrictiveXamlXmlReader` restricts known dangerous types from being loaded while deserializing xaml.

We then call `XamlReader.Load` via `XamlReaderProxy`, which is an adapter for `XamlReader` type and uses reflection to access `XamlReader.Load`. Reflection is used to avoid adding additional public surface area to `XamlReader` in servicing.

Small changes are made to `TextRange` as well since the call-site for the `StickyNote`s case was through a call to `TextRange` which in turn calls into `XamlReader.Load`.

### Customer Impact

Customers would be protected from opening potentially-compromised XPS documents and stickynotes annotation xml files.

### Regression
No. This security issue was reported by an external party.

### Risk - Low

- This change only affects loading XPS documents and loading stickynotes annotation data.
- The change has been tested well internally.
  - We ran regression tests to ensure nothing else is inadvertently broken.
  - Validated against POC to ensure that the fix works as intended.

In .NET Framework, we are introducing a quirk to give developers/cusotmers the option of going back to the old (i.e., unsecure) behavior where deserializing dangerous types like `ObjectDataProvider` will be allowed. In .NET Core, no quirks are being provided - we do not believe that this is a scenario that should be supported for compatibility in a relatively new platform.
This reverts commit c86d4b9, reversing
changes made to 334d0ab.
@ghost ghost requested a review from vatsan-madhavan January 14, 2020 23:51
@ghost ghost added the PR metadata: Label to tag PRs, to facilitate with triage label Jan 14, 2020
@ghost ghost requested a review from SamBent January 14, 2020 23:51
@vatsan-madhavan
Copy link
Member

@mmitche I think this is better - it preserves the original commit from the internal branch. we'll recreate the tags after merging.

as far as i can see, i don't think we can do a branding update here - our versioning doesn't lend itself to updates for servicing releases.

wpf/eng/Versions.props

Lines 3 to 10 in c86d4b9

<PropertyGroup>
<VersionPrefix>4.8.1</VersionPrefix>
<PreReleaseVersionLabel>rtm</PreReleaseVersionLabel>
<DotNetUseShippingVersions>true</DotNetUseShippingVersions>
<AssemblyVersion>4.0.0.0</AssemblyVersion>
<SystemResourcesExtensionsVersion>4.7.0-preview3.19551.2</SystemResourcesExtensionsVersion>
<SystemIOPackagingVersion>4.7.0-preview3.19551.2</SystemIOPackagingVersion>
</PropertyGroup>

@vatsan-madhavan
Copy link
Member

note: do not squash when merging

Copy link
Member

@mmitche mmitche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, looks correct now.

@vatsan-madhavan
Copy link
Member

/azp run

@azure-pipelines
Copy link

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

@vatsan-madhavan
Copy link
Member

@rladuca - empty change - so no azp run. You can just merge it directly IMO. Remember to create a merge-commit and not a squash-commit.

@rladuca rladuca merged commit f53862f into release/3.1 Jan 15, 2020
@vatsan-madhavan vatsan-madhavan deleted the revertAndCorrectMerge31 branch May 28, 2020 20:09
@ghost ghost locked as resolved and limited conversation to collaborators Apr 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
PR metadata: Label to tag PRs, to facilitate with triage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants