AutoSandbox exclusion based on hash and not path?

[RejZoR]

Am i the only one who thinks path exclusion is bad? It would make a lot more sense to make hash exclusion that is path independent.

This way you solve two things at once:
1. Files that appear clean but auto-update into something bad, yet they remain excluded due to path
2. Installers/uninstallers that generate random named temporary file/folder data which never gets excluded properly even when found clean by the analysis of AutoSandbox (hash would probably be the same regardless)

Since AutoSandbox events aren't as densely processed as file scanning i think generating a secure hash for it should be no problem as far as CPU usage goes.

Or at least have hash exclusion as default and path exclusion being an optional choice to the end user if he choses to exclude something based on path.

[DavidR]

I think the problem is one of human readability in the exclusions list, who the h3ll knows what a hash number pertains to when/if there is no other information displayed.

The people who use avast are humans (hopefully) and not machines so they need visual clues to identify what they have excluded. Should they ever need/decide to remove the exclusion.

[RejZoR]

Well you can still list them with path and filename but the hash would actually exclude it and path and filename would only be as reference to which file was excluded.

There aremany other things far less understandable than term "hash" so i don't see this as a big problem.

[igor]

Well, it's not that simple.
Excluding a file by hash means you might need to enter a lot of hashes, instead of one folder - for example (so adding the hashes for all the temporary files an installer generates might be hard). Besides, to compute the hash, you need to have the file (so you can't set an exclusion in advance, for unknown files - like your own, you're gonna compile yourself).

Don't get me wrong, I suggested adding a possibility of a hash exclusion (and why only for AutoSandbox - it should be there for FileSystem Shield etc. as well) quite a while ago already. I'm just saying it's not a magical solution of all problems, it's got its own issues as well. But as an optional parameter for the exclusion - I'd like to have it there (though a reasonable UI design is a question).

[DavidR]

<snip>

There aremany other things far less understandable than term "hash" so i don't see this as a big problem.

It isn't the term hash, but the physical number being the only reference that I made my comment on, a user not knowing what file it was for.

[RejZoR]

Igor, yes and no. That's why i said hash should be a default option since Auto Sandbox is always excluding single files but you could have an option to exclude by path manually. Kaspersky for example even goes so further you can exclude per threat name and other settings, meaning you can exclude it only under detection EICAT-TEST but not under anything else. I'm not expecting taht from avast! but i have found path exclusion to be very annoying several times with quite some installers and uninstallers. It kept on excluding files and installer kept on making new random filenames. And they were going like this forever untill i just killed it and excluded the darn thing manually.

[Lisandro]

It kept on excluding files and installer kept on making new random filenames.

Wouldn't this be a malware behavior either?

[RejZoR]

It's not a malicious app or installer. Some installers just do this to avoid conflicts with other installers, so they generate random file names for its files.

[Lisandro]

It's not a malicious app or installer.

I know... You need to say this to the antivirus engine...

[RejZoR]

Actually no. Here is how it goes now:

1. Installer executes and gets Auto Sandboxed
2. Installer creates temp_file1.tmp inside sandbox
3. Auto Sandbox finds nothing malicious and gives the Continue execution button
4. temp_file1.tmp is added to exclusion
5. Installer is executed again but this time it creates temp_file55.tmp
6. avast! Auto Sandboxes it again because the path is now different

This is how it should work:
1. Installer executes and gets Auto Sandboxed
2. Installer creates temp_file1.tmp inside sandbox
3. Auto Sandbox finds nothing malicious and gives the Continue execution button
4. temp_file1.tmp is excluded using hash value
5. Installer is executed again but this time it creates temp_file55.tmp
6. Installer works normally because the hash of temp_file1.tmp and temp_file55.tmp is most likely the same regardless of its filename

Other way would be to be aware of the parent/child app/files relationship and allow or block execution based on that. But hash exclusion would do the job for the time being.

[igor]

The first part doesn't really make sense to me (with respect to the latest update at least).
If the installer is autosandboxed, then the installer itself (whose name is probably fixed) should be added to exclusions - not the child temp file created by the installer.
If it's the child file (or rather process) that gets autosandboxed, then the parent call is stalled and waits for the result - and when the result is OK, it continues (so there is no "executed again", it just goes on).

So I find it more likely that those two temp files are actually different (i.e. that the parent creates multiple child processes, each with a different executable).
If I'm wrong, let PK correct me, but I don't think you get any results (i.e. no exclusions either) from the child processes of already autosandboxed parents.


Edit: Or do you mean two unrelated executions of the same installer (possibly a couple of days later)? Then OK, it would make sense.

[RejZoR]

My mistake on that part which i found out after you pointed it out. Installer (parent) didn't get sandboxed, temp file (child) did. So it kept on sandboxing the temp files and excluding them and since filename generated by the installer was different each time, it was also sandboxed again because exclusion didn't apply anymore.

It's hard to reproduce such scenarios because such stuff usually all of te sudden doesn't work the same way or doesn't even get sandboxed anymore, probably due to cloud feedback that has changed in 1 day time period.

[pk]

RejZoR is right, but I have some comments. Autosandbox is triggered only on the first suspicious file, i.e. all child processes are sandboxed automatically if the parent process is virtualized. What does it mean in fact? If the main installer is trusted, it usually unpacks a few/lot of files in temp folder. Every such executed app from temp will mean a garbage in our exclusion list. Autosandbox exclusion list will be probably improved in R4 update (say in ~3 months), there're several limitations in the current avast version I don't like (all paths are bound with volume letter, stored in avast5.ini, etc). I don't like hashes, because their computation is quite slow -- but I can realize combination of filepath & hashes (e.g. temp exclusions can be recognized by hashes, others by filepath). This won't fix all problems, but it'd help a lot. The other problem is with avast global exclusion list, we can think it over for R4 build.

[RejZoR]

Hashes are not THAT slow. I mean it's not like you get 100 apps sandboxed and excluded per second. If you get like 5 apps sandboxed per day and i'd say that is a fairly high number. I think even a 1GHz CPU would deal with that...

[GTX66]

This auto sandbox is a real winner, whoever developed it must be playing in one. Microsoft Updates and Firefox should not be auto sand boxed.