Aspnetcore: New Blazor WebAssembly 3.2, Dll files are blocking by the antivirus sophos

[JoseLuisFab]

Describe the bug

I have created a new project with the template Blazor WebAssembly 3.2.0, and I have published locally IIS on windows 10, and the antivirus software is blocking the dlls files, i changed the file extensions but the antivirus blocks the files too, the antivirus software is sophos web protection.

I used the following lines to changes the dlls extension files, but it did not work.
dir ._framework_bin | rename-item -NewName { $_.name -replace ".dll\b",".blazor }
((Get-Content ._framework\blazor.boot.json -Raw) -replace '.dll"','.blazor"') | Set-Content ._framework\blazor.boot.json

To Reproduce

Further technical details

• ASP.NET Core version 3.1.300
• Include the output of dotnet --info
  PM> dotnet --info
  .NET Core SDK (reflecting any global.json):
  Version: 3.1.300
  Commit: b2475c1295

Runtime Environment:
OS Name: Windows
OS Version: 10.0.17763
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\3.1.300\

Host (useful for support):
Version: 3.1.4
Commit: 0c2e69caa6

• The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version
  Microsoft Visual Studio Professional 2019
  Version 16.6.0

[KieranDevvs]

I used the following lines to changes the dlls extension files, but it did not work.

Can you elaborate on this?

[JoseLuisFab]

I got that instructions in the following link https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/blazor/webassembly?view=aspnetcore-3.1
In the seccion called Change the filename extension of DLL files.

Change the filename extension of DLL files
In case you have a need to change the filename extensions of the app's published .dll files, follow the guidance in this section.

After publishing the app, use a shell script or DevOps build pipeline to rename .dll files to use a different file extension. Target the .dll files in the wwwroot directory of the app's published output (for example, {CONTENT ROOT}/bin/Release/netstandard2.1/publish/wwwroot).

In the following examples, .dll files are renamed to use the .bin file extension.
dir ._framework_bin | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content ._framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content ._framework\blazor.boot.json

[mkArtakMSFT]

Thanks for reaching out to us. We plan to follow up with the Sophos antivirus vendor on this and see how this can be addressed. To set expectations, we don't have a clear ETA for this, so it'll take some time.

[esben2000]

@mkArtakMSFT
We have the same problem with the firewall in our company. And I have tried the trick with renaming to ‘.bin’. Our firewall is checking the filecontent so renaming does not help. I think you need to switch strategy to provide an options where Blazor is not sending dll’s directly and instead sends them as base64. Else you need to talk to every antivirus company and every firewall company in the world and probably also with a lot of IT departments and convince them all that they should allow dll’s coming from the Internet.
I saw a suggestion where a user was delivering the dll’s as base64 text
https://github.com/jucchytil/CSBNotes/blob/master/Notes.md

[darcythomas]

Some AV and firewalls may be smart enough to recognize base64 dlls. Also
base64 takes more bandwidth. I think if we XOR the files with a random key
may work better.

The file size is the same (+ small key)

The key could be random per build, or even the build date.

GZip compression on the XORed files should be similar. Although brotli
probably won't be as good.

The de-XORing could be done by overriding/extending the XRequest .open
function.

Bonus idea: The key could be included in the file name e.g.,
SomeDll.base64Key.blazor.gz

Thoughts?

On Wed, Jun 10, 2020, 01:39 esben2000 [e-mail] wrote:

@mkArtakMSFT https://github.com/mkArtakMSFT
We have the same problem with the firewall in our company. And I have
tried the trick with renaming to ‘.bin’. Our firewall is checking the
filecontent so renaming does not help. I think you need to switch strategy
to provide an options where Blazor is not sending dll’s directly and
instead sends them as base64. Else you need to talk to every antivirus
company and every firewall company in the world and probably also with a
lot of IT departments and convince them all that they should allow dll’s
coming from the Internet.
I saw a suggestion where a user was delivering the dll’s as base64 text
https://github.com/jucchytil/CSBNotes/blob/master/Notes.md

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/21996#issuecomment-641303599,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQIWVRYCWKKT5S4SUBQ2VDRVY3QTANCNFSM4NFJVYLA
.

[mkArtakMSFT]

@esben2000 is the firewall you're using also Sophos? Or from some other vendor?

[mkArtakMSFT]

Just reached out to the Sophos. Hopefully will hear back from them soon:

[esben2000]

@esben2000 is the firewall you're using also Sophos? Or from some other vendor?

@mkArtakMSFT I do not know what brand our firewall is. I have contacted the security department but this is an information that they are not willing to share :(

[mkArtakMSFT]

Thanks @esben2000. I assume you will need to work out with them in that case to make sure non-suspicious files don't get reported. Unfortunately, without more details, we can do nothing.

In this specific thread, we're tracking Sophos false alarms specifically.

[esben2000]

@mkArtakMSFT Ok, but I think that you should consider that there are probably many companies that has a strict policy about not downloading dll files. So I think you should consider an options for serving the files as base64 content. It could be an option where we can choose if Blazor should publish as dll files or as Base64 files.
Or maybe like @darcythomas idea to XOR the files.

[noseratio]

@mkArtakMSFT I've just run into the same issues with error 403 for Blazor DLLs in Chrome while trying a test Blazor/WASM project (served from the internet via HTTPS) on a Windows 10 laptop with Symantec Endpoint Protection installed.

I think this issue will be getting increasingly real as more Blazor/WASM apps are out in the wild.

Is there anything I can help to further diagnose it? That said, I don't think I can do much, it's a locked-down machine and I can't event temporarily disable Symantec Endpoint Protection there. I don't have the same issue on my personal laptop with just Windows Defender, sitting next to it.

I think it is unreal to reach out to each and every corporate antivirus software provider out there to and convince them to add Blazor DLLs to their allow-list. I do like @darcythomas' idea of xor'ing and renaming files as a proper remedy.

[mkArtakMSFT]

@noseratio can you please confirm that you're facing this even after renaming the .dll files following the guidance provided here: https://docs.microsoft.com/en-ca/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-3.1#change-the-filename-extension-of-dll-files ?

[noseratio]

@mkArtakMSFT, I just got a chance to try it out on that machine again. Renaming to .BIN or .DAT or even .PNG didn't help, sorry. I suspect this machine's scanner has HTTPS inspection and MIME filters set up to prevents content that looks like Win32 DLL/EXE.

[hultqvist]

A related problem is that Sophos is blocking with 403 but the JavaScript console reports it as an integrity problem.
I guess Blazor is parsing whatever response it gets regardless of the response code.

SEC7136: [Integrity] Kilden 'http://example.com' klarede ikke en integrity-kontrol for en -ressource på 'http://example.com/_framework/_bin/Microsoft.AspNetCore.Components.bin'.

I would prefer the console message to reflect that the request was blocked rather than the 403 message didn't pass the integrity check.

[mkArtakMSFT]

We've done as much as we could by reaching out to different antivirus vendors. Unfortunately we can't control this and reach out to everyone. Having said that we think this will get resolved over time and there is nothing more we plan to do in here.

[hultqvist]

I wish you could plan something more.

What did you ask the antivirus vendor to do?

Did you offer them to do any type of modification to the file content so that they could let them through
knowing that a malicious file imitating this change will not be executable anywhere other than inside the webassembly runtime?

[darcythomas]

I think some form of XOR 'encryption' would be a good option to have.

But that aside, would it be possible for Microsoft to publish some kind of
form letter or press statement saying just blocking dll is over kill and
running dlls in a browser is safe, and a list of vendors who have fixed the
bug?

Then when we (the public) come across this issue with a new AV vendor, we
can raise a ticket with the AV vendor and point them the the official
Microsoft statement. That way there is some weight behind what we are
asking the AV to fix.

tl;dr; Crowd source the contracting AV vendor with the backing of a
statement from Microsoft.

On Thu, Sep 17, 2020, 07:03 Peter Hultqvist [e-mail]
wrote:

I wish you could plan something more.

What did you ask the antivirus vendor to do?

Did you offer them to do any type of modification to the file content so
that they could let them through
knowing that a malicious file imitating this change will not be executable
anywhere other than inside the webassembly runtime?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/aspnetcore/issues/21996#issuecomment-693600926,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQIWVU3FDJSNVSUQKXUBU3SGEDZJANCNFSM4NFJVYLA
.