Comodo 3 and 4 path identification BUG

Comodo Internet Security - CIS Resolved/Outdated Issues - CIS
1

I’m not sure how aware some of you are, but Comodo’s path identification has always had an odd issue - it identifies an exe by its original path EVEN AFTER it’s been moved to a different folder.

Try it yourselves - put an exe called A.exe for example in C. So let’s say it is now C:\A.exe. Run it and comodo will have an allow/deny popup. Allow it. Now move the file to let’s say C:\Windows\A.exe and run it again. Comodo will NOT ask for allow/deny anymore. It will consider it’s the same file as C:\A.exe even though its path changed.

Moving the file to a different drive, such as D:\ will solve the issue and force Comodo to reidentify it but if it’s on the same drive, you can move it wherever you want, Comodo will still ID it by its old path.

This causes issues with some programs. For example World of Warcraft. When an update is available, WoW downloads the files in a torrent-like manner, and puts them in some kind of temporary folder. After download is finished the files overwrite the originals. But Comodo keeps on IDing the new files by their old paths(temporary download folder) even as it has the current paths allowed. This leads to an odd circumstance where you’re being asked to allow WoW.exe every single time you run it, and furthermore when you Purge Comodo’s program list, it will say that they are no longer located in the game folder even though they are – because it’s IDing the updated .exes by the path they were originally downloaded to.

Anyone who has ever had Comodo and WoW together, and had WoW on a different drive than C:\ will know this issue. The only fix for it is to allow the entire WoW folder, like D:\WoW*.* so that it doesn’t try to pinpoint the exact exes with the fault anymore. Alternatively the issue can be fixed by creating an entirely new WoW folder and moving the whole game there, then delete the old folder, forcing Comodo to re-detect their paths.

This issue has been around since ancient times with Comodo. Don’t you think it’s time to update the way Comodo detects the paths for running processes to something more robust?

2

I guess comodo identify exe or other critical files based on hash alike algorithm. :slight_smile:

3

Comodo doesn’t do hash checks on files. Modify an exe and it won’t ask for redetection. Nor does allowing an exe to run guarantee that an identical copy of it will run unrestricted.

The implementation for path identification seems to be done at filesystem level. I say this because when the file is moved to another drive or partition, redetection is forced.

Anyone who’s tried to move a folder with 3000 files on the same drive to some other place will know that the process is instant, without the need of each file being moved byte by byte. As far as the filesystem is concerned, files have their own ID on a partition, and everytime the files are moved to a different location, so long as they’re on the same partition, the only thing that Windows does is change the file’s location on the file table. The file and its ID aswell as data are left untouched.

Comodo seems to be using this system to some extent to ID files. This would explain why when the path of a file that Comodo knows is changed, as long as it’s on the same partition, it doesn’t react. Furthermore WoW seems to be confirming this to me. On my previous post I spoke of one of the 2 fixes for WoW being to create a new folder and delete the old one.

Well, when I move WoW’s files into the new folder, the mechanism stated above takes effect: instead of moving all 16GB of WoW into the folder, the file table just notes that the files occupying the space are located somewhere else. This makes the moving instant. FOR ALL FILES EXCEPT THE NEWLY UPDATED ONES, WHICH ALSO HAPPEN TO BE THE ONES COMODO IS GLITCHING OUT ON. They are usually WoW.exe and WowError.exe, these get updated on every patch, and they alone get a progress bar and are transferred byte by byte. This signals a refresh in their ID. And as a result of that file table refresh, Comodo also becomes able to properly detect them again instead of asking for access every single time.

In other words, a file detection bug fixed by simply playing around with the folders - move the files to a new folder, delete the old empty folder, then rename the new folder as the old one. That to me is clear proof of file table usage by Comodo to identify file paths. And it’s NOT doing it right.

4

Just wondered whether this problem (as described for WOW) generates repeated sandbox alerts, even if files are added to my safe files.

Best wishes

Mike

5

yeah I think that’s a known issue and unfortunate one’s too

6

It could very well be, though my SB is always off. One way to check is to take the sandbox-offending file, move it to a different partition or drive, then move it back. If that fails then the folder ID may be glitching. Create a new folder, copy all the program’s files into it, DELETE the old folder and then rename the new one to what the old was named. If it fixes it then it’s the same problem. Also check, BEFORE moving the file, if purging the program list reports that it no longer exists even though it’s still at its location.

Example:
File c:\program files\something\this.exe is sandboxed repeatedly

OPTION 1(file ID refresh):
-move this.exe to d:\ then move it back to c:\program files\something\

OPTION 2(folder ID refresh):
-create c:\program files\new folder
-move everything from c:\program files\something\ to c:\program files\new folder
-delete the now empty c:\program files\something
-rename c:\program files\new folder\ to the old name - c:\program files\something\ ← DO NOT RUN THE SANDBOXED APP BEFORE COMPLETING THIS STEP OR IT WILL REMAIN REGISTERED AS c:\program files\new folder\this.exe IN COMODO’S PROGRAM LIST EVEN AFTER YOU RENAME IT

Clearing the program from the list should not be necessary. If this fixes it, then you have basically fixed the sandbox problem WITHOUT EVEN TOUCHING COMODO’S SETTINGS. This would prove that comodo’s settings are right, but its filesystem management is not.

If Comodo insists on keeping the current file identification system they can actually make one use of it: have file path checked and SILENTLY updated everytime a program in the list is run. That way people won’t get the same alert twice for allowing a program and moving it. Or provide an option saying “this program has changed location since last run, but was classified as safe. would you still like to allow it? [keep current rules] [create new ones]”

