Google Chrome vs. FX+NS; integral sandboxing vs. 3rd-party

[NickP]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

@ Tom

"Thank you for not only taking the time to reply, but for also taking the time to do the research and to cite original sources for those who wish to see for themselves. You and I have discussed in another context that corporations are inherently self-serving (it's their duty to the stockholders), so I'd rather look to independent researchers than to corporate press releases -- regarding *anything*. "

Thanks and I agree. Got to be careful when looking for the "independents," though, as many have personal or paid biases. This problem is the worst with politicians and drug studies. Fortunately, the IT security research community is diverse & competitive enough to prevent or squelch most bogus claims.

"I came away from our private conversation thinking that you thought Chrome sandbox to be excellent, possibly/probably better than Sandboxie. Do I retract any portion of the above apology? "

http://hak5.org/episodes/episode-703

Skip to 10min mark where they do free Comodo vs Sandboxie. Sandboxie gets owned repeatedly with its recovery feature (and maybe something else). Comodo stops stuff even if the user is a self-defeating noob. A test of "host intrusion prevention systems (HIPS)", as we used to call them, in the past showed DefenseWall & Sandboxie to be better than the others, but both of them let certain stuff slip through. Comodo Defense+ is newer, yet getting better over time. Maybe SB is better now or maybe new features = new problems.

The real issue I have with Sandboxie is that they have tons of awards and security labels, but little independent serious review. The program is a black box: nobody knows in detail how its supervisor mechanisms work or can easily do a code review. Chrome uses OP-style sandboxing at the browser level, is bug-hunted relentlessly, and was analyzed w/ source by several experts on bug-hunting and sandboxing. It's received *much* more scrutiny than Sandboxie. That matters in the security community when one is making assurance arguments.

I think part of SB's protection level is it's sandbox design, but a major part is malware authors aren't directly targeting it. The fact that most scrutiny in Chrome has found issues makes me almost certain that similar scrutiny in SB would show similar results. The SB team would have to be savant programmers, have Windows source code or apply EAL5-7 security engineering techniques to do better than the Chrome implementation. To be clear, I'm not cutting SB developers down: I'm just saying the Chrome team tried really hard for a long time only to produce a sandbox with vulnerabilities & SB people likely did too.

I don't use Chromium for privacy concerns & lack of NS-like features. The sandboxing feature never really concerned me. Most bugs for Chrome are found by white hats & never get exploited. The largest source of bugs in browsers are renderers and plugins. Rendering is sandboxed. Untrusted plugins are sandboxed. Trusted plugins can be further restricted by the OS thanks to process isolation. So, the sandbox definitely has bugs and bypass issues in it somewhere, but it will do fine against wild malware. Ironically, one of the best claims comes from your link on Chrome vulnerabilities:

"No security vulnerabilities in Chrome have been successfully exploited in three years of Pwn2Own."

On the flip side, I think the Mac was exploited first in many of those competitions. Gotta love security theater.

"paying a record $3,133"

I think that was an intentional joke. In hackerspeak, elite = "leet" = l337 or sometimes 31337. It's just a guess, but I think it's a pun on leetspeak. When considering compensation for app bug hunting, you have to also factor in pride and the feeling of being elite/special/whatever. Mozilla & IE have had many, many issues. Chrome is the one that's last man standing at most hackathons. Hence, they aren't just getting money: they get the pride of defeating "the most secure browser."

"Overall, which do you think more effective, ceterus parabus: Chrome sandboxing or Sandboxie? Or is there another third-party sandboxing solution (for those who don't want to go to the expense or effort of full-on VM) that you think is more secure than all others? "

It's hard to say. Like I said, without adequate analysis of Sandboxie, all we can say is it stops all the most common malware variants & catches most others. Chrome's got good malware prevention & isolation. NS is the only reason I would recommend Sandboxie & FF. However, the Comodo thing might be better for lay users who are easily tricked (the majority lol?).

My top recommendation for usable, affordable, secure browsing: a dedicated (cheap) PC with a hardened Linux (or OpenBSD) that runs from read-only boot + a KVM switch. It would have FF/NS on it, of course. The user would just turn it on, wait a while & then could switch between PC screens with the press of a button. A safe file transfer option could be made available with easy GUI for sharing files either way.

Next best thing is a hardened Mac due to great usability + obscurity. Next, a browser VM in a reputable product, like VMWare or VirtualBox. Far less usable, but safer, is restarting the computer with a LiveCD or LiveUSB stick. Both would run a hardened Linux & are easy for lay people. I recommend this for online banking. If not Linux (many possible reasons), then a hardened copy of Win7 is ideal. One guy on SB forums runs FF/NS on SB in a VM for messing with really dangerous stuff. So, those are some cheap options to start with. (Did I just say "cheap" and "Mac" in same paragraph? My bad.)

If you can afford or acquire it, an isolated browsing solution powered by INTEGRITY, LynxSecure or VxWorks MILS is "probably" good. (Dell Secure Consolidated Solution is an example.) Another option is General Dynamics High Assurance Platform. I laugh at the "high assurance" part, especially considering Bell's paper, but the system is accredited for Top Secret. This means it was at least tested & analyzed. It's also very usable. Another one that depends on a small TCB is the Turaya Desktop offering. It leverages TPM, isolated trusted processes, a microkernel & paravirtualized desktops to protect the system. INTEGRITY Workstation was an earlier product that did the same & might still be available.

