Ok so I made a .bat file to delete a text file for testing and I run the .bat file and it deleted the text file the sandbox pops up and says it was isolated and blocked and gives me options to keep it sandboxed or not, so i chose keep sandboxed but the file was able to do the damage so really the sandbox did not isolate the bug I ran this test on a few machines and made more files and they all let it do the damage can u please check this out because thats a major flaw
As far as i know it’s only “protecting” files that are on the “My protected Files” groups.
Where was the file located your batch file deleted?
sorry for the double post , the file i deleted was in c:\test.txt , i ran the batch file from the desktop and also from inside the c:\ directory
Well, that doesn’t make sense.It’s like:''my AV protects just the files in ‘‘my protected files’’ list ‘’
The files in ‘‘My protected files’’ section are really protected by not allowing to anyone or anything to change them, without permission.This is completely different thing.
Snip from the CIS HELP file (The Sandbox)
If a safe or installer application is executed by an application running inside the sandbox, the installer will also run in the sandbox no matter what
If a user defines an application for sandboxing, this will cause any applications (safe or installer) to also be executed inside the sandbox.
In addition to the sandbox restriction level set for an application, defense + also implements the following restrictions. A sandboxed application cannot:
Access non-sandboxed applications in memory
Access protected COM interfaces
Key log or screen capture
Set windows hooks
Modify protected registry keys (if virtualization is disabled)
Modify EXISTING protected file (if virtualization is disabled).
So in this case i think you have to put the test.txt file in c:\windows\system32 and see if you can still delete it…
Sorry can’t help it, that’s the current implementation of the Sandbox apparently from what i understood and figured out…
yes exactly i was shocked when i tested it , and i was able to delete .exe files mp3 files any file really even after fully updating everything to latest version so reallly hope they fix this , I was giving a demo of it in a live webinar and 40 people saw it not work and i was like omg lol there like so much for that I told them i would let u guys know , when i use that sandboxie program it works like a charm but this sandbox I even set it to run in the sandbox and tried all the different options like restricted or limited or unrestricted and every option let it go right through and delete the target file >:-D thanks keep me posted
well I decided to just turn off the sandbox and let defense plus ask for permision that works but if they change the sandbox so that it will work more like sandboxie and really trap things I’d love to use it thanks for the support
That sounds suspicious, the .exe extension is on “My Protected Files” that would suggest you should not be able to delete existing .exe files.
You just used a simple batch file to delete random .exe files?
An other note, please be careful with comparing CIS sandbox with SandboxIE although the names look alike their intention/design/functionality is different.
Please read this post for more details Introduction to the Sandbox
yea just made a simple batch file to delete .exe .mp3 .txt it worked on anything i tried , and on multiple machines too, with everything fully updated, using windows xp , try it out
open notepad put in del c:\test.txt
make test.txt put it in the c:\ directory
and launch the batch file the test.txt will disapear and then comodo pops up saying it has isolated the file wich is bogus lol
forgot to add after u create the notepad file , rename it to .bat to turn it into a batch file
You still haven’t answered Ronny’s question what happens when you put some .mp3 and .txt files in windows\system32\ folder (that’s a protected folder).
I ran it and it worked it deleted the test.txt file right in the system32 folder , and then after the file deleted comodo popped up saying it was isolated and if i wanted to keep it in the box lol
Removed all bold
oh no i just realized one more thing ! , if u run the .bat file inside cmd , so if u open up CMD and type in c:\bug.bat or the name of the file u make , then it will run and defense plus doenst even stop it or ask u for permision , I know in the past years ago people would get to a level where they could access ur folders and ur cmd by exploit , so then they would upload there .bat file then use CMD and execute the .bat file , and they would have the .bat file kill special things on ur pc like anti virus or such , then they would proceed to upload a real bug and execute that to open a backdoor on the system so kinda scary I guess if one program opens a hole the rest can easily be wiped out unless they can change this to detect the execution from CMD ???
Removed all bold
Looks like a bug from my understanding of the sandbox.
Re the design of the sandbox, this makes more sense when you understand that with virtualisation switched on (which I think it will be for auto-sandboxing, when virtualisation is stable) all files are protected, as the sandboxed file writes to its own private copy of any file it wants to write to.
That’s the theory anyway. See the virtualisation mini FAQ here for details.
I figured out what’s causing this in version 4.0.x.779 as stated before in this post the .bat or .cmd files spawn the process to cmd.exe
While the user created .bat/.cmd is “sandboxed” the actions done by cmd.exe are “trusted” because it’s a M$ file.
I could prevent this behavior by putting c:\windows\system32\cmd.exe manually in the sandbox with limited permissions AND file system virtualization active.
Looks like a point of improvement for the Sandbox…
But, unless I have misunderstood, the sandboxed batch file is calling cmd.exe to execute it’s commands, so in theory, though cmd.exe is not normally sandboxed, the cmd.exe instance that is run to execute the commands should be sandboxed.
If not there must be an intended exception to this rule for windows system files, or for trusted vendor’s files, which we don’t know about. Or it’s unintended.
Bug or design issue…???
It does note that cmd.exe got started sandboxed limited, but only File Virtualization will prevent this, and that’s not enabled on “auto sandbox” thus not preventing this.
To rule out the cmd.exe stuff here I wrote a PoC in C# and I can delete a file C:\Windows\System32\test.txt without problem, if the application is Auto Sandboxed.
If i put the PoC on Manual Sandboxing (Same as Auto but with File/Reg visualization) it creates a C:\Vritualroot\PoC\HarddiskVolume1\Windows\System32\test.txt.del file. And the original file is still there.
So deleting files on the “My Protected Files” is currently not covered on Auto sandboxed “applications”.
Well found Ronny & Boosty
Not good - an urgent bug for Egemen then, I guess?