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

Create document on safely executing repros Fixes #45341 #45456

Merged
merged 7 commits into from
Jan 30, 2025
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Malicious NuGet.Config
Forgind committed Dec 13, 2024
commit 14acf31282b0ed59a0b840bd80e7fa8d0a934ce7
1 change: 1 addition & 0 deletions documentation/general/ExecutingCustomerCode.md
Original file line number Diff line number Diff line change
@@ -51,6 +51,7 @@ Some examples of specific patterns to watch out for that can cause issues includ
2. MSBuild SDKs. At the top of many .NET projects is a line that includes `Sdk="<SDK>"`. This automatically imports build logic associated with the specified SDK. If you are unfamiliar with the specified SDK, ensure it is secure before building any code including it.
3. MSBuild tasks. Within a `Target` block are MSBuild Tasks. Many of these, including `Exec` and `DownloadFile` execute logic that pulls code or build logic from the internet and may execute it. If you are unfamiliar with any MSBuild Task in a customer-provided project, ensure you fully understand its semantics before executing it (by building).
4. Typos. NuGet packages starting with Microsoft. and System. can only be pushed to nuget.org by Microsoft accounts, but Mircosoft and Sysstem are unregulated.
5. Malicious NuGet.Config files. Even if a PackageReference points to a package you're familiar with, perhaps even a Microsoft. or System. package, a NuGet.Config file can dictate searching in a different package source first that may not be secure and may include a malicious version of the package.

More examples of patterns that can easily be exploited by malicious users can be found [here](https://aka.ms/msbuild-security-documentation)
Copy link
Member

Choose a reason for hiding this comment

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

Other things to watch for:

  • .rsp files injecting the custom extensibility
  • autoinclude files - Directory.Build.[props|target], .user project files - as additional logic can be injected via those
  • location where we open the projects from - as e.g. opening from 'Downloads' folder is supectible to injecting logic from unrelated auto-include files that can be placed to Downloads with relatively low privileges
  • attempts to write to locations outside of the root of current repo/solution (especially to locations like drive roots, msbuild install location, nuget cache, etc.) - this can inject logic to subsequent unrelated builds
  • Some additional tasks of interest: [internal link] https://microsoft.sharepoint.com/:w:/t/ManagedLanguagesIDE/EX0mgFi9TGJEkAKi3JYd7_EBZxyaXX1-tIze9Hbi2megLw?e=QUnpME - this however doesn't feel like it should be in scope of this doc (especially on public repo)

Copy link
Member Author

Choose a reason for hiding this comment

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

These are good additions, but I don't want to overload this section with too many things to watch out for. I'd rather people following this option go to the security documentation you're working on and see a more complete set there 🙂