So, you have plenty of options. From there, you must choose the best one to suite your needs.

"btw, although the digital sig ID's you as the originator of this post, you do know that I can copy it, minus the header and footer, and post it as my own, anywhere on the planet? ... kidding. "

You had to be. All I'd have to do is say, "Encrypt this with the private key you signed it with. I've encrypted two more things that can be verified by decrypting with my public key." And you couldn't or wouldn't... and everyone would know who *really* wrote the post. Just as digital signatures are supposed to work.

Side note: If it seems I'm bashing the hell out of SB, it's not intentional. In trying to be balanced, I'm giving SB the intense scrutiny I already gave to the Chrome platform.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJOzvQsAAoJEFvQ0aBVJJxWeN8IAI2Ergc/2Rnj5AaO9Gn5bv/U
ARiGq2DQ9guEYSYraQOLWL5eaZ6JHBzYNYzYpBONcUAq0DA5Elw9l5PErpJgQd6y
O4MegspAG6LyD0XrpzID8XFGqJQ1dBgJytJ+bON0mrS6vPdCLz3FgOf9SjdJCsAh
dS5gZbycxLavVYGHI4fKkrbDJ8Yi5dGYsVwEyELvNJxpFA1hiUYyf1iWxA00oiGZ
6sICz5DMSLuixULDJCfXRYUdk89Jr+J+C9NMv7Bpho0GuMniB/d4HvI4dPP4qmZv
lFrSsN0XYfz4H8OyNWI1EYAStsKo9IUiar1VbeeA1BfiTETAEzeva93xGtjnsjU=
=KwmQ
-----END PGP SIGNATURE-----

[NickP]

@ Hungry Man

"I get some of the issues you mentioned about Chrome but many of those issues apply directly to Firefox + NS as well. I can't say "This is where Firefox + NS is weak therefor Chrome is better" =p I have to say why Chrome isn't weak in those areas. I'll respond further later. I don't feel like writing an essay on thanksgiving =p"

I was trying to take a hard, balanced look at these things. I talked more about Chrome because that was the focus. However, some of the issues I presented may apply to other browsers. It's actually part of why I mentioned those things: to give room for more analysis and discussion.

[Hungry Man]

The program is a black box: nobody knows in detail how its supervisor mechanisms work or can easily do a code review. Chrome uses OP-style sandboxing at the browser level, is bug-hunted relentlessly, and was analyzed w/ source by several experts on bug-hunting and sandboxing. It's received *much* more scrutiny than Sandboxie. That matters in the security community when one is making assurance arguments.

A sentiment I have echoed widely both on separate forums and to a lesser degree on the Sandboxie forum. The lack of proper V&V, closed source, and a single dev being responsible for the entire product and the implications of these things.

I think that was an intentional joke. In hackerspeak, elite = "leet" = l337 or sometimes 31337. It's just a guess, but I think it's a pun on leetspeak.

It certainly is =p


As for Comodo and Sandboxie they work fairly differently. The main strength (And weakness) of SB is that you can poke holes in it. I can give Chrome read/write access to my downloads folder and that can cause problems.

That's negating the issues I mentioned earlier.

I was trying to take a hard, balanced look at these things. I talked more about Chrome because that was the focus. However, some of the issues I presented may apply to other browsers. It's actually part of why I mentioned those things: to give room for more analysis and discussion.

Yes, the reason I broght it up is because a portion of what you said definitely applies to both.

