Possible regression with .Net 7
Xeio opened this issue · 6 comments
Hmmm, so upgraded my project to .Net 7 yesterday and got a new report from a user after I hadn't heard a peep after adding the AV protection a few months ago.
Die Datei [...]\Mozilla\Firefox\Profiles\b93zdwlj.default-release\storage\default\https+++lostmerchants.com\cache\morgue\33{c36484e8-6fc5-42bb-b202-371d08f9d421}.tmp ist mit Trojan.Upatre.Crypted.2 infiziert.
Honestly not sure this is even actionable at the moment but figured I'd bring it up in case anyone else runs into it. I ran VirusTotal against my site and the DLL URLs that had caused issues prior to adding BWAP and they come back clean. Looks like it's some sort of temp file in the cache created by Firefox, the only files I even have in that directory are ".final" files and they all exist as unique GUIDs so good luck on me trying to figure out which cache item it could even be.
Could be some change in the framework or maybe not.
Thanks for reporting this. I will upgrade the sample apps and the apps that I have that use this package to .net 7 soon, and see what happens
I tried running the whole Firefox cache directory of ".final" files through VirusTotal as a zip and it seems to have detected something, though won't tell me which of the 89 files might be the problem. Not that there's an easy way to figure out which file goes with which cache item anyway. 😬
I poked at it a bit and deleted everything from the cache till just Microsoft.Extensions.Logging.Abstractions.dll was left, since that was a problem back before I was using BWAP, that file does not get detected so... might be something new or it's just a fluke that particular DLL doesn't trigger a false-positive for my project anymore.
Minor update, it seems to be the primary client DLL of my project itself (not any of the .Net or other libraries) that's triggering the AV, though it's not detected when downloading directly. Had to comb through the files a bit and the sqllite cache file for firefox to figure out which dll it was.
Possibly the cache for the primary Blazor client DLL isn't being xor'd while stored for some reason? It doesn't seem to be the raw DLL on the file system (xor'd or not), but I'm guessing Firefox may be doing some compression.
Maybe it's all some really unlucky fluke? I tried changing the xor key from the default and suddenly none of the files seem to be detected. So either bad luck or they've caught onto "bwap" or something odd like that.
Gotta love AV vendors in any case. 🙃
Feel free to close or not, might be worth seeing if your other samples have similar behavior. I'd recommend just taking the whole /cache/morgue/ folder for the site in Firefox from the app data, zipping it, and uploading it to scan to do a quick check.
Still really strange that it only detects the file on the file system inside the firefox cache, not when the xor'd file is uploaded directly. 🤷♂️
Thank you. This is important feedback. Maybe the key must be more complex by default, but then the size of the compressed assemblies get larger. It is difficult to find a balance
The default key got a little longer in the latest releases. Thank you for your feedback.