Sophos Anti-Virus - On Access Cache Scanning functionality

Hello LoXodonte,

it "always" had an in-memory cache, since 10.3 it's backed up to the AV\Config directory to preserve it when the service restarts. Can't say though if a cold boot invalidates the cache. AFAIK a file is first checked if its type is eligible for scanning, if yes then the file is "fingerprinted", and if not known subsequently scanned. Furthermore the cache size is bounded. That's about all I can say.

Christian   

Thanks for the reply Christian,

Cold boot does not appear to invalidate the cache, but I'm wondering if a virus def update might. Also, you say the cache size is bounded, so older cached items will eventually get phased out and need to be rescanned? 

Would it be a terrible idea to add on-access folder exclusions for the .NET framework files being scanned?

mainly it's the: C:\Windows\assembly folder, and the scanning of dlls within it. Which I don't fully understand because this folder doesn't appear to contain dlls.  What would an exclusion statement look like to exclude all dll files from scanning located in that directory path?

dll's load from here as well. C:\Windows\Microsoft.NET\assembly\

Hello LoXodonte,

a virus def update might [invalidate the cache]

good excellent point!

the scanning of dlls within it. Which I don't fully understand

use dir from an administrative CMD prompt or use an alternate method to view That annoying c:\windows\assembly folder (whereupon he exclaimed: "The thing's ramified - it goes on forever - and - oh my God! - it's full of DLLs!"). :smileyvery-happy:

Would it be a terrible idea to add on-access folder exclusions [...]?

I'm neither a security analyst nor a developer and my gut feeling could be completely wrong. While your run-of-the-mill threat might consider this location too complex to abuse it could be appealing to someone scheming a sophisticated (targeted) attack and it is (or used to be) used for example by ZeroAccess (but arguably a threat could at least partially be detected if only \assembly is excluded).    

If there were a general problem with .NET applications and/or the GAC we'd likely have heard. Thus I assume that there's room for improvement in the way the application has been built. Neither does On-Access scan files on its own (i.e. without them being opened by some process) not does .NET or some other component open a file just "because it's there". The scan of mscorlib.ni.dll (even though it's some 14MB) and one or two other DLLs shouldn't result in a 30 seconds delay. That's not to insinuate the application is poorly written - but certain methods might be better than others in a specific context.

Christian