I also think that NoScript has some inherent weaknesses by relying on user interaction but the fact that some protections remain despite the whiteilst is imo whta makes it so powerful. Those are also, incidentally, the only protections that I think are worth using (I don't think blocking content is really strong security.)

[Tom T.]

Keetch on several sandboxes (paints darker picture)
http://media.blackhat.com/bh-eu-11/Tom_ ... xes-WP.pdf

Keetch's on practical sandboxing
http://www.slideshare.net/tkeetch/black ... -sandboxes

Barely have had time to skim those, much less reply to the responses, but I did see that those papers covered only:

IE Protected Mode
Adobe Reader X
Chromium

No mention, AFAICT from Table of Contents and a quick search, of third-party sandboxing applications.

"SB pwned through Recovery feature". You can run your AV scanner over anything inside the SB *before* recovering it to your desktop or whatever. If I forget to lock my front door before leaving, I can't blame the locksmith if I get burglarized.

Got to be careful when looking for the "independents," though, as many have personal or paid biases. This problem is the worst with politicians and drug studies.

lmao You got that last part right, Bro!

"without adequate analysis of Sandboxie, all we can say is it stops all the most common malware variants & catches most others.

It's not an AV or anti-malware program. It's a sandboxing program, and one point that is almost *never* mentioned (here I go sounding like a fanboy again), is that you can run *any* program inside the sandbox. Got a suspicious MS Word doc? Open Word *inside Sandboxie*, then open the doc there. Same thing with a Flash video, .pdf, *any* executable can be run in the sandbox. Surely Chrome doesn't do that? IDK whether Comodo does, but we had a long thread here a ways back where a Comodo fanboy kept insisting that with Comodo, he didn't need NS or default-deny JS. Giorgio took three minutes to write two benign POCs that ran strictly in the browser, which the Comodo product being touted couldn't have touched.

SB works by installing a kernel-level driver that renders the entire HD read-only to whatever app is in the sandbox, including the browser or whatever else. It creates a virtual C drive, clones the needed portion of the registry into a virtual Reg hive (tends to be 256k for running the browser), clones your profile if the browser is the app being SBd. All are dumped on exit, if so configured. (Best practice.)

And you do realize that your ideal setup is way beyond 99% of Average Home Users? ... We get lots of complaints that even NS on Firefox on Windows is too complicated for them... AHUs need the simplest, most intuitive, yet safest, combo possible, and are going to buy a computer preloaded with Windows or Mac. Just getting them off of IE can be a major effort. Search my posts for the complaints where "I love Fx/NS, but my spouse/parent/child/whatever won't touch it" -- one recently: "Can't get my wife off of AOL."

Re: video of Comodo v. SB: Haven't had time to watch yet, but

"Maybe SB is better now or maybe new features = new problems."

TBH, I do stick with an older version. Some of the changes were merely for Vista/7 compatibility, and we both know that every line of code added is another chance for an exploitable flaw...

@ Hungry Man:

The main strength (And weakness) of SB is that you can poke holes in it

Without that, you can't save bookmarks, cookie permissions, etc. You'd have to shut the browser, open a non-SB browser, and make those changes manually. PITA. Of course, when you go running around with a drill, you have to be careful where you drill.

btw, this is why I liked Fx 2.x better than 3+ -- bookmarks in simple HTML file vs SQLite db. Can't see any malice possible in bookmarking a new page, then saving that bookmark through to prefs.js\bookmarks.html. This db stuff is a lot more complex and less immediately visible to the user. Sure, use the SQL Manager add-on -- which adds yet more complexity, and more attack surface..

a single dev being responsible for the entire product

Guess you should uninstall NoScript immediately, as Giorgio is solely responsible for the released product (though he may get a bit of behind-the-scenes help here and there, but nothing compared to the entire program.) Let's all wish him health and long life.

(I don't think blocking content is really strong security.)

It's an *additional layer* of security. If you are not familiar with the concept of "Defense in Depth", please read up on it.

The exact opposite is "single catastrophic point of failure".

As already mentioned, in doing support I sometimes have to disable NS or allow sites I'd rather not (at user request), so the other layers of defense (incl SB) had better hold up.... But that's a voluntary choice on my part, inherent in volunteering to donate my time here.

[GµårÐïåñ]

I have been reading this thread and I didn't feel that I should comment or step into it but I wanted to say something really quick because I have spent over 20 years as a developer, worked with the military and done a lot of security work and wanted to drop my two cents, for what its worth. I personally find comments by all sides to have valid points and some invalid points that are based on personal bias, which is natural, no harm there.

However, I have not found ANY system in existence, be it Windows/Linux, Installed/Live, Fx/Chrome, etc, to be any good in providing total security and accountability. The fact is that every single provider of a solution, be it public, open, closed, private, has an agenda. No matter the agenda, it leaves a portion of the population vulnerable who don't share that agenda. It always comes down to the almighty $$$ whether its Google aiming for global domination, or M$ aiming for monopoly and a dash of world domination, or Apple trying for the artsy, fartsy, cluless group distracted by shiny new things.

When it comes to OS, windows a necessary evil, apple is <I don't know how to politely say what I need, so I will leave it to your own imagination>, Linux is secure but quite limited in many ways whether us die hards want to admit it or not and will NEVER be publicly or mainstream adopted. When it comes to browsers IE <well I don't think I need to say it> fast, best decoding and function but not secure, Fx was the best alternative (not including Opera which you have to pay for, mostly worth it) but frankly has turned into a useless and broken tool because they tried to compete with the new guys and ended up killing the baby in the process, Chrome/Chromium novel idea for cloud based and internet consumers focused on extending Google's reach, succeeded but frankly sucks in many ways and will continue to do so as long as Google's agenda is in the forefront. Security that is sandbox or AV based is reactionary and useless because it works on heuristics and even when it tries to grow a brain and "detect" new ones, it is often a false positive. Third party tools like Java, Flash, Silverlight, are just horrible things that the web adopted and was better for it BEFORE them, but now has to suffer because of them. No programming language is perfect short of writing assembly, the more object oriented, library, api based, the more holes for things to go wrong. More functional and creative but less secure, something to be said about the obsolete cobol, fortran, pascal days of structured programming, at least they did what they did and did it tirelessly, but losing traction in today's world.

If you are a windows user, I recommend tightening your registry, your environment variables, security and policy and hope for the best. For a browser, use Comodo Dragon, a better, more security conscious version of Chrome/Chromium that has built-in functions that should be in Chrome too but would hinder Google's agenda, so it isn't. Not the best, but if your Fx on its way to hell is taking you with it and NS is having a hard time making up for its shortcomings, and are a novice user, Dragon is a good alternative. Now if you can handle Linux, go for it, and use Lynx (yes I said that, its text based and for today's consumer web useless, but it does the job if you want to avoid getting screwed). But no matter what, no solution is perfect, you just have to make the best judgement based on what works for you and that's it. All the reviews, take them with a grain of salt and do your own research and use your own judgement, no one will take responsibility for your security like you would. If you don't know better and do put your faith in someone, then be prepared to be disappointed in some way or another, as it WILL happen. Just life and the reality of it is that control is an illusion, we have none. All we can do is the best we can to mitigate it and there is no consensus on that, obviously. <end my two cents/soapbox>

[Tom T.]

Agree with the overall outlook, my friend, but just a couple of comments.

... Fx was the best alternative (not including Opera which you have to pay for, mostly worth it) but frankly has turned into a useless and broken tool because they tried to compete with the new guys and ended up killing the baby in the process,

Couldn't agree more. Which is why I stuck with F2 for as long as possible, and why i continue to stick with F3 for as long as they will support it. With F4+ , they went crazy on a lot of thing. Simple example: In F2 or F3, Tools > Add-ons, a small box, 462x520 pixels in my case, with all of your add-ons, the options and enable/disable buttons, and a "Find Updates"button. Clear and intuitive. With the new F4+GUI, it opens an entire freaking *page*, with a bunch of useless or distracting garbage, no "Find Updates" button that I can see.... Also, bookmarking in F2 was fast and easy. F3, more complex, with a smaller dialog box but more choices. F4+, use the gold star, balloon-pops, navigate through a confusingly-labeled menu, and organizing is even worse.

MZ still warns "F3 will be supported for only a short time. Please update to the latest blah blah." I think that started with the final release of F4 on 22 March 2011. Yet they're still supporting F3.6.x eight months later (and still displaying the same "warning"). This tells me that too many users are refusing the bells and whistles of the new versions. Note that the same happened with Windows XP. When Vista flopped, they had to extend support for XP, and here it is still going strong ten years after release., the longest in MS history, including DOS. And they will support it through 2014. The lesson here is tried-and-tested. Yes, it was Swiss cheese on first release, but now, one hardly sees critical updates to the core OS (as opposed to IE, Office, etc.) Note how many UAs of users here display the NT 5.1, not just mine.

So I think if MZ wants to keep market share, they should keep this workhorse F3 running; then they can play around all they like with trying to catch the snazzy-jazzy crowd.

Security that is sandbox or AV based is reactionary and useless because it works on heuristics and even when it tries to grow a brain and "detect" new ones, it is often a false positive.

Sorry, Brother, I have to disagree with you. Sandboxing and AV are two entirely different categories of product. Your comments about reactive vs. proactive, hueueristics, etc. apply to AV, definitely. (Still better to have it than not. A lot of old viruses and worms are still floating around out there.)

A sandbox, OTOH, does not in any way vet the material put into it. It merely prevents any of it from writing to the HD, so that any malware that is picked up is dumped when you exit and close. The malware doesn't get to reside permanently on the HD. Nor does goodware, or bookmarks, etc. Which is why some very judicious and carefully limited holes need to be punched in it if you want the convenience of being able to add bookmarks, change NS permissions and settings, etc. while running sandboxed. Of course nothing is perfect, and there will be flaws in any such product from time to time. Still, it adds another layer of protection that is very strong if produced and configured correctly. So again, you are better off with it (or with a full VM) than without it.

Just wanted to clear up the difference between AV and SB. No sandbox that I'm aware of uses heuristics, signatures, etc. It blocks it all from the HD, unless specifically told to allow it. [/soapbox]

[GµårÐïåñ]

Sorry, Brother, I have to disagree with you. Sandboxing and AV are two entirely different categories of product. Your comments about reactive vs. proactive, hueueristics, etc. apply to AV, definitely. (Still better to have it than not. A lot of old viruses and worms are still floating around out there.)

No, in my rush I didn't clarify and put them together and that was my fault. You are right, the heuristics refers to the AV and some is better than nothing but not a substitute for common sense. As with Sandbox, it doesn't magically keep the data away from the system, all it does is ensure that unlike the usual writing of data to the disk which could land on any sector, the data in sanbox is forced to be linear in a cluster of sectors that it will record and remember and then when you close the sandbox, it low level deletes those sectors, hence the illusion that its keeping it separate. It uses Direct Disk Access similar to Direct Memory Access. But in fact some vector of "evil" can indeed cross the barrier of "sandbox" and go into the main system as they are on the same drive and execution of them will allow them to bypass sector isolation by going into the MFT or the boot sector allowing them to virtually morph anywhere when the system is initialized again. But yes, they are better than nothing, at least there is some isolation but its no different than what an AV quarantine does.

[Tom T.]

.... As with Sandbox, it doesn't magically keep the data away from the system, all it does is ensure that unlike the usual writing of data to the disk which could land on any sector, the data in sanbox is forced to be linear in a cluster of sectors that it will record and remember and then when you close the sandbox, it low level deletes those sectors, hence the illusion that its keeping it separate. ... But in fact some vector of "evil" can indeed cross the barrier of "sandbox" and go into the main system as they are on the same drive and execution of them will allow them to bypass sector isolation by going into the MFT or the boot sector allowing them to virtually morph anywhere when the system is initialized again. But yes, they are better than nothing, at least there is some isolation but its no different than what an AV quarantine does.

Hmm... I could very well be mistaken, but my recollection when I first began using SB was that there was no writing to disk *at all*, and that the sandbox was created in memory only -- with the entire HD being read-only to programs, processes, etc. inside the sandboxed block. In fact, I just now visited the home page, and the explanatory diagram looks different from what I remember from four years ago. Are you aware of any changes over time in the method and place of storing the sandbox?

The dev now admits that flaws are found on the average of once every few months. Perhaps more people have tried to attack it, or perhaps it's just a matter of more time elapsing. It seemed that he thought that the previous method was reasonably bullet-proof against anything except user error.

Also, it seems that sandboxed data may reside in the pagefile alongside non-sandboxed data, a possible leak area. I don't use a pagefile, so not an issue for me.

Again, my memory from 2007 may not be spot-on. But anything that can get to the boot sector..

Sandboxie also prevents programs executing inside the sandbox from loading drivers directly. It also prevents programs from asking a central system component, known as the Service Control Manager, to load drivers on their behalf. In this way, drivers, and more importantly, rootkits, cannot be installed by a sandboxed program.

Pretty strong statement. Difficult to know without someone doing exhaustive pen-testing.

I know in my own experience, I've managed to avoid infections, by defense-in-depth and of course the vital common sense, as you said. But many people I know, some quite intelligent, and at least one experienced sw programmer, have picked up infections here and there. So perhaps proper use of a properly-configured sandbox is a part of that.

[Hungry Man]

Just to note the Dragon browser adds very little in terms of security - purely SSL, which is of course Comodo's strongpoint as the #2 cert provider. And then it does some other things by default that are easily configurable in Chrome/ium (block 3rd party cookies.)

@Tom

Without that, you can't save bookmarks, cookie permissions, etc. You'd have to shut the browser, open a non-SB browser, and make those changes manually. PITA. Of course, when you go running around with a drill, you have to be careful where you drill.

Yep. That's kind the problem.

Sandboxes are basically MAC based security, they have rules and no one gets around them. But then suddenly the user's allowed to poke holes and we get a much weaker structure that requires time to fine-tune.

I personally like Sandboxie a lot but it is not ideal - or rather practical. I pretty much believe in a practical security approach above all else.

Guess you should uninstall NoScript immediately, as Giorgio is solely responsible for the released product (though he may get a bit of behind-the-scenes help here and there, but nothing compared to the entire program.) Let's all wish him health and long life.

There's a big difference between Sandboxie and NoScript (and I don't use NoSCript.)

NoScript is open source. Sandboxie isn't. So if you even have a single dev on an opensource project anyone can say "Hey, here's a bug." Sandboxie does not have that luxury, bugs have to be found by using the program. Sandboxie is also written in C/++, which is of course pretty vulnerable as a language.

But yeah I personally don't like relying on any security that's handled by a single developer. I don't think anything is inherently wrong with that dev but there's just no way for any project of significant complexity to be manageable by one person.

It's an *additional layer* of security. If you are not familiar with the concept of "Defense in Depth", please read up on it.

lol I am very familiar with layered security.

@GµårÐïåñ

it low level deletes those sectors, hence the illusion that its keeping it separate. It uses Direct Disk Access similar to Direct Memory Access.

In this case you're talking about Sandboxie I assume. But something like SELinux or Chrome doesn't work like this, it's just MAC ie: restrictions on the flow of information.

Hmm... I could very well be mistaken, but my recollection when I first began using SB was that there was no writing to disk *at all*, and that the sandbox was created in memory only -- with the entire HD being read-only to programs, processes, etc. inside the sandboxed block. In fact, I just now visited the home page, and the explanatory diagram looks different from what I remember from four years ago. Are you aware of any changes over time in the method and place of storing the sandbox?

In Sandboxie if I write to a file it reads that file first, copies it to the sandbox, and writes to the file within the sandbox. Everything in that sandbox is still on the HDD and guardian explains that better than I can.

But, yeah, it's still on the HDD.

The dev now admits that flaws are found on the average of once every few months. Perhaps more people have tried to attack it, or perhaps it's just a matter of more time elapsing. It seemed that he thought that the previous method was reasonably bullet-proof against anything except user error.

It's hardly bullet proof. It's wonderful though. The only limitations/ vulnerabilities are really do to Windows' own limitations.

Also, it seems that sandboxed data may reside in the pagefile alongside non-sandboxed data, a possible leak area. I don't use a pagefile, so not an issue for me.

This is more of a privacy issue. You can't execute a pagefile or maybe there's some way to have it swap into memory that I don't know about using the page.

I think one of the issues inherent to a conversation like this is the term "sandbox" which means one thing for chrome and another thing entirely for sandboxie. Sandboxes are just sets of rules that act as restrictions in some way or another. It's vague as hell. I can tell Word not to read from my windows\system32\* and that's a sandbox right there. Chrome works by allowing only reads and writes to specific places. Sandboxie works by allowing reads to the entire system but restricting writes to the virtualized environment, which is created via the addition of a new application layer environment and using kernel hooks to incercept calls made from within that environment.

[GµårÐïåñ]

Hmm... I could very well be mistaken, but my recollection when I first began using SB was that there was no writing to disk *at all*, and that the sandbox was created in memory only -- with the entire HD being read-only to programs, processes, etc. inside the sandboxed block. In fact, I just now visited the home page, and the explanatory diagram looks different from what I remember from four years ago. Are you aware of any changes over time in the method and place of storing the sandbox?

Is not a mistake so much as it is a presumption that is actually not in practice true. Just look at the animation on the front page of Sandboxie and you'll see what I mean: http://www.sandboxie.com/img/FrontPage/ ... mation.gif

The dev now admits that flaws are found on the average of once every few months. Perhaps more people have tried to attack it, or perhaps it's just a matter of more time elapsing. It seemed that he thought that the previous method was reasonably bullet-proof against anything except user error.

Also, it seems that sandboxed data may reside in the pagefile alongside non-sandboxed data, a possible leak area. I don't use a pagefile, so not an issue for me.

Correct and actually I have been in touch with the developer working on many issues that have arisen over time (since i use it too for things here and there) and he has actually been pretty open to critique which is a good sign of a good developer. I have had nothing but a good experience dealing with him when reporting issues to him and usually he is pretty good at getting at it. We also go off grid (not on the support forum) for issues that could be exploited and its been a while since we have talked but a few months ago an issue came up and AFAIK it was dealt with.

Again, my memory from 2007 may not be spot-on. But anything that can get to the boot sector..

Sandboxie also prevents programs executing inside the sandbox from loading drivers directly. It also prevents programs from asking a central system component, known as the Service Control Manager, to load drivers on their behalf. In this way, drivers, and more importantly, rootkits, cannot be installed by a sandboxed program.

Pretty strong statement. Difficult to know without someone doing exhaustive pen-testing.

Correct in theory. However, say you are using an application that has a payload of SetACL (a nasty bugger that is used professionally all the time but in the wrong hands can be a nightmare, hence why the documentation on it is pretty thin) can easily manipulate the Registry, FAT tables, boot sectors, DMA and it is because sandboxed or not, it ALLOWS the program to run and a payload designed to access places you normally wouldn't allow, wouldn't be restricted by the sector isolation of the executable once in memory. Specially low level system memory.

I know in my own experience, I've managed to avoid infections, by defense-in-depth and of course the vital common sense, as you said. But many people I know, some quite intelligent, and at least one experienced sw programmer, have picked up infections here and there. So perhaps proper use of a properly-configured sandbox is a part of that.

For 99% of the run of the mill malware, its excellent. But someone of say Giorgio's caliber hacker and humbly myself in my glory days, it would not take much find a way through the restrictions, as its still data and if you can manipulate its execution, where, how, when, you can bypass anything, including AV software. Did a POC about a year or so ago for Comodo proving to them how their Defense+ and AV and Sandbox CANNOT intercept a cleverly hidden boot time payload. They finally after arguing with me for weeks when saw it in action, quitely conceded and terminated discussions and to the best of my knowledge never warned or did anything differently for the public to be aware of this. Although I admit, I have not read the lengthy fine print they have, they might have buried the warning somewhere in there.

[GµårÐïåñ]

Just to note the Dragon browser adds very little in terms of security - purely SSL, which is of course Comodo's strongpoint as the #2 cert provider. And then it does some other things by default that are easily configurable in Chrome/ium (block 3rd party cookies.)

Yes and No. I agree with you that in whole its not that different. However, it does have features by default that frankly baffles me that Chrome doesn't. To see what I mean, install them side by side and compare the config page. A couple that stand out the most are as follows but certainly not comprehensive. Start incognito by default in Dragon, not in Chrome (have to use CLI), discarding the cache/cookies by default in Dragon, not in Chrome (you can manually delete them). A few other more subtle stuff in the GUTS of the code before compile with/without GUI. By no means do I think its more secure because of Comodo security, in fact that part bugs me, but no more than Fx relying on Google malware domain list to make its decisions. Both are flawed in that sense.

Sandboxes are basically MAC based security, they have rules and no one gets around them. But then suddenly the user's allowed to poke holes and we get a much weaker structure that requires time to fine-tune.

Agreed. But its not always the user poking holes, the browser or the sandbox software does that too by default in many cases to make it more "user friendly". I think common sense and best practice trumps any "do it for you" or "set it and forget it" approach. I have always been an advocate of proactive security, why I object to any list based security like ABP subscriptions. Security is not one size fits all, it would be naive to think it is. Now the whitelist, manually added, user based decisions, although not ideal depending on who your user is, like NS I have no issue with. It gives me control over what to allow and if I pooch it, then its on me.

NoScript is open source. Sandboxie isn't. So if you even have a single dev on an opensource project anyone can say "Hey, here's a bug." Sandboxie does not have that luxury, bugs have to be found by using the program. Sandboxie is also written in C/++, which is of course pretty vulnerable as a language.

I have to disagree to some degree with your assessment, although I know the principle of "hit by bus" that makes it less than ideal. Too many cooks in the kitchen is not an improvement always, in fact it could be detrimental, I give you Fx as an example. NS is open to review which is good and it has one person who is dedicated that makes sure its always on the leading edge. I admire that and frankly feel that Giorgio doesn't get the credit he deserves on how much of himself he invests into this project. Its easy to snub it not knowing more about it, but everyone is entitled to their views, and I will respect yours as just that. The language used, agreed and already touched on that, so I won't repeat it.

@GµårÐïåñ

it low level deletes those sectors, hence the illusion that its keeping it separate. It uses Direct Disk Access similar to Direct Memory Access.

In this case you're talking about Sandboxie I assume. But something like SELinux or Chrome doesn't work like this, it's just MAC ie: restrictions on the flow of information.

Yes I was. However, Chrome is not as perfect as you think in the true sense of MAC, if it was, a cookie/data set by one tab wouldn't be accessible by another, so there are holes, just not as blatantly obvious. The fact that it has Flash built in and LSO can be shared across various "protected threads" should be a giveaway. Hence my object to pretty much all third party addons like Flash, Java, Silverlight, and even PDF to an extent, it allows their own vulnerabilities to come in and become part of the system. Sometimes introducing a hole, sometimes just making it bigger and sometimes just exposing it.

Also, it seems that sandboxed data may reside in the pagefile alongside non-sandboxed data, a possible leak area. I don't use a pagefile, so not an issue for me.

This is more of a privacy issue. You can't execute a pagefile or maybe there's some way to have it swap into memory that I don't know about using the page.

Using the less known and less discussed hidden streams in windows since Windows 2000, a malicious software can indeed dip into the pagefile and execute although unlikely given that you need to have somehow known or recorded the start/finish bits. I have written security software that has relied heavily on this thinly documented feature allowing you to hide things on your system in plain sight and with the handy built-in self destruct when someone tries to "extract" data from your drive common in forensics, which obliterates the stream given that you didn't know it was there to account for it. I won't go too much into that, Military implications, but just say it can be done.

Didn't mean to get involved in this conversation which seemed mostly directly at Tom but I wanted to clarify the parts that I posted and was involved with. Cheers.

[Hungry Man]

Yes and No. I agree with you that in whole its not that different. However, it does have features by default that frankly baffles me that Chrome doesn't. To see what I mean, install them side by side and compare the config page. A couple that stand out the most are as follows but certainly not comprehensive. Start incognito by default in Dragon, not in Chrome (have to use CLI), discarding the cache/cookies by default in Dragon, not in Chrome (you can manually delete them). A few other more subtle stuff in the GUTS of the code before compile with/without GUI. By no means do I think its more secure because of Comodo security, in fact that part bugs me, but no more than Fx relying on Google malware domain list to make its decisions. Both are flawed in that sense.

You can clear out your cookies after each session (or just block altogether) and yeah, as you said you need command line/flag to "always incognito" (or just right click and run as incognito.) I guess those can be considered security issues but they seem minor to me. Comodo really markets it like it's some amazing new thing but I think we can agree that deep down they're very similar.

Agreed. But its not always the user poking holes, the browser or the sandbox software does that too by default in many cases to make it more "user friendly".

That's how MAC works. If you don't poke some holes nothing will work =p

I think common sense and best practice trumps any "do it for you" or "set it and forget it" approach. I have always been an advocate of proactive security, why I object to any list based security like ABP subscriptions. Security is not one size fits all, it would be naive to think it is. Now the whitelist, manually added, user based decisions, although not ideal depending on who your user is, like NS I have no issue with. It gives me control over what to allow and if I pooch it, then its on me.

Well I don't think there's any single solution but I do definitely believe in "set it and forget it" approaches. In fact I think a proper security model necessitates a silent system.

I have to disagree to some degree with your assessment, although I know the principle of "hit by bus" that makes it less than ideal. Too many cooks in the kitchen is not an improvement always, in fact it could be detrimental, I give you Fx as an example. NS is open to review which is good and it has one person who is dedicated that makes sure its always on the leading edge. I admire that and frankly feel that Giorgio doesn't get the credit he deserves on how much of himself he invests into this project. Its easy to snub it not knowing more about it, but everyone is entitled to their views, and I will respect yours as just that. The language used, agreed and already touched on that, so I won't repeat it.

I definitely agree that you can have too many hands all grabbing at the code but I don't believe you can have too many eyes, which is why even though NS has a single dev it can stay fairly up to date on exploit management because it's open source. In a project like Sandboxie (large, critical to security, patches kernel, written in c/++) you either need a dedicated team for patch management or you need to stay open source.

Yes I was. However, Chrome is not as perfect as you think in the true sense of MAC, if it was, a cookie/data set by one tab wouldn't be accessible by another, so there are holes, just not as blatantly obvious. The fact that it has Flash built in and LSO can be shared across various "protected threads" should be a giveaway. Hence my object to pretty much all third party addons like Flash, Java, Silverlight, and even PDF to an extent, it allows their own vulnerabilities to come in and become part of the system. Sometimes introducing a hole, sometimes just making it bigger and sometimes just exposing it.

Oh definitely. There are holes. I don't know of any functional user system with a MAC model that doesn't have holes that's currently available - though I have seen some itneresting projects.

I don't think that saying "Chrome introduces attack surface via Flash and PDF" is valid in the sense taht those are almost always on the computer anyway in another program. And Java/Silverlight are plugins that go with any browser. I mean, of course, they all increase the attack surface but the attack surface is there one way or another.

Using the less known and less discussed hidden streams in windows since Windows 2000, a malicious software can indeed dip into the pagefile and execute although unlikely given that you need to have somehow known or recorded the start/finish bits. I have written security software that has relied heavily on this thinly documented feature allowing you to hide things on your system in plain sight and with the handy built-in self destruct when someone tries to "extract" data from your drive common in forensics, which obliterates the stream given that you didn't know it was there to account for it. I won't go too much into that, Military implications, but just say it can be done.

Interesting. I would think w^x or something could stop that. Good to know.

And don't worry about getting in on the convo, Tom and I wanted it as public as possible so that users could join in.

[Tom T.]

@ Hungry Man and GµårÐïåñ:

I was referring to the Sandboxie home page of 2007. A quick search could not locate a cached copy. Yes, I see how it works *today*, but I had a different recollection from the last time I looked at his page four years ago. I could be mistaken.

Agree about the Bus Factor, and the fact that NS is OSS means that if anyone were actually capable of filling Giorgio Maone's shoes (and with equal dedication and zeal), then the project could go on -- maybe.
Still, alla tua salute, Signore Maone!

Also agree that OSS can subject code to many more eyes. It isn't perfect, but at least it's possible to do so.

Comodo was breached by a hacker who issued fradulent SSL certs in Comodo's name. So they should clean up their own house first. They did fix this one quickly, but It makes one less willing to trust them completely, or at least, it's a credibility hit. Did everyone forget this?

An attacker, identified at an IP address originating from Iran, was able to use the stolen account credentials to fraudulently authenticate their IP address and impersonate certain websites and domain servers, including a SSL certificate for an add-on update server for Mozilla Firefox. ....

In a statement issued by Trustwave, which also is in the business of issuing SSL certificates, Trzupek said having control of the Mozilla Firefox add-on update server could have allowed the attacker to inject any arbitrary code they desire into the Web browser, in a trusted manner, enabling the attacker to upload malware onto a victim's machine without their knowledge.

Let's note that Comodo isn't OSS.

Sandboxes are just sets of rules that act as restrictions in some way or another. It's vague as hell. I can tell Word not to read from my windows\system32\* and that's a sandbox right there.

I'd call that just a permissions restriction. Is UAC a sandbox? This is just semantics, really, but I think of a sandbox as a clearly-defined space, virtual or physical, in which certain specified apps, processes, etc., can be forced to run, and with their privileges drastically reduced or even eliminated in bulk. E. g., no write permissions outside the sandbox.

btw, did you mean "write"? I don't use Word (Open Office is free, better, OSS, and safer, but that's just MHO; YMMV), but IIRC, Word has to call some dlls etc. from \system32\.

And don't worry about getting in on the convo, Tom and I wanted it as public as possible so that users could join in.

A-B-S-O-L-U-T-E-L-Y! .. and especially from my very knowledgeable and experienced friend GµårÐïåñ. Of course, all others with something to contribute are equally welcome. The more eyes and minds...

[Hungry Man]

Comodo was breached by a hacker who issued fradulent SSL certs in Comodo's name. So they should clean up their own house first. They did fix this one quickly, but It makes one less willing to trust them completely, or at least, it's a credibility hit. Did everyone forget this?

VeriSign and Comodo are pretty much the two top CA's. Even VeriSign, which holds a ridiculous amount of marketshare and in a lot of ways sets the standard has screwed up.

I think the CA system is beyond the scope of this particular discussion though.

I'd call that just a permissions restriction. Is UAC a sandbox? This is just semantics, really, but I think of a sandbox as a clearly-defined space, virtual or physical, in which certain specified apps, processes, etc., can be forced to run, and with their privileges drastically reduced or even eliminated in bulk. E. g., no write permissions outside the sandbox.

UAC is not a sandbox, it's a mechanism for moving between Mandatory Integrity Access Control, which is a sandbox.

http://en.wikipedia.org/wiki/Sandbox_(c ... _security)
As you can see there are loads of different types of sandboxes, such as the Jail:

A jail is a set of resource limits imposed on programs by the operating system kernel. It can include I/O bandwidth caps, disk quotas, network access restrictions and a restricted filesystem namespace.

or rule based execution or capability based. Essentially, restrictions.

btw, did you mean "write"? I don't use Word (Open Office is free, better, OSS, and safer, but that's just MHO; YMMV), but IIRC, Word has to call some dlls etc. from \system32\.

