DefenseWall pitfalls

There's one particular issue with DefenseWall that I keep referencing to from time to time, in this forum, and across other forums. It is not an easy thing to describe and it also applies to three other (conceptually similar) programs - GeSWall, Sandboxie and BufferZone. Because of this difficulty, I am making this sticky so that I can reference the issue more easily (instead of having to sift through old posts) in the future:

simmikie wrote:...in fact i feel i have an advantage. my files are resting quietly in their permanent homes while still being isolated from from harming the system. i do not have to make a determination of what stays sandboxed and what gets released. i don't have 30 sandboxes containing various file types or programs. i can change my music, image, video etc files at my leisure or not at all for infinitum.

This is where I have to disagree. How do you know for sure that every single file will open untrusted? How are you opening your files (which are apparently labelled "Untrusted" by DefenseWall)? If you are simply double clicking them, then you do NOT guarantee that they open untrusted. To guarantee that they open untrusted, you have to manually right click and go through the DefenseWall context menu to specifically run it "Untrusted". This can become extremely inconvenient if you are wanting to browse through eg. 100 picture files. With Sandboxie, I use this method (note I describe the issue about files not opening sandboxed despite it being inside a "forced sandboxed folder". The same issue occurs with DefenseWall and GeSWall for respective "Untrusted" and "Isolated" files):
https://ssj100.forumotion.com/sandboxie-f1/newbie-sandbox-setup-help-t88.htm#488

I first discovered this issue with Sandboxie and picture files (and some video file types) some time in 2009 and later confirmed that DefenseWall, GeSWall and BufferZone all had the same pitfall. tzuk admitted that nothing directly could be done about this from the Sandboxie (and therefore DefenseWall/GeSWall/BufferZone) point of view. It took me some hours of experimenting but I eventually figured out the workaround for this with Sandboxie - I've described it in the above link. As far as I can tell, no such thing can be accomplished for DefenseWall, GeSWall and BufferZone. Since I was already inclined towards using Sandboxie (for its life-time license with updates, 64-bit compatibility, configurability, anti-execution properties, ease in wiping "frozen malware" etc), this simply confirmed that Sandboxie was the best program for an "above average" user like myself.

Of course, there is an indirect workaround for this issue - use a third party picture viewer program and force that picture viewer program to always run sandboxed/untrusted/isolated. However, there's no certainty that this issue involves just picture files and "Windows Picture and Fax Viewer" (or the equivalent in Windows Vista/7). Because of this, there is no "guarantee" that every file you download will open sandboxed/untrusted/isolated. In DefenseWall's case, even if you checked that the file is "Untrusted", it could theoretically still open "Trusted" if you opened it by double clicking on it (as most people routinely do when they eg. download files from their web browser). The only method to "guarantee" that it opens "Untrusted" is to "Right Click" the file and manually select to "Run as untrusted" via the DefenseWall context menu as shown below:


However (and unfortunately), for DefenseWall, even running a folder as untrusted via this context menu method doesn't "guarantee" that everything from that folder opens "Untrusted". The reason is because "explorer.exe" cannot be run "Untrusted", and you are essentially using "explorer.exe" to browse folders. On the other hand, with Sandboxie, you are able to run "explorer.exe" sandboxed via the context menu (and I've described how to take advantage of this so it is convenient to do so). By running "explorer.exe" sandboxed, you "guarantee" that everything you open through this will also open sandboxed. This cannot be achieved by DefenseWall (and GeSWall, BufferZone). And worse still, with BufferZone, it's not (yet) possible to eg. open picture files virtualised if Windows Picture Viewer is your default image viewer program.

To demonstrate further doubtful behaviour with DefenseWall, try the following:
1. Open your web browser "Untrusted"
2. Download a .txt file (which would open with Notepad by default) on to your desktop or into your Downloads folder
3. Check that this file is labelled "Untrusted" by DefenseWall (it should be)
4. Now double click the file and watch it open "Trusted"
5. The workaround for this is to specifically add the Notepad program into the "Untrusted Applications" list. However, this should make you think...what else needs to be added into this list in order for ALL files to open "Untrusted" via routinely double clicking on it?

To conclude, I feel that DefenseWall (and GeSWall, BufferZone) gives a false sense of security from the security purist's point of view - newly introduced files (from the web browser, foreign USB drives etc) may open "Trusted"/"Unisolated" despite having the label of being "Untrusted"/"Isolated". And unfortunately for these three programs, there isn't any convenient method to workaround this in order to "guarantee" that everything opens "Untrusted"/"Isolated".

EDIT: here's a youtube video I created demonstrating the pitfalls:
https://ssj100.forumotion.com/t309-defensewall-pitfalls#2497

