@netmc ,
These are some really good and very technical questions. I’m going to ping one of our product experts - perhaps he can provide some clarity here!
@dstokes1 - Can you be of assistance here?
@netmc These are great questions. I’m going to have to do some research as these are development/architectural items that are beyond my scope. If I get anything back soon, I’ll post here for sure.
@netmc Here are answers from Product Management that address your 4 questions:
1. We do not implicitly trust digitally signed applications: we use it as input into our threat intelligence engines but just because a file is signed (even by a well-known vendor), it isn't guaranteed that the file will be benign. Certificate theft is rampant across the industry where trusted software vendors' certificates are stolen and used to sign malware, leading it to only be an indicator of authorship, not a guarantee.
2. Webroot will scan files within sandboxes but there is no guarantee that an application sandboxed by the operating system will not be able to impact the broader system. So, we are still scanning and inspecting these files as even though they likely pose less risk, the risk is not zero.
3/4. Releasing files from the console should be a relatively infrequent action: we presently require local releasing to ensure the precise file is restored (the console operates off a summarized view of files and, as a mistake during restore from quarantine can introduce an infection, we are particularly cautious). That said, this sounds like an area where the user experience can indeed be improved. We will take this as an item to investigate soon to see if we can make the restore process more seamless.
In the meantime, if you have a copy of the file which is producing this false positive, please send it to us so that we can ensure it is proactively whitelisted.
Thank you for allowing me some time to get them addressed properly.
We will occasionally get an alert about a uncategorized file on our Macs. The error will always be something similar to the following:
MRT, Uncategorized file, \Library\Apple\System\Library\InstallerSandboxes\.PKInstallSandboxManager-SystemSoftware\BF320ED5-6C90-4CB6-B2F4-84E54AFD49FD.activeSandbox\Root\Library\Apple\System\Library\CoreServices\MRT.app\Con, 00000000000000000000000000000000,
The MRT will always be in a random sandbox location. I’ve talked with support on this and they said that this is a known issue and that Webroot’s whitelist only allows for MRT to be in one location, so when it is found in another location it throws this false positive. They also said that the only method for releasing this file and allow it is to put the device in an unmanaged profile and then release the file from the agent on the Mac directly.
I have several issues with both the false positive AND the way to fix it.
- Why is Webroot not using application signing to verify applications and still relying on whitelisting in this day and age? Almost every application should be digitally signed by the author. If the file is digitally signed, what does it matter what location it is in?
- Why doesn’t Webroot properly support application sandboxing? This has been present in Macs for a while now.
- Why doesn’t the mac agent and Webroot web console support releasing the file from the management console? This is the whole point of a management console--to not have to connect to endpoints directly to manage them.
- Placing the endpoint in an unmanaged profile just to release a file seems administratively excessive. The whole point of using a managed agent is to control everything centrally and needing to place a device into an unmanaged profile AND to then manage it from the local device to release a file goes against the idea of central administration.
This issue has been present for quite some time (about a year if not longer), and it has still yet to be fixed.
I completely agree with @netmc . I don’t find the response from Webroot particularly helpful. Regrettably, MAC management by Webroot overall seems to be half-baked. If we are selling our clients on being able to properly manage their COMPLETE environment but then having to isolate MAC’s to an unmanaged profile in order to ignore or allow errors that shouldn’t be flagged in the first place, then this is more than simply an issue where “the user experience can indeed be improved”.
Hi,
I have the same issue with the /Volumes/Backups of <computer name>/Library/Apple/System/Library/CoreServices/MRT.app/Contents/MacOS/MRT
under Big Sur. Webroot quarantines the file and then the Time Machine backup fails. The only way to reliably use Time Machine & Webroot with the past few MacOS versions I have found is to turn off scanning archived files in policies for EndPoint Protection (Webroot Anywhere).
You can also use an MD5 hash but this will change when the file changes version of course. You can’t use filenale and folder path as the folder location is dependent on the computer name for Time Machine backups now and webroot doesn’t recognise Mac system variables or wildcards in the folder names as far as I know.
Don’t know if “BF320ED5-6C90-4CB6-B2F4-84E54AFD49FD.activeSandbox” is treated as a compressed file, but if it is, this could work.
Not ideal, but Backups are critical as well, and can save you if security software fails. And Webroot should still be able to slow/stop an active infection.
I have the same issue. Any tips for solution?
