The article refers to v.12.0.0.6810 so two releases ago. But I haven’t read anything about fixing these vulnerabilities on the changelog of v.12.0.0.6818 and v.12.0.0.6870.
Just from the standpoint of Comodo using file paths instead of file hashes to add to the local white list meant the devs using this type of methodology was always going to be abused.
As far as I can tell (might be wrong), as an initial fix all Comodo needs to do is make sure it always checks the cert for safe files OR creates a local store of file hashes for safe files, and checks with that each time an instance of an assumed safe file is launched.
I’m glad someone actually went ahead and created a working exploit.
Umm no, CIS never used just the file paths, it has always been based on file hash for the local file list.
As far as I can tell (might be wrong), as an [i]initial[/i] fix all Comodo needs to do is make sure it always checks the cert for safe files OR creates a local store of file hashes for safe files, and checks with that each time an instance of an assumed safe file is launched.
CIS already does this for every file that is executed, it determines both the file hash and checks for a digital signed certificate, which it then checks if the vendor is a trusted vendor or not.
The vulnerability is in the way CIS checks the PE file that is attempting to access a COM interface that is provided by cmdagent, to see if it is digitally signed either by Comodo or Microsoft. CIS would do this check using the on disk file path instead of parsing the PE file in memory to check for the digital signature.
By local white list I am referring to the Auto-Containment white-list (ignore) rules.
Comodo does not use a file hash when white-listing an individual file from containment via the Auto-Containment settings (including the Auto-Containment popup when launching an unknown executable file).
CIS would do this check using the on disk file path instead of parsing the PE file in memory to check for the digital signature.
That is what I said, they are using a file path to check the file.
As I say, I am not surprised that this type of methodology of only using file paths in certain scenarios to check files has resulted in an exploit like this elsewhere within the software.
UPDATE. Comodo has provided SecurityWeek the following statement:
There have been no reported incidents exploiting any of these vulnerabilities and no customers reporting related issues to us. The Comodo product team has been working diligently to resolve all vulnerabilities and all fixes will be released by Monday, July 29
This supposed vulnerability it can be partially true:
COModo: From Sandbox to SYSTEM (CVE-2019–3969)
But the POC is a fake!!!
If you do a precisely observation on the POC-video there is a little trick that in a real scenery (and Comodo well configured) it cannot work if the malware run fully sandboxed!
BTW:I have read the technical article and is very good… Congratulations to the author! :-TU
The alleged vulnerability is unlikely to be used by an attacker. When reading the text, it looks more like a theoretical thing than anything with practical implications.
There is always a lot of fuss when “vulnerabilities” are discovered in Comodo. IMO this fuss is most likely caused by the competitors. They have worse things than this being discovered on their side, yet the press remains silent. 88)
Still interested to see when Comodo folks will fix this.
This is patched apparently for enterprise versions of the software. Devs are apparently aiming for consumer versions to be patched by end of this week.