Another attack vector that DefenseWall and GeSWall (and probably BufferZone) don't protect the user from is related to malware that can execute without having to open the file. Watch the video of a POC demonstration here:
http://blog.didierstevens.com/2009/03/04/quickpost-jbig2decode-trigger-trio/

Didier Stevens demonstrates this with PDF files, but in theory, ANY file type can have vulnerabilities (even image files) - for example, recall the wmf vulnerability:
http://en.wikipedia.org/wiki/Windows_Metafile_vulnerability

The specific exploit Didier Stevens demonstrates involves a bug being triggered in the "explorer.exe" process. The reason DefenseWall and GeSWall don't protect the user here is because they cannot contain/isolate the "explorer.exe" process.

So here's a potential scenario where a user running eg. DefenseWall could get owned by malware:
1. User downloads a malicious file via an "Untrusted" web browser.
2. User hovers his/her mouse cursor over the malicious file (not even clicking it).
3. The relevant bug is triggered within the "explorer.exe" process (which is of course "Trusted") and malicious code execution runs outside the protection scope of DefenseWall (effectively runs as "Trusted").
4. System is destroyed.

I think the most cunning malware that could be developed would combine the above attack vector with the one I recently tested:
https://ssj100.forumotion.com/t319-excel-macro-testing#2640
In other words, the malware could be executed without having to open the file (bypassing DefenseWall, GeSWall, etc), and it could be executed within a trusted process (bypassing SRP, AppLocker, Classical HIPS, etc).

Always ready to comfort the young and restless: you don't have to fall victim to this kind of automagic exploits if you don't want to:
1) There are good Shell Extension managers on nirsoft - ShellExView, for example, that allow you to remove/disable unwanted explorer extensions.
2) Installing alternatives that don't display this behavior is also an option. I already mentioned my alternative for opening PDF files. My PDF reader does not install any shell extensions at all.
3) You may find this unexpected, but you can also remove the associations for certain registered file types on your system, and open any media files (images included) with "Open With..." The system just won't know how to open it; it's all up to you...

Paul

p2u wrote:1) There are good Shell Extension managers on nirsoft - ShellExView, for example, that allow you to remove/disable unwanted explorer extensions.

Wouldn't we then want ALL explorer extensions to be disabled? Do you think this is practical?

p2u wrote:2) Installing alternatives that don't display this behavior is also an option. I already mentioned my alternative for opening PDF files. My PDF reader does not install any shell extensions at all.

Are there any other commonly used software that installs shell extensions? If so, what are the alternatives?

p2u wrote:3) You may find this unexpected, but you can also remove the associations for certain registered file types on your system, and open any media files (images included) with "Open With..." The system just won't know how to open it; it's all up to you...

Could you give us a tutorial/example? Perhaps post it in another topic/thread.

ssj100 wrote:Are there any other commonly used software that installs shell extensions? If so, what are the alternatives?

Oh yes. Image viewers and media players tend to do this all the time, and the problem is that there don't seem to be any alternatives. They all do this:
1) for convenvience
2) to increase their user statistics

ssj100 wrote:

p2u wrote:remove the associations for certain registered file types

Could you give us a tutorial/example? Perhaps post it in another topic/thread.

I'm actually preparing this kind of tutorials. Coming up soon...

Paul

p2u wrote:Oh yes. Image viewers and media players tend to do this all the time, and the problem is that there don't seem to be any alternatives.

How about software which do have alternatives? You've already given us one example - PDF readers.

p2u wrote:1) for convenvience

We all have to sacrifice some level of convenience for security. This level varies depending on the user.

p2u wrote:
I'm actually preparing this kind of tutorials. Coming up soon...

Looking forward to it!

ssj100 wrote:How about software which do have alternatives? You've already given us one example - PDF readers.

A good program won't force-install anything unwanted. It will either ask you or assume that you'll take that decision yourself later (OptIn). A good image viewer in this respect is the FastStone Image Viewer. VLC Media Player and Media Player Classic (K-Lite Codec Pack) also provide a 'Cancel' option for file association settings during setup. But when I used them (3-4 years ago), such aggressive players like QuickTime and RealPlayer with their mandatory online "media guides" seemed to ignore ANY of the user's wishes. That's their business model (Spyware/Adware-like) and that's why they're no longer installed on my computer.
P.S.: On a DefaultPermit system like Windows, rules for so-called "convenience" (actually a business model we have been trained and conditioned to follow) may always bypass security rules, even program restriction policies (file associations = programs linked to them). The architecture of Windows is insecure; MS has done a lot in the sense of "anti-user" and "anti-exploit" kind of measures, but as the saying goes: You cannot make a silk purse out of a sow's ear. That's why I urge everyone to rethink convenience vs. security.

Paul