I mean that after restart the folder is still there with all of it’s contents intact. “Reset sandbox” works as it should though.
I don’t understand why I need to add anything to protected files. the bat file was detected as unrecognized, yet it was able to do stuff in vtroot folder, untill i set BB level to restricted. I never made it trusted.
I bet any of you can repeat this experiment. Just create a bat file, place it anywhere, guide it to c:\vtroot and tell it to do stuff there. File will be unrecornized but will do whatever you typed there.
If the bat file is sandboxed then of course it can change the files in the VTRoot, these are the files that sandboxed applications are supposed to be able to change, if the applications can’t change any files on any hard-drive then they simply can’t run or work, they need a central point to save on the hard-drive and with CIS they have a common folder for all sandboxed applications.
Also, try making the bat file deleting another file on your system that is not in the VTRoot folder, if the bat file is sandboxed it should fail.
When I have add Comodo Dragon to auto-sandbox (Fully Virtualized) it also runs with all the extensions and saves the bookmarks, however when I restart my computer and start Comodo Dragon it starts as it was just installed, no bookmarks, default homepage, no extensions. Is this expected behavior?
Oh, OK. I don’t know. I haven’t tested the fully-virtualized auto-sandbox.
I do suspect however, that based on the previous auto-sandbox behavior, (harmful processes are gone upon restart) that if this is not intended behavior, it is at the very least a side-effect of the intended behavior.
I would suggest that it’s a better idea to run your browser in the manual sandbox, rather than the automatic sandbox.
Yes, the batch file is run from real system, file is isolated by Behaviour Blocker (previously known as auto-sandbox), but it is still able to perform actions in vtroot folder (program from “outside” being able to mess with files inside vtroot folder, which is basically sandbox and should be isolated from the real system), unless BB is set to Restricted or higher. As far as I understand BB does not virtualize (sandbox) unknown files (unless set to fully virtualize), but just takes some rights from them.
So the question is, should unrecognized file be able to perform actions within vtroot folder, when default BB setting (Partially limited) is used?
Let me answer that with a question. What malware would try to voluntarily get into the sandbox? I have never heard of one. Usually a malware would like to get out of it.
umm… what if malware from the outside tries to start malware from inside vtroot folder? “Outside” malware will be isolated as partialy unknown, but will it prevent it from starting something from vtroot folder (or it’s subfolders)? It’s pretty unlikely scenerio, I understand but someone might try it…I guess?
Now we are into more general vulnerability questions, specifically that relating to inter-program comms. Chiron’s thread addresses that.
To answer Eric’s question - which I think is exactly the right one - I think your exploit is only likely to be a problem where the sandbox is being used to permanently store important information. (Then if malware gets in it could cause damage). This is not a traditional sandbox application - traditionally sandboxes are viewed as disposable.
But Comodo is maybe stretching that with the notion of a banking Kiosk. You might store passwords in it I suppose using something like Keypass. You might setup your browser in a very specific way. You might find it convenient to install your personal finance app there too to make transfer easy.
But equally maybe that’s not what Comodo intends you to do?
