Question

I'm pretty sure that sandboxed drivers that dont exist on the real system can't load. They are allowed to if only if you enable that option in the lowlevel access options in sandboxie's menu.


Now to make the setup more practical yet effective, one could block access to each directory present in the User folder on say Vista/7 yet keep the desktop accessible. Would allowing wrote access to the desktop give a chance for anything to install? I wouldnt think so since the appdata folder is probably the only main folder that could be used to install anything under the user directory.

Rico wrote:I'm pretty sure that sandboxed drivers that dont exist on the real system can't load. They are allowed to if only if you enable that option in the lowlevel access options in sandboxie's menu.

Yes, that sounds correct.

Rico wrote:Now to make the setup more practical yet effective, one could block access to each directory present in the User folder on say Vista/7 yet keep the desktop accessible. Would allowing wrote access to the desktop give a chance for anything to install? I wouldnt think so since the appdata folder is probably the only main folder that could be used to install anything under the user directory.

Wouldn't allowing write access "anywhere" allow something to potentially execute/run? By the way, for argument's sake, what about malware which only exists in memory? This is why a good "approach" is also necessary to make full use of Sandboxie (eg. reserve a separate web browser for banking and delete contents after each session).

The thing here though is even if it does run, where can it go? It cant write anywhere else but that folder, hence cant really install anything. Also most exploits tend to allow stealth downloads to a browser's cache.

Considering that I know what I am downloading is trusted, that should be a non issue. As then I would explicitly allow it to download to my desktop.

Rico wrote:The thing here though is even if it does run, where can it go?

I don't think it needs to "go" anywhere to cause problems. For example, some malware only needs the executable file to run and doesn't require to be "installed" anywhere. Classic examples are scare-ware and ransom-ware.

Rico wrote:Also most exploits tend to allow stealth downloads to a browser's cache.

I think you're right, but then most (all?) exploits' payloads would be stopped dead with Sandboxie's start/run restrictions.

Rico wrote:Considering that I know what I am downloading is trusted, that should be a non issue. As then I would explicitly allow it to download to my desktop.

This is what I do all the time - recover specific files on to my REAL desktop (in a "Downloads" folder).

Memory only malware, how common is that? it seems that there s always some little Achilles heel somewehere...

Well, if its as rare as kernel mode vulnerabilities that can bypass all security software I think I should be good. The real problem is that Windows wasnt designed with security in mind.

I think whats great about Sandboxie is the number of roadblocks and restrictions it hurls against conventional malware. I think getting the most out of the program depends on how much you can really lockdown.

Sandboxie certainly has a steep learning curve if you want to dig deep!

ssj100 wrote:If someone has an example of in-the-wild malware which only operates via a .DLL file, please PM me the sample.

Don't know if Stuxnet counts?

While testing with the read only access IE 8 works fine. Chrome blurts out an alert that things might not function as expected, nonetheless everything works well. There is one thing I dont understand though; in principle browsers need to download a page to be able to display it right? Or can it render content without downloading it?

I also noticed the Registry Read only setting, how would I configure the whole registry to be read only? I know its not that necessary but since I came this far I might as well do this.

Yes, that's certainly what I observed in my testing too - IE seems to work fine. However, Firefox doesn't.

I think the browser does still "download" and render a web-site. It doesn't need to specifically download and write new files on the system to do this.

I don't think it's possible to configure the whole registry to be read only.

ssj100 wrote:p2u, could you guide me on how to test DLL loading? I'll obviously need a DLL file to start. Thanks.

Hm... Compiling, programming, debugging? I think you'd better find or ask ready examples, no? Rmus must have something left, I think. Dll's can be readily downloaded from online resources, but if you have "copy"-protection on in AE2, the download will be blocked. How about the Firehole leaktest by Robin Keir? It's harmless and it's a nice place to start. It creates a dll on the fly: http://keir.net/firehole.html
Read the explanation to see what it does. The download link is in the middle of the page.

Paul

Regarding the location of the registry: http://help.lockergnome.com/windows2/file-located--ftopict484827.html

It seems that they are a number of 'files' located throughout the C drive which mean that they are already set to readonly with the settings you have devised. If any of what I'm saying is wrong please feel free to correct me.

p2u wrote: Dll's can be readily downloaded from online resources, but if you have "copy"- protection on in AE2, the download will be blocked.

Paul, are the C:/ read only settings that are discussed here act in the same way? Do they provide copy protection too?

ssj100 wrote:what about malware which only exists in memory?

Is there memory only malware with no executable or file involved or did I misunderstand?

Rico wrote:Paul, are the C:/ read only settings that are discussed here act in the same way? Do they provide copy protection too?

Let me say first that "C:/ read only" doesn't seem workable to me.
P.S.: For Firefox it's enough to set it to start always in Private Mode.

Code:

browser.privatebrowsing.autostart = true

Nothing will be written to disk unless you specifically download something. When exiting Firefox, everything from memory cache is safely deleted.

The copy protection in AE2 has nothing to do with user (or program) access rights. AE2 determines that you want to download (= copy) an executable file from the Internet and will block that download.
P.S.: I believe this protection was also removed from AE3.

Paul

p2u wrote:Let me say first that "C:/ read only" doesn't seem workable to me.

It's fine when specified to IE's virtual environment only (and apparently Chrome's?), and is a viable method of locking down the environment further (eg. for internet banking purposes). This is the flexibility of application virtualisation (Sandboxie in particular).

As I mentioned in the Sandboxie configuration thread, making C:\ read only will prevent all newly introduced file types from being downloaded/executed (written to disk). I think AE2 only prevents .EXE and .DLL types.

Rico wrote:Is there memory only malware with no executable or file involved or did I misunderstand?

I was meaning malware which doesn't need to write to disk to perform malicious actions (eg. clip-board logging). Therefore, they execute and perform their actions only in memory. I'm not aware of such malware in-the-wild.

p2u wrote:Let me say first that "C:/ read only" doesn't seem workable to me.
P.S.: For Firefox it's enough to set it to start always in Private Mode.

I don't think this can prevent a driveby as a malicious site exploits vulnerabilities to be able to download anything without consent. In a perfect world, one would think that if they didn't explicitly permit the download of an executable it wouldn't be there. This however would be a vastly superior safety net that can't be beat.

@ ssj, so basically its not virus types that infest/ install on the PC? Clipboard logging shouldnt be an issue if you deisgnate a sandbox for unsafe vs safe browsing.

Rico wrote:@ ssj, so basically its not virus types that infest/ install on the PC? Clipboard logging shouldnt be an issue if you deisgnate a sandbox for unsafe vs safe browsing.

Yes, I would suppose so. And yes, a good security approach with Sandboxie is also necessary to realise its potential.