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

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 notifications@github.com 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 .

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 notifications@github.com 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 .

@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 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

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?

@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.

@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 ?

@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.