Sandboxed CLT fails?

[Guest]

[i4u1]

Sandboxed clt doesn't give final results. Because of so called "virtualization" CLT cannot give/create htm with results and feed it to browser as a final scores.
Confirm?

Also try this: sandboxing enabled but allow CLT to run not sandboxed and voila 30/340. So why not sandboxed CLT behaves differently as sandboxing completely disabled?

[EricJH]

The CLT program was accidentally added to the trusted list (whitelist in the Cloud) in the past 24 hours.
CLT will be removed from the whitelist with the next antivirus update.

So, update the antivirus, then follow the instructions here, and see how CLT works.

[i4u1]

the matter of fact that i don't use antivirus - only HIPS & firewall. And how do i supposed to update smth.?)

So Q answered: must cis with D+ work w/ and w/o sandboxing enabled similarly when run some app not sandboxed (choose to allow to run it not sandboxed even if app not dig.signed and untrusted) ?

And i still get 30/340 with CLT not sandboxed but with sandboxing enabled. Is this right and correct behavior? So if not being sandboxe app gets "trusted" "installer" automatically? W/o runtime/HIPS protection as disabled sandboxing allow.

[Whoop-dee-doo]

...
And i still get 30/340 with CLT not sandboxed but with sandboxing enabled. Is this right and correct behavior? So if not being sandboxe app gets "trusted" "installer" automatically? W/o runtime/HIPS protection as disabled sandboxing allow.

Follow the instructions in this post (the post lists the appropriate method to make sure your CLT results are accurate. If you still get a low score, please post the information that is requested.)

[i4u1]

Follow my instructions to run CLT and post your results here.
Why should i disable sandbox to get 340? Or why i should run it sandboxed if i don't want it to?

Run as stated and post your results here to answer my Qs.

[Whoop-dee-doo]

I have updated this post (the post lists the appropriate method to make sure your CLT results are accurate.). Most notable change was

...[snip]...

Note: there are specific circumstances when CLT reports very low scores. The moderators and developers are investigating these specific circumstances and hope to have more info soon. Based on current feedback from the developers, CLT can give erroneous and unreliable results when testing CIS in any configuration that is different from the one described below (it is a limitation within CLT). The reasons why CLT may give unreliable results when using other CIS configurations will be the topic of another FAQ post (as soon as we get more feedback from the developers).

...[snip]...

i4u1,
CLT will not provide reliable scoring in the configuration you have described. Try CLT with configuration the is suggested in the link above (now it suggested to test with sandbox disabled).

Also, CLT was reported as AV false positive and we are waiting for it to be de-listed.

[i4u1]

Whoop-dee-doo, i know the reason CLT behave oddly - sandboxing.
It's broken cuz sandboxed HIPS doesn't work for virtualizes files/registry - as obvious explanation, however "virtualized" files and registry somehow protect the real ones even however stated as vulnerable in CLT.

And sandboxing even broken in that way it virtualizes differently when dbl-click vs. "Run sandboxed" in shell or main window ways. Anyone can try these ways and check \VirtualRoot\ folder to see the difference.

So the right decision will be to fix/restore HIPS for any sandboxed app. and virtualized files/registry. As stated HIPS broken even when apps ran not sandboxed with sandboxing enabled - however not a single virtual file/registry should be involved in this case.

[Whoop-dee-doo]

Whoop-dee-doo, i know the reason CLT behave oddly - sandboxing.
It's broken cuz sandboxed HIPS doesn't work for virtualizes files/registry - as obvious explanation, ....

We'll have to wait for more feedback from the developers. Apparently, it is much more complex than the explanations proposed by users and mods (and since we do not know the exact details of how CLT and CIS  interact, we have to wait for the developers to provide more information). Currently, it appears that the CLT findings do not represent a bug in CIS, but rather a limitation in CLT. But, as I said, we have to wait for more feedback from the developers regarding issues such as:
1) Does a bug exist, and if so, is it in CIS or CLT.
2) Do default CIS and sandbox settings need to be changed.
3) Does CLT have to be updated to so that it can provide more accurate testing under any configuration.

[i4u1]

The explanations are quite simple re-read them above. CLT has no interaction to CIS:) only FS and registry and some OS and OS managers regarding IE and driver installation.
Since all this is virtualized and not happen on real machine (as sandbox suppose to do) it all allowed and CLT runs smoothly nicely modifying virtual registry and files.

CLT works fine and show results according to virtualized permissions for apps if ran sandboxed as "Run sandboxed" via shell not by dbl-click. And fairly says 200/340 or around. Since i convinced HIPS don't catch virtualized operations as they are supposed safe for real machine/files/registry and thus CLT show failures like they were real on real system.

Send developers here - I explain them how it works and how to avoid this pitfalls in CIS using proper system design and coding techniques. hehe

CLT should not be blamed it only shows the real state of real or virtualized protection not the ability of HIPS to virtualize smth. even if it's made ugly when GEtModuleFilename returns not virtualized path and not relative path to virtualized files and not check both directories virt. and actual for newly created and existing files for redirection of R+W+O operations on FS and objects = That's why CLT fails to render final results in html (obviously virtualized to \VirtRoot\) to browser.

[i4u1]

But the question why Sandboxing in automatic and manual mode behave different still remains.

[Ronny]

But the question why Sandboxing in automatic and manual mode behave different still remains.

Automatic "sandboxing" or Isolation is only there to prevent "unknowns" to be able to infest the system, it doesn't use visualization to prevent malware from being able to exist after reboot.

