How does whitelist handle this problem?

Whitelists are clearly a useful tool to help eliminate false positives which have been identified as benign after testing and experience. This and other benefits mean we will be using whitelists to increase usability, eliminating alerts in cases where they are very likely just a nuisance.

A disturbing problem with software is the rather common occurrence that a trusted and security conscious vendor of a trusted piece of software updates that software but in the process creates a new vulnerability. Often, as has been the case too many times to relate, widely used apps like Adobe (poster child for this problem perhaps) patch one thing only to create another problem. Whitelisting by vendor or by app can mean that the newly insecure software might be allowed, with resulting security risks.

Can D+/CSI “trust” of whitelisted apps guard against this annoying aspect of software development? Is the Whitelist database robust enough to identify and treat differently updates?

When an update is identified as insecure, or vulnerable to exploit when the previous version was not, can we be alerted to this threat by CSI/D+? It certainly would be a desirable feature of CSI to incorporate a feature similar to Secunia to monitor our systems and alert us to new security information.

Obviously a whitelist creates risks, but such a development would help mitigate the risks!

From the online help pages Unknown Files: The Sand-boxing and Scanning Processes:

When an executable is first run it passes through the following CIS security inspections:

Antivirus scan

Defense+ Heuristic check

Buffer Overflow check

If the processes above determine that the file is malware then the user is alerted and the file is quarantined or deleted

An application can become recognized as ‘safe’ by CIS (and therefore not sandboxed or scanned in the cloud) in the following ways:

Because it is on the local Comodo White List of known safe applications

Because the user has added the application to the local ‘Trusted Files’

By the user granting the installer elevated privileges (CIS detects if an executable requires administrative privileges. If it does, it asks the user. If they choose to trust, CIS regards the installer and all files generated by the installer as safe)

Additionally, a file is not sandboxed or sent for analysis in the cloud if it is defined as an Installer or Updater in HIPS policy (See Computer Security Policy for more details)

It it would trigger a buffer overflow situation it would be caught before even white listing could allow it.

So, B/O problems are covered, but other security vulnerabilities introduced by a patch might be a problem.

Buffer overflow is the most used way a malware can install its self without the user getting notified.

What other security problems are you referring to?

If patched software is given a clean bill of health by default AND avoids the scrutiny of D+ then presumably any security vulnerability that D+ would catch could be introduced. I’ll grant you that the B/O protection is the most likely vector for infection through programming error. But patching code might well short circuit bug fixes and other security measures previously built into the software that had earned whitelist status. It has happened repeatedly with Microsoft system patches, Adobe and other software which has been actively supported and revised frequently.

I don’t know the answer but I use secunia to scan my system for software with security vulnerabilities and know that the status of software as “trusted” is very tricky to establish and NOT stable over time.

My suggestion is that if we trust a whitelist that whitelist has to be dynamic and under constant review. it is dangerous to assume that what was once “prove” secure and trustworthy will be trustworthy in the future.

Of course, the other obvious problem is that a previously unknown security flaw is uncovered, making the whitelist problematic. Whitelists are justifiable and preferable to users simply clicking “allow” for software “they really want to use” but it is not foolproof. It seems highly desirable that local “whitelists” created by user choice and the Comodo default “whitelist” be constantly reviewed. An adjunct something like secunia or the other databases online available that reviewed installed software on the user system during virus scanning or other independent scan would be a way to capture the changing landscape and warn users they are using (whitelisting) vulnerable software.

Interesting line of thinking. A function to please the more advanced users.