Whatever they decide to do, Comodo MUST start to acknowledge path changes when they happen.

7

Thanks, that’s very useful. Just managed to mock up a sandbox alert caused by the above issue. So that will be very useful for bug diagnosis.

Re the changes you suggest, I think the devs will need to respond :). Sorry bit beyond what I can answer!

Best place to suggest them would be in the wishlist, I think.

Best wishes

Mouse

8

Meanwhile I think this info is usefyl for bug tracking purposes, so I will transfer to bugs.

Best wishes

Mike

9

Since this is a complex issue I am not entirely sure I can just dump it in the wishlist. However, if you can confirm for me what I have said then maybe it can be pushed into the higher ups’ attention. I would like you to check my started threads history. I have opened this discussion several times in the past over the last year in the bugs section but it did not once get a response.

Again I do not care how they decide to handle this(my suggestions, I’m not all that interested in pushing them forward), as long as they DO handle it. It is a bug, and some functionality in Comodo has to be changed.

10

The good thing is the developers know about this. :-TU

Josh

11

Hello Josh! It’s great to know that the devs are aware of the issue. My question is, since how long? I’ve been aware of it since some time around version 3’s middle age. I am looking forward for more feedback, specifically, if they have a timeline of fixing it.

12

Don’t have anymore info at this stage sorry. :frowning:

But let’s see what future CIS releases bring… Ive been aware for a while my self. Hopefully they can improve this at some stage.

13

Posted this for information here https://forums.comodo.com/news-announcements-feedback-ctm-b198.0/
but the question should be directed here I guess -

This path identification issue and corruption could they be linked?

Well nearly destroyed. Recovered more by luck than judgment. Let me explain.

Two machines with Comodo installed with Internet Security Premium (Free) for some time. Upgraded from 3.x a while ago with problems loading the virus database on both PCs but got the sorted. Comodo System Cleaner was installed on both machines while 3.x was operating.

Note that both machines are running XP Pro – one a 32 bit v2002 bit SP3 version while the other 64 bit ver2003 SP2 version. XP32 is a gateway (ics) for XP64 on a home network.

Now the problems. Current date is 19 June the issues started 4-6 days ago. Both machines were running 4.1.150349.920 Free, Database 5146 at the point at which XP64 was repaired. Installer on XP64 was correct as was the installer on XP32.

Fundamentally the only major difference is this machine has Acronis 10.0 backup sw. Symptoms were on the XP64 only; Initially this was seen when XP64 machine would require a system generated ChkDsk to run at boot up. Initially I took no notice but after a couple of times it appeared that this ChkDsk would only take place after a update of either the virus data base or the System cleaner. Note this was casual observation, but I turned off the auto DB update on the XP64 machine and all seemed ok.

A couple of days ago I took a look at the Comodo forum, didn’t find this thread bit another. Anyway, I came to the conclusion I would see if there was an updated prog & DB ver and see if the XP64 would behave, if not then I would remove Comodo and see if the problem still occurred. This is when it got worse.

Xp64 did a Db download maybe a Prog and possible a System Cleaner update too.

On re-boot the pc did a Chkdsk during this it told me that:-
Register Hive Software Corrupt
C:/windows/Prefetch/Oneinit(?).exe.30b18140.fp is corrupt and unreadable also imjmig(?).exe 03882F7a.pf
At this time the system del/corrected a number of files

On re-boot Chkdisk ran again automatically and deleted “duplicate object ids from a large number of file records.

System auto reboot gave a disk error and Acronis Boot Drive (partition) not found.
Tried to boot into Safe Mode – no good
Changed boot drive to DVD with XP64 OEM disk – tried to load windows (several times) – could not find OS or could not find HDD. On one occasion windows started to load but was Blue Screened after a while. (Note machine getting hot had to open side panel and use large external fan)

Ok so a corrupt boot sector, appear to be no way to recover it. I then decided to recover the data by install the XP64 320G HDD Partitioned as System & Data in to the XP32 machine slot 2.
On XP32 boot up ChkDsk ran automatically operating on local F drive (ie System drive from XP64). Cleaning of a load of files 10-15 minutes before XP32 operated nomally. Not sure if this is standard Windows feature ie to check the secondary HDD boot sector & repair if required but if it is it is very useful & nice to know.

Reinstalled 320g HDD into primary slot in the XP64 machine. On boot up the system gave me the option of Safe/SafeNetwort/PreviousGoodConfig - Choose Safe – all seemed ok.

Rebooted with internet & network disconnected. Removed Comodo AV & Reg Cleaner. (Note directory and files still in place C:ProgFiles (x86) but not listed in control Panel Add/delete Files)

Rebooted and make restore point called “After ■■■■■ up –I hope”

Installed AVG 9 updated and scanned ok – XP64 been operating ok for 24 hours after several shut down /start ups.

So what cause the initial corruption? Just a guess. I found a thread called Comodo 3 & 4 path identification BUG here
https://forums.comodo.com/empty-t57591.0.html
Could there be some confusion when applying updates???

The XP64 has two locations for Comodo
C:/Program Files/Comodo/ComodoInternet Scurity
*C:/Program Files (x86) /Comodo/Comodo System-Cleaner
Even after uninstalling this program, now why is that?

Long winded sorry!

Regards

14

Comodo and chkdsk conflicts were reported in the past. I cannot make a link between Comodo’s path ID and actual data corruption, even though Comodo IDs files at filesystem level in some way. The main reason for this is that the mechanism was not explained to me by any mod/dev so far, so aside from our independent observations there isn’t much else to go on.