If you manually run an app sandboxed it's deliberate sandboxing by the user not by "unknown malware" and thus CIS will give you the opportunity to set sandbox parameters as you like.

[i4u1]

Actually i don't get your answer. I can't find official description of these "2 differen sandboxing modes".
Where to read about these different Sandbox modes/features? Why FAQ lack of it? And why it's not specifically stated that sandboxing only works when used manually? Or what exactly happen when automatic sandboxing used. Which of selected options are really working when automatically used? And why options are treated only for manual usage and discarded upon automatic?
Where's the information about these differences and why people counting on sandboxing can't get it fully working on automatic basis or at better different settings for manual/auto mode?

Anyway it's a big mismatch when one button states the same sandboxing mode and behave differently indeed - it's a silent but and not expected behavior by users.

[EricJH]

Ronny is correct when he describes the two sandbox modes: automatically sandboxed and manually sandboxed.

To learn about the automatic sandboxing process read Unknown Files: The Sand-boxing and Scanning Processes.

To learn about the manual sandboxing process follow the links at the bottom of Unknown Files: The Sand-boxing and Scanning Processes.

Notice that the user interface emphasises the manual sandboxing options

[i4u1]

According to this
"If the user enables virtualization, then sandboxed apps. can't modify registry keys or modify existing protected files either"
I should expect the same behavior for automatic and manual sandboxing then VirtualRoot should reflect the same when run CLT with manual sandboxing and run it with automatic. See the difference.
Sanbox tab options in settings of D+ should affect manual sandboxing only cuz for Always sandbox there's separate settings of virtualization etc. So why the heck manual not equal to automatic wen on defaults - with file/registry virtualization enabled? Why VirtualRoot is empty in one case and not in other?

And why 1st post still unanswered? - CLT when run with S/B disabled not equal to CLT run not sandboxed via Allow near sandbox button with S/B enabled?

The D+ main menus/tabs should state and reflect clearly automatic process and some implied to some way of type or run applications via shell 'Run as sandboxed' or other internal buttons to run apps with some set of already checked options of type of virtualization.

Why are they different to CLT - not signed not trusted, unrecognized app?

Show me the exact lines of help where stated that automatic sandboxing behave differently and cannot be changed or irrelevant to those settings on Sndboxing tab... otherwise CIS 5.0 has a bug with sandboxing processing and HIPS in case of skipping sandboxing stage to Run stage of app.

Have you both tryed CLT in a manner of stress testing with all types of settings and clearing white/black local lists and observing the results - virtualized registry and FS and comparing results to each other in a way i did to FS and explained here? I wish documentation would reflect the actual way of things happen...
OR better actual thing will happen according to documentation and settings made by users. Deliberately in D+ tab not in some subsubsub menu for virtualization of FS and reg.


And even if CLT virtualized properly via "Run" shell or D+ menu tab, CLT fails some HIPS test cuz virtualised spawn processes have the same access to the same files but virtualised, the same access to system resources, networking etc. HIPS just not working when virtualization does. That's why some of failed tests (190/340) are failed by HIPS+Sandbox cooperation fail (speaking about spawn IE process and its failed tests).
Even being fairly sandboxed CLT can interact bypassing HIPS to real applications - result log sent directly to browser w/o permissions - like one failed test on interaction w/ browser.

[salaficall]

According to this
"If the user enables virtualization, then sandboxed apps. can't modify registry keys or modify existing protected files either"
I should expect the same behavior for automatic and manual sandboxing then VirtualRoot should reflect the same when run CLT with manual sandboxing and run it with automatic. See the difference.
Sanbox tab options in settings of D+ should affect manual sandboxing only cuz for Always sandbox there's separate settings of virtualization etc. So why the heck manual not equal to automatic wen on defaults - with file/registry virtualization enabled? Why VirtualRoot is empty in one case and not in other?

And why 1st post still unanswered? - CLT when run with S/B disabled not equal to CLT run not sandboxed via Allow near sandbox button with S/B enabled?

The D+ main menus/tabs should state and reflect clearly automatic process and some implied to some way of type or run applications via shell 'Run as sandboxed' or other internal buttons to run apps with some set of already checked options of type of virtualization.

Why are they different to CLT - not signed not trusted, unrecognized app?

Show me the exact lines of help where stated that automatic sandboxing behave differently and cannot be changed or irrelevant to those settings on Sndboxing tab... otherwise CIS 5.0 has a bug with sandboxing processing and HIPS in case of skipping sandboxing stage to Run stage of app.

Have you both tryed CLT in a manner of stress testing with all types of settings and clearing white/black local lists and observing the results - virtualized registry and FS and comparing results to each other in a way i did to FS and explained here? I wish documentation would reflect the actual way of things happen...
OR better actual thing will happen according to documentation and settings made by users. Deliberately in D+ tab not in some subsubsub menu for virtualization of FS and reg.


And even if CLT virtualized properly via "Run" shell or D+ menu tab, CLT fails some HIPS test cuz virtualised spawn processes have the same access to the same files but virtualised, the same access to system resources, networking etc. HIPS just not working when virtualization does. That's why some of failed tests (190/340) are failed by HIPS+Sandbox cooperation fail (speaking about spawn IE process and its failed tests).
Even being fairly sandboxed CLT can interact bypassing HIPS to real applications - result log sent directly to browser w/o permissions - like one failed test on interaction w/ browser.

+1

I hope to get some explanations from the developers on this issue

[Tags:]