Vulnerabilities in the azurelinux-3.0-net8.0-webassembly-amd64 image

[MichaelSimons]

• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/253
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/252
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/251
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/250
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/249
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/248
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/247
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/246
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/245
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/244
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/243
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/242
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/241
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/240
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/92
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/82
• https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/80

[MichaelSimons]

@sbomer - can you take a look at these vulnerabilities and try to address them? TIA.

[sbomer]

From @akoeplinger in #1285 (comment):

None of the vulnerabilities are relevant in our case since we don't run untrusted input and aren't using nodejs in a webserver context. Do you know if we can close them as "won't fix"?

@MichaelSimons

[mthalman]

No, not without going through a big exception approval process. The proper mitigation here is to update the configuration of the Dockerfile so that it doesn't reference vulnerable versions.

[sbomer]

From @MichaelSimons in #1285 (comment)

None of the vulnerabilities are relevant in our case since we don't run untrusted input and aren't using nodejs in a webserver context. Do you know if we can close them as "won't fix"?

I am not familiar with the EMSDK support model. I see the version we are on is well over a year now. Will we be staying on this version for the lifetime of 8.0? This feels like a recipe for numerous vulnerabilities over it's lifetime. Requesting s360 exceptions is not feasible for these. They are going to tell us to update our dependency.

[sbomer]

@akoeplinger mentioned in #1283 (comment):

@sbomer unfortunately upgrading emsdk is not as easy, the versions are not compatible. This needs to be reverted.

@akoeplinger what are the versioning requirements for our EMSDK dependency?

[akoeplinger]

#1291 will fix the issues too, except https://github.com/dotnet/dotnet-buildtools-prereqs-docker-internal/issues/240 since that one exists in the npm provided by Azure Linux through tdnf so they need to fix that upstream.

@akoeplinger what are the versioning requirements for our EMSDK dependency?

We essentially can't upgrade it as the versions are not ABI compatible and there are existing third party wasm libraries that would fail. In .NET 9+ we're using our own version of emsdk that we build in the https://github.com/dotnet/emsdk repo and ship as a nuget package, that's why we don't install Google's emsdk in the net9+ Dockerfiles anymore.