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 documentation on how to safely run repro projects #45341

Open
dsplaisted opened this issue Dec 5, 2024 · 6 comments · May be fixed by #45456
Open

Create documentation on how to safely run repro projects #45341

dsplaisted opened this issue Dec 5, 2024 · 6 comments · May be fixed by #45456

Comments

@dsplaisted
Copy link
Member

We should create guidance on how to safely build and run repro projects, since building or running a project implies that you trust it. This could be separate guidance, or it could be part of #45340.

If using Windows, the guidance probably involves using Windows Sandbox, and possibly how to script it to set up an environment.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-NetSDK untriaged Request triage from a team member labels Dec 5, 2024
@Forgind Forgind added needs team triage Requires a full team discussion and removed untriaged Request triage from a team member labels Dec 10, 2024
@Forgind
Copy link
Member

Forgind commented Dec 10, 2024

I think we should do this sooner rather than later. Also, can we have a security label? I think that'd be useful given Microsoft's overall push towards security.

@marcpopMSFT
Copy link
Member

marcpopMSFT commented Dec 10, 2024

Recommendation in this order:

  1. Share a binlog
  2. Try the repro in a locked down environment like sandbox
  3. Try to recreate the repro yourself without the customer application
  4. Try the repro in an environment without your credentials
  5. Examine the repro for any risky actions per Create documentation about trust boundaries of the .NET SDK and how to use it securely #45340

Next steps:

  1. Create an .MD file in our repo
  2. File an issue in the docs repo linking back to the MD
  3. Once a document exists, modify our MD file to link to the official docs

@marcpopMSFT marcpopMSFT added this to the 10.0.1xx milestone Dec 10, 2024
@KalleOlaviNiemitalo
Copy link
Contributor

KalleOlaviNiemitalo commented Dec 10, 2024

Is MSBuild intended to be secure against a malicious binlog? I mean if a threat actor crafts a binlog and sends it to you as a fake repro and you replay it through MSBuild.

@Forgind
Copy link
Member

Forgind commented Dec 10, 2024

Is it possible to craft a malicious binlog? My impression was that the reader looks for specific pieces and turns them into the associated events, and it just fails if something looks wrong.

@KirillOsenkov?

@KalleOlaviNiemitalo
Copy link
Contributor

I wonder if it would be possible to post an MSBuild,binlog file that resembles MSBuild.binlog at a glance, but FileUtilities.IsBinaryLogFilename returns false, so BinaryLogReplayEventSource is not used and the file content is actually XML that then gets evaluated as a project.

@Forgind
Copy link
Member

Forgind commented Dec 13, 2024

I wonder if it would be possible to post an MSBuild,binlog file that resembles MSBuild.binlog at a glance, but FileUtilities.IsBinaryLogFilename returns false, so BinaryLogReplayEventSource is not used and the file content is actually XML that then gets evaluated as a project.

I don't know why this is true, but it didn't seem to work when I tried it. I ran the following:

C:\bugs\temp2>dotnet build "MSBuild,binlog" --no-restore
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  MSBuild,binlog failed with 1 error(s) (0.2s)
    C:\Program Files\dotnet\sdk\9.0.200-preview.0.24529.19\Microsoft.Common.CurrentVersion.targets(3171,7): error MSB4057: The target "CreateManifestResourceNames" does not exist in the project.

Build failed with 1 error(s) in 0.5s

C:\bugs\temp2>dotnet build temp2.csproj --no-restore
You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy
  temp2 succeeded (2.6s) → bin\Debug\net9.0\temp2.dll

Build succeeded in 2.9s

C:\bugs\temp2>

Between the first and second command, I renamed MSBuild,binlog to temp2.csproj.

As you can see, the first build failed, and the second succeeded. I'm not clear as to why CreateManifestResourceNames is connected, though, as I didn't change the actual contents at any point...so I think that still counts as not 100% sure, but it seems like no? If it failed, I would've expected something more like "couldn't find a .*proj..." or something like that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants