Viruscope can cause file handle sharing violations for some progs [M861]

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

[ol]- Attachment #1

  • COMODO Firewall Beta 7.0.308911.4080
  • Windows 8.1 x64 (Version 6.3.9600)

[li]HIPS to Paranoid Mode

  • Cloud Lookup disabled
  • Trust applications signed by trusted vendors - disabled
  • Trust files installed by trusted installers - disabled
    [/li]
  • Clean install. Clean configuration.
  • None

[li]Make sure that Viruscope is enabled.

  • Run a program that may write to, close, then re-open a file with no file sharing options.
    [/li]
  • cmdagent.exe opened the file when it was written to and closed… then the original program re-opened the file before cmdagent.exe could close it, causing a conflict with the original program’s lack of file sharing flags.
  • It should be accounted for that programs may not create file handles that share access. cmdagent.exe should either suspend programs trying to access files it is scanning, or something else safer than immediately opening it.[/ol]

Attachment #2: Procmon log screenshot of normal operation. (Viruscope OFF)
Attachment #3: Procmon log screenshot of a failed operation. (Viruscope ON) (Tester application displays an exception)
Attachment #4: Tester program that cleanly shows the bug. (Requires .NET 4)

[attachment deleted by admin]

#2

I’m sorry, but I am not familiar with this. Can you either briefly explain or provide me with a link where I can understand how sharing violations affect the way in which programs run?

Thanks.

#3

tl;dr version: A sharing violation results in the same behavior as an access violation but with a different cause. The program cannot open the file.

When a program opens a file, it chooses two sets of options. The desired access, and the sharing options.

Most passive scanners will open a file with Read only access and Delete sharing options. This is the least restrictive possible. It means that other programs can even delete the file while the scanner is trying to read it.

The most restrictive possible is opening a file with Read+Write access and no sharing options. It means other programs cannot do anything with the file until the file handle is closed by the restrictive program. (I guess Delete access is higher)

In general, access flags could be: Read, Write, Read+Write and Delete.
In general, sharing flags could be: Read, Write, Read+Write, Delete and None.

It is good practice to use the lowest access you can get away with while allowing the greatest sharing you can get away with without allowing programs to mess with the intended state of your programming logic. (IE, don’t let a program write to a file you are currently writing to)

Now for the important part. It may be obvious that if the second handle on a file requires more access than the first handle shares, it will be denied. (Access Violation) The less obvious part is if the second handle’s sharing options conflict with the access the first handle has already acquired, equally it will be denied. (Sharing Violation)

For example, my tester program will spit out the message:

System.IO.IOException: The process cannot access the file 'C:\Test\output.bin' because it is being used by another process.

In my real-world example which caused me to discover this problem, my game was unable to save and sometimes load save-games. cmdagent.exe had an open file handle where the game wanted full access and was unwilling to share any access. (It was about to move a temporary file to a permanent name)

Some programs may gracefully accept the inability to open a file. Some programs will cover up the error and simply cause undesired results. Some programs will flat out crash.

#4

I should note that I seem unable to get my tester program to error out when on a mechanical hard drive. It errors out nearly every time when run on my SSD.

I’ll try modifying the program to work in more situations but in the end this problem is reliant on race conditions. If Viruscope can get in and out before the program re-opens the file, there is no problem… but hoping for a race condition to happen the same way every time is bad.

#5

It seems that it didn’t have to do with SSD vs mechanical drives. A different bug somewhere in Comodo was having trouble using Volume Mount Points in Windows.

(See Attachment Screenshot)
My program opens C:\Mounts\2000a\output.bin and is redirected to open \Device\HarddiskVolume6\output.bin
Comodo doesn’t see the redirection hint and tries to open \Device\HarddiskVolume6\output.bin directly, but thinks that the path is a normal file rooted on the C drive… and cannot find it… thus it cannot cause the sharing violation.

When I unmount the mechanical drive, assign it a drive letter and reboot, Comodo then causes the sharing violation as I expected.

[attachment deleted by admin]

#6

Thank you for providing so much detail. I really appreciate it.

Is there a particular program which I should recommend that the devs use to replicate this issue?

Thanks again.

#7

My tester program is attached on the first post. (I updated it slightly to be less forgiving)

I made the program to mimic what my real-world program did and it ran into the same problem.

The test logic is to:

[ol]- Create/overwrite a file (Read+Write access, No Sharing)

  • Write 16KB to it
  • Flush and Close the file
  • Sleep 0-3ms or not at all
  • Immediately re-open the file (Read+Write access, No Sharing)
  • Read a byte from the file (which is buffered as a 4KB read)[/ol]

Step 5 is where the exception can occur… usually when the Sleep does not occur. The No Sharing flag conflicts with the fact that cmdagent.exe has the file open with Read access.

The program that originally found this issue is very esoteric and is commercial software… so I can’t really recommend that. Not to mention it is hard to test with as it is not immediately apparent that the problem occurred.

#8

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Many thanks again.

#9

As this was not fixed during the Beta testing period I will move this bug report to the main Bug Reporting Board.

Please check and see if this is fixed with the newest version (7.0.313494.4115)? Please let us know whether it is fixed or you are still experiencing the problem.

Thank you.

PM sent.

#10

It still occurs with Win8.1x64 and Win7x64.

The beta/RC1 installer gave me version 7.0.312140.4101, so I can’t test with the version you specified.

#11

Same here on windows 8.1 x 64.
With game World of Tanks.
Final version of CIS. Viruscope is On.

#12

Thanks for checking this. I have updated the tracker.

#13

hope i’m not necroing this, but if you’re still in need of a good testing application for this issue, i had tons of access denied errors whenever i closed foobar2000.
whenever it tried to write it’s current playlist and config to disk, it threw me an error. sometimes dozens, until it finally succeeded after lots of retries.

firefox also had a lot of trouble writing config files, especially of addons, but it will do so silently.

#14

no edit button? forgot to add something:

i’ve tried process monitor to find the issue and whenever it was running, the problem magically went away…
took me a while to identify comodo as the culprit, and even longer that it’s viruscope.
it was a friend who tried different settings about week after i actually uninstalled comodo, and found that one.

#15

Thank you. I have mentioned in the tracker that if the devs require more information they may contact you. I hope that’s okay.

#16

that’s fine.
i don’t have a technical insight as deep as the thread starter, but i would happily share any info i got.
contact by email would be preferred though, as i’m not really a frequent visitor here.

#17

If you have your profile set up to alert you in case you receive a Personal Message then you would receive an email alert anyway.

Thanks.

#18

Hi jljtgr,

Devs have marked this issue as “Fixed”. Please verify.

Thanks.

#19

The problem still persists using my OP-attached (#4) tester program using CFW v7.0.317799.4142.

[attachment deleted by admin]

#20

Please try the beta build in order to verify it.

Thank you.