I meant Word. I was giving an example of a sandbox ie: If I restrict Word from writing to a certain folder I've just sandboxed it. It might not be a great sandbox, but it is.

[Tom T.]

I think the CA system is beyond the scope of this particular discussion though.

Agreed. It's not the CA system, it's that *Comodo itself* was breached by a hacker in a foreign country who was able to log in as a privileged Comodo exec with the authority to issue certs. That's not confidence-inspiring, especially for a company in the business of firewalls and overall security.

Re: definition of "sandbox": As said, the definition of sandbox was mostly semantics. Different people give it different names, or attribute different qualities to a sandbox. Since you and I both use SB, I was using their definition. Not a significant issue.

btw, did you mean "write"? I don't use Word (Open Office is free, better, OSS, and safer, but that's just MHO; YMMV), but IIRC, Word has to call some dlls etc. from \system32\.

I meant Word. I was giving an example of a sandbox ie: If I restrict Word from writing to a certain folder I've just sandboxed it. It might not be a great sandbox, but it is.

Here is your original quote, emphasized:

Sandboxes are just sets of rules that act as restrictions in some way or another. It's vague as hell. I can tell Word not to read from my windows\system32\* and that's a sandbox right there.

I wasn't referring to the write.exe program. (nice to meet someone who remembers that!) I knew you meant MS Word. But I think you typo'd by saying you could tell Word not to READ from s32, where probably you meant, tell it not to WRITE to s32. Which is why I said i thought that Word *must* have READ permissions to s32, as some of the libraries it calls are in s32. Clearer?