Sandboxie security flaw???

Disclamer: Until moments ago, I had no freaking idea something like that could happen. It also doesn't seem to be documented as being known, or being a limitation of Sandboxie. Therefore, if it's a limitation of Sandboxie, then it should be documented. Any limitation of any security solution should be publically known, so that users can act upon those.

Reproducing steps:

1. Create a folder in your Desktop;
2. Force the folder to a sandbox;
3. For testing purposes, download this file: http://hostsman.it-mate.co.uk/HostsMan_4.0.81_beta2.zip;
4. Place it in the folder you created in step 1;
5. Double-click the zip file to open it as a folder. (Make sure you're using Windows 7* built-in function!);
6. Double-click hm.exe and execute it;
...
7. What happens?
...
8. It executes outside of the sandbox.

I'm glad that it was just Hostsman and that I also have AppLocker, that actually blocked the execution. That's what called my attention, actually.

I don't know if it's a security flaw or simply a limitation of Sandboxie; but, it's the latter, then users should know of these limitations, so they can make the necessary changes to certain routines, IMHO.

-edit-

* I don't know if the zip function is present in other Windows versions, such as Windows Vista.

This issue (or at least the concept) has actually been discussed a lot across many forums, including over on the Sandboxie forums, and also on these forums.

I think generally tzuk says that .exe files will always open sandboxed when run within a forced sandboxed folder. However, he has stated many times that some other file types may not open sandboxed, depending on the situation.

I'm not surprised that running a .exe file from within a built-in function of Windows results in the file running outside the sandbox. The reason I'm not surprised is that eg. opening a JPG file (inside a folder which is forced sandboxed) with Windows Picture and Fax Viewer will result in the JPG file running outside the sandbox too. Sure, it's not a .exe file in this instance, but I think it's a similar concept.

In summary, Sandboxie's forced folder feature has limits - there is no guarantee that every file will open sandboxed within a forced folder. This is why I personally never rely on it. In fact, I essentially don't use that feature.

I suppose it would be good for this limitation to be formally documented. However, the same limitation (in principle) exists with software like DefenseWall and GeSWall too, and I don't think they document this.

Thanks for the feedback!

I know that the Forced Folders has been discussed before, but I remember being said that it would work for executables.

I believe there was some hype about Forced Folders, due to another user, from another forum, mentioning that Sandboxie wouldn't run non-executables sandboxed if executed from very lenghty folders... or something like that.

But, tzuk's answer was that Forced Folders was/is advertised to force executables.

For instance, I'm not/was not surprised that it opened the *.txt files, within the zip file, outside of sandbox. I would expect that behavior.

I was surprised because this happened with an actual executable. This executable being inside a forced folder, whose function Forced Folders is advertised to force them. Therefore, I had no reasons to suspect it wouldn't.

This changes one's perspective... lol

-edit-

What you mention here...

ssj100 wrote:
I think generally tzuk says that .exe files will always open sandboxed when run within a forced sandboxed folder. However, he has stated many times that some other file types may not open sandboxed, depending on the situation.

... is pricesely the reason why I believed the executable would open inside the sandbox, because it was in a forced folder.

Yes that's right. I suppose your situation is slightly different, as you're sort of running the executable from a zip program, which so happens to be built into Windows. I wonder if the same issue occurs with a third party zip program? I have a funny feeling it won't.

ssj100 wrote:Yes that's right. I suppose your situation is slightly different, as you're sort of running the executable from a zip program, which so happens to be built into Windows. I wonder if the same issue occurs with a third party zip program? I have a funny feeling it won't.

1. Any limitation should be documented, so that the user can act accordingly. I believe we agree on that.
2. As a user, regardless of my level of knowledge, I shouldn't have to guess what kind of limitations Sandboxie has. Those should be provided the Sandboxie's author.
3. I also should not feel in need of using a third-party application... As a user, I certainly would not switch applications, if I don't know I'm in a possible danger.

4. I know I shouldn't place alluminum foil in the microwave oven. I know that, because when we bought our first one, we read the documentation. Can you imagine what would have happened, if the instructions documentation lacked that piece of information?

5. That said...

5a. There's a two edge sword with third-party compression tools.

5a.a. Remember I'm having under consideration someone using the Forced Folders functionality as I was using. That was the only function I was using. It's been advertised to work to force executables. That was my aim.

5a.b. Having 5a.a. under consideration, if you double-click a zip file from within the forced folder, then yes, the zipped file will be forced to open in the sandbox.

5a.c If you have an executable inside the forced folder, and if you open say 7-zip, and then go to the that forced folder from within 7-zip, and launch the executable, then it will launch inside the sandbox.

5.a.d If you proceed as in step 5a.c, but this time with a zip file, and then launch the executable from within the zip file, then the executable will be launched outside of the sandbox.

6. Could that behavior/Sandboxie limitation be abused? In our systems, I doubt. Take that as you want.

I understand your point - I was actually asking whether running a third party zip program would make a difference purely out of curiosity. Ever since I started using Sandboxie, I have never relied on the "Forced Folders" feature (I essentially don't even use it), and it's always been my personal recommendation for others to follow suit.

Anyway, tzuk is generally pretty good with documentation of limitations - take the 64-bit issue for instance. I'm not sure if tzuk knows about this zip issue, so it might be worthwhile posting it over on the Sandboxie forums to let him (and others) know. Other examples of such documentation on limitations can be found here:
http://www.sandboxie.com/index.php?KnownConflicts
http://www.sandboxie.com/index.php?DetectingKeyLoggers
http://www.sandboxie.com/index.php?NotesAbout64BitEdition

Perhaps the documentation of the zip limitation is also documented somewhere else? I'm just trying to emphasise again that tzuk is generally very open with the public on the limitations of Sandboxie.

ssj100 I'd like to thank you for understanding.

Unfortunately, I will not post this in Sandboxie's forum. There's been a conflict between tzuk and I, and he clearly stated I was no longer welcome there. He actually deleted some of my posts - that initiated all of that.

If you'd like to know the reason, I can PM you, if you'd like to. I got nothing to hide, I just don't want to polute the thread with something 100% off-topic.

I decided to post what I found at your forum, because I know you're avid user of Sandboxie and someone who goes there, and if you thought it was serious enough to post it there, then you would.

-edit-

By the way, I'd like to know what you think about the following. But, first of all, I'm not an expert... I just know a few things I learnt over the years. lol

I'm sure you're familiar with packed malware? Basically using such functionality/technique, malware authors can turn a known malicious code into something "new". (Packed malware is an easy way to bypass antiviruses/antimalware, which detect by signature/hash...)

Now, let's imagine for one second that Sandboxie was being used by the masses, right now.

Anyone using Sandboxie the way I was/am, has a vector attack right there.

All I'd have to, if I were a cybercriminal, would be to send a zip file to my targets. I know before hand that any of these people would be placing the files in a folder, that would be forced to a sandbox.

I'd also know that it would be a perfectly legitimate choice only to use Forced Folders. Maybe they just want this kind of safeguard, as I wanted.

Imagine any one of these people receiving an e-mail with a zip file. This zip file is placed in the forced folder.

The user doesn't even have to open the zip file, in any way. All I'd have to do is create a script (maybe a vbs script ???, which is not blocked in Windows by default), that would simply open the zip file and launch the executable from within the zip file. Of course, this script would come in the e-mail as well.

If I could do it manually, for sure cybercriminals can automate all of this and all behind the scenes?

So, if this could happen, then I'd consider this to be a pretty serious security concern.

Again... if it can happen.

m00nbl00d wrote:By the way, I'd like to know what you think about the following.

Sounds interesting, but doesn't sound like something that would happen in the real-world. If it did exist, I would guess that the likelihood of a home user coming across such an attack vector is negligible. However, if it did exist, I don't think there's anything Sandboxie could do about it. The Forced Folders feature is unfortunately an unreliable mechanism in Sandboxie.

With my own security setup/approach, I would hope that SRP would block the execution of the executable within the zip file. I would also wonder how the script itself would execute in the first place - presumably it would have to be spontaneous, otherwise it would have to rely on "user error". If it's via a zero-day exploit resulting in remote code execution (particularly a kernel-level exploit), then pretty much everyone would be susceptible to it anyway.

In other words, I suspect that if this malware mechanism was able to attack a system spontaneously, it would likely be using exploits that Sandboxie (or any other home security mechanism) can't do much about anyway.

By the way, on a similar note, I actually have a folder that I basically never open/view with a REAL explorer.exe - I always use a sandboxed explorer.exe to open/view it. All newly introduced files from the internet or external devices are moved there directly without having to view the file in a REAL windows explorer. I've got into the habit of doing this because Didier Stevens demonstrated an exploit where malware executed without the user opening the file. In fact, all the user needed to do was to hover their mouse cursor over the file to trigger (malicious) execution. This was done by exploiting the "explorer.exe" process.

ssj100 wrote:
Sounds interesting, but doesn't sound like something that would happen in the real-world.

Why wouldn't it happen?

If it did exist, I would guess that the likelihood of a home user coming across such an attack vector is negligible.

How so? Nowadays, yes you're right. Sandboxie is that much widely used to become a target, at all. But, in the scenario I proposed, I mentioned a way to abuse Forced Folders, which... well... it's advertised to force executables.

Any other functionality Sandboxie has really has no bearing. No other functionality should excuse a severe limitation. The fact Sandboxie/other application isn't that widely used, should never execuse limitations that could pose a risk.

However, if it did exist, I don't think there's anything Sandboxie could do about it. The Forced Folders feature is unfortunately an unreliable mechanism in Sandboxie.

Interesting that you say unreliable. Is Sandboxie's author aware that it's unreliable? Was he aware of that when he decided to make of Forced Folders a functionality you could only use paying for a license? Sorry, but, for me, saying it's an unreliable feature doesn't cut it. If it's unreliable or not 100% trustworthy, then either it should be documented in Sandboxie's official FAQ's website, for example, or simply remove* the functionality for once and for all. A security application should not have unreliable functionalities. Otherwise, it's what... a paradox?

* If it isn't there, then the user won't be using it and lead to believe it will work.

With my own security setup/approach, I would hope that SRP would block the execution of the executable within the zip file.

I really don't think we should bring other security methods into discussion. Otherwise, I could very well say that antimalware/antiviruses are as effective as any other security solution, such as Sandboxie, and simply because I'm using AppLocker. It makes no sense, at all.

I would also wonder how the script itself would execute in the first place - presumably it would have to be spontaneous, otherwise it would have to rely on "user error". If it's via a zero-day exploit resulting in remote code execution (particularly a kernel-level exploit), then pretty much everyone would be susceptible to it anyway.

Why would you need a kernel exploit? I remember when many people used to victims of .vbs scripts. Nothing blocks the execution of these scripts by default in Windows. That's actually what made Microsoft change the way PowerShell scripts work; they can't be executed by default. VBS scripts can be, though. I'm talking about VBS scripts, but a cybercriminal could use any other method. I just happen to remember VBS scripts received via e-mail were a nightmare to a lot of people.

Also, is user error that uncommon? I thought it was the other way around.

In other words, I suspect that if this malware mechanism was able to attack a system spontaneously, it would likely be using exploits that Sandboxie (or any other home security mechanism) can't do much about anyway.

Because, as you said Forced Folders is unreliable? If Sandboxie Forced Folders could intercept Windows zip built-in function and/or third-party compression tools, when opened unsanboxed, to open a forced folder zip file, and then launch an executable, then it could prevent the malicious actions, and simply because the executable would be launched from within a zip file, placed in a forced folder.

-https://www.f-secure.com/v-descs/iframe.shtml

By the way, on a similar note, I actually have a folder that I basically never open/view with a REAL explorer.exe - I always use a sandboxed explorer.exe to open/view it. All newly introduced files from the internet or external devices are moved there directly without having to view the file in a REAL windows explorer. I've got into the habit of doing this because Didier Stevens demonstrated an exploit where malware executed without the user opening the file. In fact, all the user needed to do was to hover their mouse cursor over the file to trigger (malicious) execution. This was done by exploiting the "explorer.exe" process.

That's all very valid, but it doesn't exclude the fact that many may be/will be using the Forced Folders functionality, just the way I was. Also, as I previously mentioned, it's no excuse for not letting us know about any limitations. Just because user X is using functionalities A, B and C, it won't mean that user Y will be using them as well; he may as well be using only C. A very legitimate choice.

And, as of now, you don't even need to trick the user or exploit a bug. All it has to happen if for any user Sandboxie user, like me, to believe a functionality advertised to work in a certain way is working as it should, when it isn't.

Don't get me wrong, as of now, there's no danger of any exploit/trick to abuse this. Sandboxie isn't that widely used, at all. But, that doesn't mean that even a geek user, using just the Forced Folders can't fall for an accident, like I did.

I didn't know that Forced Folders was unreliable to the point of not being able to intercept that a compression tool is launching an executable from within a zip file. You can be sure many others won't. They may be forcing their compression tool to a sandbox, but that won't change the fact that they don't know.

So, while in itself it may not be a security flaw, but only a limitation, by not letting Sandboxie users (present and future) know about these limitations, it becomes a security risk. I was lucky enough that I was opening a very legitimate application, regardless of having AppLocker.

I don't know what else to say. If you're unhappy with Sandboxie, its limitations and its documentation etc, then just don't use it. Pretty simple really. I was just mainly trying to make conversation before haha. You make some good points of course. Unfortunately, I repeat, the Forced Folders mechanism of Sandboxie is not reliable - I've known this pretty much ever since I started using Sandboxie, and I've repeated this issue many times over the last few years across many forums, including on the Sandboxie forums. I've also repeated many times that I don't personally rely on it and that I don't recommend others using it (or at least "relying" on it). I suppose it's ultimately up to tzuk to document this limitation formally.

Yes, I know you were trying to make a conversation. I also know that you know that Forced Folders is unreliable. But, the problem is that this is about those who don't/won't know. Why doesn't Sandboxie actually has that information in the Forced Folders section? They would know when setting up a Forced Folders about the limitations. So, why not? Is it because it damages Sandboxie reputation or something like that?

Forced Folders also allows to force the execution of CD/flash drive contents to a sandbox. Yet, this won't always work either, I suppose.

After all, it wouldn't even be necessary for this information to be only in the FAQ. If it were explained in Forced Folders section, then we would know about. I would have known about it.

Also, it's not a matter of being unhappy. For instance, there was a known limitation (by design) in AppLocker. Didier Stevens actually brought this up to discussion and I think he got in touch with Microsoft. Eventually, Microsoft provided a hotfix for it, and actually documented it on Technet Library, where administrators will look out for information.

That info was only in MSDN Library, where developers go get the information.

It was not about being unhappy about it; it was about a know limitation by Microsoft not being properly documented, where administrators will check the information about new technology introduced by Microsoft.

Now, only Tzuk kows if this is a limitation or would simply require way too much work to make it work... It doesn't really matter, at all.

I'm just pointing out that this limitation can be abused - and it can! - and it won't even be necessary to use an exploit.

As you said and as I said, user error happens all the time.

Now, I don't know how anyone else has their Sandboxie/system configured. It doesn't concern me. What concerns me is how I got mine. With that said, many other people may be using/may come to use Sandboxie the very same way I was using.

A little background on what I used to do. Overtime, I simply got sick and tired of applications simply not working or being slow when running sandboxed. Initially - a few years back - I actually bothered reporting them over Sandboxie forum. Under several nicknames, as I never registered there... until maybe a couple years back.

A new version would eventually come out and would fix those issues, but then at some point, either some other application or even the same upgraded application would have issues when sandboxed, all over again.

Well, I soon got tired of having to deal with that and decided only to use the Forced Folders functionality. Heck, it was one of the reasons that made me actually buy Sandboxie.

So, I tweaked my system and eventually came to a point, where using Windows Vista and 7 own methods, I achieved a virtually unbreakable sandbox.

I still wanted to run apps (test new apps and eventually keep them), and considering that I in the last couple years I've been unable to use virtual machines, because unfortunately the current machine simply can't handle that much, I created a folder where I placed installers/executables/zipped installers/executables, to eventually test them.

So, basically I make a triage of the files I download.

Now, imagine someone - Jane/Joe - using this same approach, and maybe because someone set it up like that, otherwise they would freak out with any problems that could occur with sandboxing daily used apps. Again, a very legitimate option.

This Jane/Joe searches Google for a pdf convertion tool. The user starts to opening Google results and gets to a website that has one. The user has to download a zip file, which will be containing the pdf convertion tool. There's also a link to download a text file containing the instruction on how to use it.

Jane/Joe knows that should be running the contents of the zipped file in the forced folder, specially created to test applications and even run them in a safe, isolated file system and registry environment.

The zipped file is in the forced folder.

Scenario nº1: The user is using Windows built-in zip functionality. The user believes that all is happening in the isolated environment. It is not. Result? Do the math.

Scenario nº2: The user is using a third-party compression tool. 7-zip, for example.

If the user double-clicks the zip file, that is in the forced folder, then 7-zip will open in the sandbox, even though 7-zip itself is not forced. No issues.

Scenario nº3: The user is already using 7-zip, which is unsandboxed, and decides to open the contents of the zip file. The user believes that due to Forced Folders forcing executables, that the executable within the zip file will be launched in the sandbox. The user couldn't be more wrong. Result? Do the math.

Scenario nº4: The user doesn't even open the zip file. The user firsts open the text file to read the instructions. Guess what? It's not a text file. It's a script/executable that will be launching the executable from within the zip file, and therefore lauching it outside of Sandboxie's protection.

Windows doesn't show the file type extensions, by default. This is already in favor of the bad guy.

I too was a little miffed when I found out that the Forced Folders mechanism was unreliable back in 2009. However, I adjusted my security setup/approach to avoid relying on the mechanism. For example, for USB/CD drives, I would only browse them with the right click context menu "Run Sandboxed". I also universally disabled autorun.

But yes, it's certainly not a well known limitation. I think based on many of his posts, "Sully" relies on this mechanism quite heavily, which is surprising considering his extensive experience with Sandboxie. I suppose I got lucky coming across this limitation so early on - I experimented with Sandboxie a lot back in the day.

Just a few more comments before I explore this issue further. It's interesting to see that some people who are aware of the Forced Folders limitation still rely on it to run executable files. Sandboxie advertises the Forced Folders mechanism as follows:

If any program in these folders (or in a sub-folder of one of these folders) is started outside any sandbox, will be automatically sandboxed into a particular sandbox.

Note the use of the word "program". It's actually quite a vague term. Anyway, presumably those relying on it to run executable files sandboxed probably think that the Forced Folders mechanism only fails in very specific situations (eg. Windows Picture and Fax Viewer and picture files). However, for me, the fact that it fails in any situation is more than enough for me to never rely on it. I remember stating (repeatedly) on the Sandboxie forums something along the lines of "who knows what other situations it will also fail in". Not surprisingly, there was no active acknowledgement of my statements. But your situation as you have described in this thread is one example of my point coming good.

Anyway, can you reproduce the issue with WinRAR? I was doing some brief testing before in my VM and I think WinRAR is fine in this situation. I then installed 7-zip, and interestingly, Sandboxie asked me to apply a compatibility setting - perhaps this may be contributing to the issue? Regardless, I was able to reproduce the limitation, but I don't think it was exactly the same as what you have described. For a zip file in a forced sandboxed folder, I opened 7-zip via the right click context menu - it failed to open sandboxed! Therefore, as expected, anything running from there also failed to open sandboxed.

I think this emphasises and confirms that the Forced Folder mechanism is a bit of a mess.

Unfortunately, as I said I can't play with virtual machines, so to test WinRAR I'd have to install it in my real system, create backups and all that. Way too much. Maybe someone else could test it, though. Someone also working with virtual machines.

ssj100 wrote:
I then installed 7-zip, and interestingly, Sandboxie asked me to apply a compatibility setting - perhaps this may be contributing to the issue? Regardless, I was able to reproduce the limitation, but I don't think it was exactly the same as what you have described. For a zip file in a forced sandboxed folder, I opened 7-zip via the right click context menu - it failed to open sandboxed!

Not sure what you mean. What exactly failed? The executable in the zip file?
I also don't know if the compatibility aspect has any weight... I'll check it out.

If that's what you mean, I know that the executable would fail. Actually, right-clicking and running sandboxed would fit in my Scenario nº2, where I mentioned nothing bad would happen, because the executable would run sandboxed.

But, if you open* 7-zip, unsandboxed/not forced to any sandbox, then go to the zip file placed in the forced folder, from within 7-zip, open the zip file there and launch the executable, then it will launch outside of the sandbox.

* What I mean is, for example, go to Start Menu > All Programs and in 7-zip, click to open it. Or, even having the shortcut placed in the Desktop.

ssj100 wrote:
I think this emphasises and confirms that the Forced Folder mechanism is a bit of a mess.

So it seems.

m00nbl00d wrote:Not sure what you mean. What exactly failed? The executable in the zip file?

By double clicking the zip file, 7-zip itself failed to open sandboxed, and anything running from within 7-zip also failed to open sandboxed.

m00nbl00d wrote:But, if you open* 7-zip, unsandboxed/not forced to any sandbox, then go to the zip file placed in the forced folder, from within 7-zip, open the zip file there and launch the executable, then it will launch outside of the sandbox.

* What I mean is, for example, go to Start Menu > All Programs and in 7-zip, click to open it. Or, even having the shortcut placed in the Desktop.

Yes, and what's interesting is that I couldn't reproduce that in my VM testing. If I opened 7-zip unsandboxed, browsed to the zip file from within 7-zip, and then ran the executable within the zip file, it ran sandboxed!

Keep in mind that I was testing all this with WinRAR installed in the VM, and my Guest OS is Windows XP.

ssj100 wrote:
By double clicking the zip file, 7-zip itself failed to open sandboxed, and anything running from within 7-zip also failed to open sandboxed.

I see. So, in your case Sandboxie was being twice as careful. But, what you're experience is a bug, then. It should allow 7-zip to start.

ssj100 wrote:
Yes, and what's interesting is that I couldn't reproduce that in my VM testing. If I opened 7-zip unsandboxed, browsed to the zip file from within 7-zip, and then ran the executable within the zip file, it ran sandboxed!

Keep in mind that I was testing all this with WinRAR installed in the VM, and my Guest OS is Windows XP.

I tested the same procedure with 7-zip compatibility disabled in Sandboxie, and I get the same results as before. So, compatibility mode has no weigh.

It would be interesting if others could test it as well using Windows XP - as you have or Windows 7 - as I have.

Would not having WinRAR make any difference?

I wonder if these descrepancies we're experiencing mean that there's more to this than it being a simple limitation? At least in what comes to Windows 7? And, who knows, Windows Vista as well?

-edit-

Or, it's simply one more of those situations that we'll see Forced Folders not working as it should.

Yes, I think it's more to do with Forced Folders just not being reliable - as we've come across, there are actually many variables involved with this mechanism. I know next to nothing about programming, but I suspect forcing a folder (or I suppose a path) to run anything within it "sandboxed" (or any other command) can be incredibly complex, depending on the exact scenario.

I have both an XP and Win7x64 vm and I use WinRar v4. I can try some tests, probably mid-weekend.

I just tested it again with both WinRAR and 7-zip and I can confirm the same findings as m00nbl00d. I must have tested it wrongly before. With either program (WinRAR or 7-zip), if you try to run something from within the actual unsandboxed program, it will run unsandboxed.

Thinking about it again, I'm not sure if I'd personally say that this is a "limitation" of Forced Folders. You're using an unsandboxed zip program to open files. Sure, those files happen to be in a folder subjected to the Forced Folders mechanism, but you've sort of circumvented it by running an unsandboxed zip program to access the files. If it is labelled a "limitation", then I would personally call it an "expected limitation", given my previous experiences with the Forced Folders mechanism.

And, that would be precisely all a cybercriminal would have to do. Tricking the user into opening a bogus text file (=script file, etc), that would launch the executable from within the zip file.

And, there you go...

Regardless of being a limitation or an expected limitation (to the author), that still doesn't change anything. In my opinion, of course.

I would imagine that Sandboxie's author could make Sandboxie detect that an executable was/is going to be launched using a zip file, stored in a forced forced? Prevent its execution, then ask the user where or not he/she still wants to allow execution?

I mean, this is something that could be potentially abused. Considering that Forced Folders is actually a paid* functionality, maybe the developer could try and see if he could implement that secondary protection, for those moments?

* I'm not saying that it should be fixed only because it's a paid functionality, though. It happens it is, and considering its paid functionality, maybe the developer should make all efforts possible to fill in that gap.

I just feel that something should be done about it. If it's impossible to actually work the limitation, then go around it and detect the launching of the executable from within a forced zip file.

It would be really nice to see the Forced Folder mechanism become more reliable. However, I still wouldn't use it unless it was completely reliable (in the same sense of Sandboxie generally being otherwise completely reliable). The fact that it can't guarantee non-"program" files to open sandboxed is a huge issue for me. It's almost like an Antivirus only detecting malicious ".exe" files but not malicious ".dll" or ".bat" files. I know it's arguably not quite that level, but it doesn't feel far away from it for me.

By the way, found some key threads related to this issue here:
http://www.sandboxie.com/phpbb/viewtopic.php?t=6160
http://www.sandboxie.com/phpbb/viewtopic.php?t=12003

Perhaps the most important comment is from tzuk himself:

Again, the feature is not reliable for non-EXE files. This means sometimes stuff will work, and sometimes it won't work, and it depends on how Windows Explorer opens the viewer program, and if Sandboxie can infer that it has anything to do with a forced folder.

If you're curious, there are old topics about this.
http://www.sandboxie.com/phpbb/viewtopic.php?t=7081
http://www.sandboxie.com/phpbb/viewtopic.php?t=6672

Short answer is you need to work around this behavior by using forced programs in addition to (or instead of) forced folders.

It was actually nice to see tzuk "admit" or "clarify" it like he did - it's something I've been repeating for years. Many people (including seemingly very tech savvy ones) appeared to repeatedly ignore it. So it's good to see it coming out from the horse's mouth!