CIS should distinguish actual file change vs. file just being opened for writing

CIS should distinguish between actual file change and file being merely opened in modify/write state

CIS does not distinguish between actual file change and file being merely opened in modify/write state.

CIS should look deeper into a file (not just the “modify date”) whether the file has changed or not.

There are files that are opened in modify/write state, and this leads to modify date change even when the file is not actually changed at all.

An example of such a file is a Firefox add-on/extension called FlashGot.exe.

Please see full pathname, user names and profile names are obfuscated (below):

G:\Documents and Settings\User_Name1\Application Data\Mozilla\Firefox\Profiles\ixbwyok1.default\FlashGot.exe

G:\Documents and Settings\User_Name2\Application Data\Mozilla\Firefox\Profiles\5u1hnnok.default\FlashGot.exe

G:\Documents and Settings\User_Name3\Application Data\Mozilla\Firefox\Profiles\tl32tfm1.default\FlashGot.exe

More info about this FF extension/add-on can be found at https://addons.mozilla.org/en-US/firefox/addon/220

It is a very popular FF extension, 62,136,343 total downloads (by Monday April, 20 2009), so would expect other users have the same combination of SW (CIS, Firefox with FlashGot extension).

The Option of having this type of specific file(s) stay in My Own Safe Files (even after nominal “modification” of file) would of course have to be implemented automatically for this type of file(s) only.

Please note that the file is not actually altered, it would appear it is merely opened in modify state. The MD-5 and SHA-1 hashes for the file are constantly the same. The file is also actually modified sometimes of course, but that happens seldom and only then should the file be moved to Pending Files.

CIS could look deeper into the file(s), so that it would distinguish between real modification and the files merely being opened in modification mode?

As CIS functions now, it leaves the unnecessary and redundant research of the nominal “modification” to the weakest link, the user.

Even with programs calculating MD-5 and SHA-1 hashes, it takes time for the user to review whether the file has actually changed or not. In addition the user would have to take notes of the file size or at least the hash values. Memorising the hash values would in my opinion fit a lot better to a security application, such as CIS, instead of a human being (the user).

Implemented automatically by CIS, it would in my opinion increase security, since the user would only be alerted for review of file, when the file has actually changed.

That would best be implemented as an automatic calculation whether the file has changed or not by CIS using, e.g. MD-5 or SHA-1 algorithms.

Peter

This may be achievable IF there was a caveat applied to the changes - i.e. if FlashGot.exe is modified by firefox.exe leave it in the Safe Files list, but if it is modified by any other application, then move it out of the safe list.

Cheers,
Ewen :slight_smile:

Ewen,

Thanks for comment.

If I understand it correctly, Firefox does not change the file, not at least in my examples. The file is not actually changed at all. It is merely opened in modify/write state, hence the modify date changes, nothing else. The file itself (the contents of the file) does not change, and hence, e.g. MD-5 and SHA-1 hash values do not change, they remain the same, prior and post opening the file even in this manner.

What I wish and suggest is that CIS would check whether the file actually changes, or is it merely opened in modify/write state and not altered by content at all. In my opinion the latter is not actually a changed file at all.

The check would be easy to automate and implement in CIS, using, e.g. MD-5 or SHA-1 hash algorithms and recording the hash value (in addition to modify date).

For checking most files there would be no slow down, when there would be no change in the modify date and there hence would be no need for the subsequent check, i.e. check of the hash value. Only when the modify date is changed, only then CIS would check the respective hash value against the file and determine whether an actual change in the file has taken place or not.

It would be okay and even preferable to move the file in Pending Files, no matter what (executable) changes the file (Firefox.exe or any other executable).

Peter

+1!

Hey Peter,

Sorry for the late response.

I didn’t mean Firefox changed the file, I meant that if Firefox was the parent of FlashGot.exe, then allow the file to be opened in modify mode. If FlashGot.exe has a parent OTHER THAN FIREFOX, then display an alert and remove it from the list of Safe Files.

Cheers,
Ewen :slight_smile:

I didn't mean Firefox changed the file, I meant that if Firefox was the parent of FlashGot.exe, then allow the file to be opened in modify mode. If FlashGot.exe has a parent OTHER THAN FIREFOX, then display an alert and remove it from the list of Safe Files.

Ewen,

Thanks for reply.

It would appear that FF opens the following files in modify mode, all residing in the following folder (username and profile name obfuscated); G:\Documents and Settings\User_Name2\Application Data\Mozilla\Firefox\Profiles\5u1hnnok.default\

parent.lock
FlashGot.exe
flashgot.log
prefs.js
urlclassifierkey3.txt
localstore.rdf
places.sqlite
places.sqlite-journal
sessionstore.js

Why FlashGot.exe is opened in modify mode, is not clear to me. It is an executable, and the content of the file is not changed at all. Due to the way it is opened, the modify date changes at every launch of FF. Due to this behaviour CIS thinks the file has changed, even if the contents of the file is unchanged, and when only the file attribute (Modify Date) has changed.

Would prefer that CIS would not flag the file as a changed file based merely on the fact that the Modify Date changes. CIS should look deeper in the file and flag the file as a changed file, only when the contents of the file changes, and only then move it to Pending Files.

It should be easy for CIS to distinguish between actual file change and file being merely opened in modify/write mode. Existing MD-5 or SHA-1 algorithms could be used for that purpose. This research (calculating the MD-5 or SHA-1 hash for the file and comparing the result to the stored, previous hash) should only be performed, when a change in the Modify Date has takes place. That way the overhead would be minimized, when the calculation of the hash value would only be done when a change in the Modify Date occurs. This way it would be very easy for CIS to distinguish between actual file change and file being merely opened in modify/write mode. As CIS (.477) behaves now, the unnecessary and redundant ever again occurring review of this type of files is left to the weakest link, but the most valuable resource (requiring human interaction), the user.

Dear Forum members, if you support this request, please kindly show your support by, e.g. “+1” and “ditto” posts, which do not require much hard labour. That way chance of inclusion of this feature in a future version/release of CIS should increase. Thanks in advance for cooperation.

Cheers,
Pete

+1!

The Joker,

Thanks for your support!

Pete