We were discussing the file path/hash situation Firewall Rules for Changed application before.
the update on monday is only to fix the arp cache bug
It is not as big as you think.
First of all programs would never be allowed to do what you are doing. Programs cannot overwrite protected files. The user is allowed to do that; in fact the user is allowed to do anything to his or her system, including erasing CIS, Windows and all other files, without CIS interfering.
CIS is the nanny of program behaviour not the nanny of user behaviour. Program are monitored and limited where the user can do everything.
Even though there may be discrepancies with hash recognition of files, the user is still secure as he would have been alerted when an unknown program wanted to overwrite a protected file.
I reported it on the 18th of last month. 
So was there a problem in the beta that the mods get then and you reported it and maybe they thought they fixed it but didn’t ??
I had the problem, others did not. I don’t know if a fix was attempted prior to the public release.
Hi. About this Gp Code issue, that has been discussed in the forums. I understand in simple terms that no security issues exist if d+ set above from restricted to block and anywhere in between. Is this correct please?.
I currently have mine set as untrusted and am aware that the devs are looking at fixing the vulnerability.Why not just make default restricted and above, and pass on the other two settings?, or is there more to it, say usability issues on the restricted and above settings.
Regards
Dave1234.
I think Comodo’s answer would be something along the lines that upping the default Sandbox level will break too many applications and that will effect too many users who are not as inquisitive as the average users here at the forums.
I agree with EricJH.
Any setting above Restricted would simply make many programs simply not run. Which is just something great for a more security concerned person, but at the same time normal users can not understand why most of their programs are not running after installing CIS.
Educating all of them is not an easy task and is least expected.
I think COMODO is trying to come up with something more practical.
does def+ prevent gpcode in 5.4
Hey alexo, try downloading the latest Firefox Aurora (which is unsigned and not whitelisted) then watch what happens each time you update it. Below are some screen shots taken after the updater has run (the dates are in yank format 88) ). Same path each time “C:\ProgramFiles\Aurora\firefox.exe” but after each time the file .exe has changed the file gets sandboxed. It must be storing hashes otherwise how would it know firefox.exe is different. Nothing else has changed, the file isnt whitelisted locally or in the cloud (because its only just been released).
One possible explanation for what you are seeing is the hash is being scanned in the cloud. Maybe look at your Defence+ events to check. Or it could be something else entirely and i should keep it :-X
No
Cheers,
Matty
[attachment deleted by admin]
I would like to see a right-click context menu where a user can run an executable file at any sandbox level or run outside the sandbox rather than having to go into the program and set the level globally or
add the program to the safe files.
It would be good to have a window wthin CIS where we can see which .Exe’s are running at what sandbox level and you could change their level at any time. Having various sandbox levels for different exe’s would be nice rather than one global setting for all.
Matty, what makes you believe that what you’re seeing is indicative of file hashing? The events shown in the images posted, actually take place every time you run Aurora in the sandbox, regardless of performing an update. All they show is Aurora modifying a couple of process handles and sending a request to the DNS resolver. Take the sandbox out of the equation and if the executable path doesn’t change, there are no notifications that something may have changed.
It would be very difficult to implement this without restarting the application.
Changing access rights on the fly could bring system instability.
What im saying is why would Aurora get sandboxed again after an update if the file path is exactly the same as previously? Remember C:\ProgramFiles\Aurora\Firefox.exe is listed in Trusted Files so something must have been triggered to make D+ sandbox the executable again. If it was just looking at the file path it would surely just see C:\ProgramFiles\Aurora\Firefox.exe as Trusted and let it do what it wants.
Ive actually had about 10 C:\ProgramFiles\Aurora\Firefox.exe listed in trusted files because on first run after an update i get the sandbox alert, i ask it not to sandbox again, restart then all is fine and its added to the Trusted list along with the previous one(s).
Like i say i may be entirely wrong,
Matty
It’s entirely possible the sandbox is performing some kind of check, however, to my mind I believe it’s more likely something to with the application not being white listed.
My take on this is simple, although my logic may be flawed. You install an application on your PC, it’s registered in D+ and the firewall and everything is hunky dory. A few days later the program receives an update, which means the original executable has changed. regardless of whether the application is white listed, if file hashing is implemented, a notification by way of an alert should be presented. Hiding this information away in a log file, which in all probability, will never be looked at, is not exactly ideal.
Anyway, I don’t personally believe file hashing is currently implemented, but that’s how I see things and I would love to be corrected 
I don’t use the sandbox Eric, but that wasn’t the point of the post. However, telling me the file is unrecognised and has been sandboxed, is not indicative of a change to a file hash. Moreover, logically, should the check for a change to an executable be limited to the sandbox. Not everyone uses the sandbox and not everyone uses D+.
Logically, if file hashing were to be implemented in CIS, it should be at the level where regardless of which components of the suite are used, a check followed by a notification, precisely stating what has changed, is the only way.
Something Ronny wrote during the Beta phase of CIS 5.4 is what made me lean this way :azn:
Basically talking about multiple entries in the Trusted Files list and how the Purge function to remove obselete entries is not yet working correctly!
Possibly Egemen or another dev could give us a definitive answer but that`s unlikely!
:■■■■ Matty
If I understand Radaghast and the referred topic Firewall Rules for Changed application correctly then there is a request to extend the hash check to Firewall alerts as well as to the D+ alerts.
That would be something for Wishlist - CIS board.