A. THE BUG/ISSUE (Varies from issue to issue)
[ol]- Summary - Give a clear summary in the topic subject, NOT here.
Can U reproduce the problem & if so how reliably?: Yes, always.
If U can, exact steps to reproduce. If not, exactly what U did & what happened: Simply try the Spyshelter test at various restriction levels (all levels of BB’s automatic plus manual sandboxing via CIS interface/context menu) and observe the terrible results. There are attached screenshots of all tests. Results:
[li]Partially Limited - Total Failure (perhaps expected)
Limited - 100% Blocked
Restricted - 100% Blocked
Untrusted - Failed 3 out of 11
Fully Virtualized - Total Failure
[/li]- If not obvious, what U expected to happen: Obvious, I expected all levels above Limited to successfully block the screen capture attempts.
If a software compatibility problem have U tried the conflict FAQ?: Can’t see how this could be a compatibility program, even more considering the number of people that have reported the same bug since circa 2010 (earliest reports of this bug I’ve seen).
Any software except CIS/OS involved? If so - name, & exact version: I think not.
Any other information, eg your guess at the cause, how U tried to fix it etc: In the KS cvs process dump ignore the presence of Baidu PC Faster as the tests were done before its installation (and were the same after installation). The results are also not influenced by HIPS being on or off.
Always attach - Diagnostics file, Watch Activity process list, dump if freeze/crash. (If complex - CIS logs & config, screenshots, video, zipped program - not m’ware)
[/ol]
B. YOUR SETUP (Likely the same for each issue, so you can copy forward)
[ol]- Exact CIS version & configuration: 6.1.276867.2813, Proactive
Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV: BB, HIPS (see A.7), FW and AV
Have U made any other changes to the default config? (egs here.): Yes, but the results were the same using default Proactive.
Have U updated (without uninstall) from a CIS 5?: No.
[li]if so, have U tried a a clean reinstall - if not please do?: Yes, to no avail.
[/li]- Have U imported a config from a previous version of CIS: No.
[li]if so, have U tried a standard config - if not please do: Yes, even tried importing it directly from the installation folder before the clean reinstall.
[/li]- OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used: Win 7, SP1, 64-bit, UAC off, admin account, no VM
Other security/s’box software a) currently installed b) installed since OS: no
[/ol]
I believe you are referring to the discussion which takes place in this topic. Is this correct?
If so then I believe the true bug is that Restricted is able to block the screen capture while Untrusted is not. Therefore, there must have been a mistake made in the permissions given to programs running under Untrusted, as Untrusted is supposed to be able to block just as much as Restricted, and then more.
If you confirm that this is the bug you are reporting I would suggest changing the name of this bug report to something similar to “Restricted is able to block screen capture but Untrusted cannot”. Does that work for you?
The issue is that it may not a bug that levels above limited do not block screen capture, as I don’t believe blocking screen capture is currently one of the primary goals. However, anything blocked by Restricted should also be blocked by Untrusted. Thus, in order for this to be fixed I believe we should narrow down on the main bug, which is with the permission difference between Restricted and Untrusted.
In addition, please also attach the diagnostic report and the KillSwitch process dump to your first post.
Ok, I’ll see about the diagnostics & process dump—I should have remembered it initially. But the title remains. Just look at the screenshots. I’m sorry I haven’t written down everything in the report, I just wanted to finish it quick as I was in a hurry yesterday, but if you look at the screenshots you’ll see that indeed various levels fail.
Partially Limited - Total Failure (perhaps expected)
Limited - 100% Blocked
Restricted - 100% Blocked
Untrusted - Failed 3 out of 11
Fully Virtualized - Total Failure
So the leak is with Untrusted and Fully Virtualized (I don’t know if Partially Limited counts). I could change the title to include both, but I’ll have to adjust to make them fit, I’ll try.
Thank you for clarifying that for me. Can you please also add that summary into your first post?
Seeing those results I believe that there is definitely a bug with Untrusted. It should be blocking anything Restricted or Limited can block. With FV I’m not 100% sure what the intended behavior is. I’ll check this and get back to you.
Okay, I will forward this to the devs. However, as it’s possible that there are actually two separate bugs at play here, one for Untrusted and the other for FV, I would greatly appreciate it if you could create a separate bug report for the FV vulnerability.
For the time being however, I will forward this one as specific to Untrusted.
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.
Chiron, I already sent you a personal message, but I think my answer should be posted here also. Quoting myself:
Hi Chiron!
I understand your concern, but on my way to making a separate report for the FV, I realised the information is all there already. My report already deals with FV as with other restriction levels. While I also don’t want to see anything overlooked, I think I’ve provided the devs with enough information to investigate and therefore fix the problems. If they fix the BB levels but not FV, the report cannot even be considered as solved. So for now I think I’ll just wait.
If it is one bug that affects many restriction levels, or many separate bugs, this is not of my concern. I will not be the one doing the investigation nor the fixing. If you could forward or re-label my report as pertaining to the sandbox (a general sandbox/isolation issue) then the devs can analyse the bug and determine its details better than I could. On our end if cannot be much more than guesswork anyway.
Can you please check and see if this is fixed with the newest version (6.2.282872.2847)? Please let us know whether it is fixed or you are still experiencing the problem.
Thanks Chiron.
Maybe you could update your “guide to CIS installation” suggesting people to set BB as Restricted for now and explaining why. Actually this is quite abig bug, because people can think they are fully protected while they are not (or at least, the grade of protection doen’t follow the BB setting list)
Untrusted is still more secure. The only parts of it which seem affected by this are vulnerabilities which you are still protected from unless you allow a Firewall alert. However, Restricted is still vulnerable to other techniques which can be used to trick a user into performing an action they did not mean to do.
Thus, at least for me, Untrusted is still the superior setting.
Can you please check and see if this is fixed with the newest version (6.3.294583.2937)? Please let us know whether it is fixed or you are still experiencing the problem.
Can you please check and see if this is fixed with the newest version (7.0.313494.4115)? Please respond to this topic letting us know whether it is fixed or if you are still experiencing the problem.
