Google Chrome Updating

[yabbadoo]

Sandboxie does not protect from Windows security holes. Example: Blaster worm would have infected your computer even if you were using Sandboxie.

Buster, intrigued, I would like to ask you direct how your worm can infect the PC when using Sandboxie.

As i see it, Sandboxie introduces a one way valve, where reversed flow is not possible :-
OS > Sandboxie > Browser > Internet.

As the OS has no connection with the Internet, only through a browser, how is it possible for your worm to crawl back through the virtual minefield of Sandboxie, unless there is something lacking in the operators configuration and security conscious ability ?

I cannot see it Buster, but no doubt you will explain this invertebrate cyborg Houdini act.

[Buster]

I meant the computer will be vulnerable even if you are using Sandboxie if there is a vulnerability in the OS. That means that your computer may be compromised independently if you are using Sandboxie or not.

[yabbadoo]

I meant the computer will be vulnerable even if you are using Sandboxie if there is a vulnerability in the OS. That means that your computer may be compromised independently if you are using Sandboxie or not.

If the OS is not connected to the Internet by a browser, how can an Internet threat possibly enter the system ? If for instance I had no Internet connection and only used my PC for word processing and offline activities etc., it is impossible for Internet bugs to come anywhere near me.

In such an offline usage situation, the OS can be shredded with holes, it does not matter. There is no external connection. The only bugs likely to infect my apparatus are the local spiders.

Likewise, no browser in use, no infections and with Sandboxie providing a virtual environment from the OS outwards, no bugs can escape the sandbox and infect the OS, no matter how many holes the OS has in it.

The only way your bugs can invade the OS when Sandboxie is being used, is if Sandboxie does use Windows security features and nobody yet has categorically stated that is the case.

Like I have already said, there is no reason whatsoever why an independent security program should remotely be associated with an OS security system. They are two separate and completely divorced concepts.

[Buster]

If the OS is not connected to the Internet by a browser, how can an Internet threat possibly enter the system ?

If you read about Blaster worm you will know how.

[yabbadoo]

Oh dear Buster, I have read enough about your Blaster worm to know that quoting that as an example of Sandboxie fallibility is ridiculus. You are stating an instance originating in 2003 concerning malpractice with MS Windows updates. Sandboxie is an Internet protection not protection against MS/Windows updates being externally hacked, updates that do not even go through Sandboxie, but are directly transmitted from MS to all their Windows sets.

So if MS gets hacked and infected with a worm which they then transmit to all their Windows users, why on Earth do you give that as an example of Sandboxie failure ? Why mention it at all ? It is utterly irrelevant, just a company being hacked like many other private and Government organisations, banks, credit card companies and even the Pentagon.

So let us forget your example in the context of Sandboxie. If this worm was wriggling around in the virtual world of Sandboxie, it would never get into our machines but be vaporized on browser closure with all the other bugs. Sandboxie cannot protect a PC from external threats beyond its control.

[Curt@invincea]

Sandboxie does not "rely" on Windows security. It "uses" many features of Windows security as part of its defenses. For example, running processes under the user account NT AUTHORITY\ANONYMOUS LOGON would be considered "using" Windows security. But that is just 1 way Sandboxie protects you. Features like redirecting file/registry writes into the sandbox are not part of Windows security.

I think when Buster says "OS vulnerabilities", he is referring to kernel exploits. There are examples of kernel exploits that no sandbox or user-mode protection app can protect against. Fortunately, these are rare. Sandboxie does protect against most every other kind of OS vulnerability.

Not all malware spreads exclusively over the Internet. Once a machine was infected, Blaster was spread over the network (no browser required). Stuxnet was spread via infected USB drives. Blaster was before Sandboxie, but these types of buffer overrun exploits typically will just crash under Sandboxie today. If they do run, they will not stick after the sandbox is deleted. The goal of Sandboxie is to prevent malware from infecting/harming your computer -- not to stop it from running. For example, CryptoLocker will run under Sandboxie, but it will not cause any damage to your system.

[Buster]

Oh dear Buster, I have read enough about your Blaster worm to know that quoting that as an example of Sandboxie fallibility is ridiculus.

I did not say Blaster worm infection would due Sandboxie fallibility. I said it was due Windows vulnerabilities.

Anyway we are talking about different issues so just forget my intervention.

[yabbadoo]

Thanks for that post Curt.

I would like to emphasize that Sandboxie is not a Hospital dealing with patients injured by a variety of external incidents. Sandboxie is purely an online defense against attack by Internet transmitted threats whilst on duty, it does not provide bandages for wounds already received.

I find it a little disturbing that Sandboxie "uses" certain Windows security features. We have already seen how MS were hacked and consequently infected all their computers with Blaster worm updates.

[DR_LaRRY_PEpPeR]

Sandboxie does not "rely" on Windows security. It "uses" many features of Windows security as part of its defenses.

I'd say "uses" IS "relies" on. Being able to use something is, in fact, relying on it...

Features like redirecting file/registry writes into the sandbox are not part of Windows security.

But the Windows permissions and security mechanisms are what prevent file/registry writes, and then Sandboxie does its thing by selectively allowing (enabling) stuff that's OK.

Contrast this, guys, to Sandboxie 3.x that, AFAIK, had to do everything [itself] to BLOCK stuff that wasn't allowed. Whereas now, it has Windows' own abilities take care of that, and then "re-enable" what it needs (the opposite of previous versions).

Those Windows mechanisms are so restrictive, in fact, that Sandboxie v4 needs more stuff, like the GuiProxy, to allow basic stuff to work again. Yet people still can't run some programs the way they could before, because the Windows restrictions are too severe, and Sandboxie hasn't (or possibly can't) made a way to enable or "proxy" what they need.

I think when Buster says "OS vulnerabilities", he is referring to kernel exploits. There are examples of kernel exploits that no sandbox or user-mode protection app can protect against. Fortunately, these are rare. Sandboxie does protect against most every other kind of OS vulnerability.

Yes, rare I guess. Although it seems like we have a couple of the kernel-mode font parsing exploits each year. Again, don't know how much of a problem those would be in Sandboxie though...

Same with Elevation of Privilege vulnerabilities, it's not clear to me. (BTW, these (EoP) need a corresponding initial exploit of some sort.) I mean, if something elevates to SYSTEM in the sandbox, that's fine (? is it?), and it's still sandboxed, right? So I'm not sure when or how something gaining SYSTEM privileges could/would be a problem in Sandboxie!



But yabbadoo (glad you like my writing ), ALL application/user-level exploits (most common in your sandboxed programs) will be fully contained by Sandboxie. Although IF there's an unpatched Elevation of Privilege bug in Windows that could ALSO be exploited, then I think it starts to become sketchy...


Also, your Internet connection examples: The OS always handles the low-level networking connection stuff, AFAIK. I mean if there was an exploit in Windows' networking (TCP/IP driver or such), I think it would affect Windows itself without Sandboxie being a factor, since that part doesn't happen IN Sandboxie. There was a vulnerability in newer Windows versions 1-2 years ago regarding reception of malicious UDP packets. Same type of example. (Err, maybe that was against the Firewall.)

Finally, last year, there were a couple Security Bulletins about USB driver vulnerabilities. Just connecting a malicious USB thumb drive, etc. exploits this. You (people) might think autorun (disable) or Force Folder external drive letters in Sandboxie, but that wouldn't help. Simply plugging in the drive is all in takes. Autorun isn't needed. And Sandboxie doesn't matter, since this is at the driver-level, before anything would even run in Sandboxie.

[yabbadoo]

@ Dr. Larry Peprer

Another masterpiece of logic and expertise eh ?

I am not in favor of systems piggy-backing on others. It makes reliance become dependent on the weakest link. For Sandboxie to use = to rely on Windows somewhat dicey security measures is distressing news after many years of regarding Sandboxie as being a unique and individual program.

Like I said earlier, Windows security is a joke. Nobody in their right mind would rely totally on being protected from all Internet related evils by Windows security. For XP users like myself, we have not had a MS security update since they assassinated XP in April 2014. So what Sandboxie/Windows reliance applies to us ? Sounds suspiciously like progressive depreciation.

I understand that the total probability of failure is the consecutive multiple summation of the number of individual probabilities, so if one component has a probability of zero, then failure becomes a certainty.

[Curt@invincea]

Sandboxie does not "rely" on Windows security. It "uses" many features of Windows security as part of its defenses.

I'd say "uses" IS "relies" on. Being able to use something is, in fact, relying on it...

Would you say a Boeing 747 uses, relies on, or requires all 4 engines? It can fly on 1 engine.

[Curt@invincea]

But the Windows permissions and security mechanisms are what prevent file/registry writes, and then Sandboxie does its thing by selectively allowing (enabling) stuff that's OK.

No, Sandboxie filters all file/registry writes. It does not use Windows security to perform this task at all.

Contrast this, guys, to Sandboxie 3.x that, AFAIK, had to do everything [itself] to BLOCK stuff that wasn't allowed. Whereas now, it has Windows' own abilities take care of that, and then "re-enable" what it needs (the opposite of previous versions).

Those Windows mechanisms are so restrictive, in fact, that Sandboxie v4 needs more stuff, like the GuiProxy, to allow basic stuff to work again. Yet people still can't run some programs the way they could before, because the Windows restrictions are too severe, and Sandboxie hasn't (or possibly can't) made a way to enable or "proxy" what they need.

Sbie v4 does not remove any blocking nor shift those tasks to Windows security from Sbie v3. Sbie v4 adds many new security features on top of v3. Example: integrity levels. Sandboxed processes now run at untrusted integrity. Should they be allowed to send messages to higher integrity applications? Answer: it depends. This might enable an application to function properly, or it might enable malware to damage the host system. So Sbie by default doesn't allow it. If this breaks your application, then you have to use the resource access monitor or something like ProcMon to figure out what is being blocked and what should be allowed.

[Buster]

Sbie v4 does not remove any blocking nor shift those tasks to Windows security from Sbie v3. Sbie v4 adds many new security features on top of v3. Example: integrity levels. Sandboxed processes now run at untrusted integrity. Should they be allowed to send messages to higher integrity applications? Answer: it depends. This might enable an application to function properly, or it might enable malware to damage the host system. So Sbie by default doesn't allow it. If this breaks your application, then you have to use the resource access monitor or something like ProcMon to figure out what is being blocked and what should be allowed.

I bet that without Patchguard technology Ronen would have not changed internal architecture as he did from v3 to v4.

Sbie v4 broke things that were working fine in v3 and in terms of security v4 was not a step further compared to v3 at least on first versions.

[yabbadoo]

Sandboxie does not "rely" on Windows security. It "uses" many features of Windows security as part of its defenses.

I'd say "uses" IS "relies" on. Being able to use something is, in fact, relying on it...

Would you say a Boeing 747 uses, relies on, or requires all 4 engines? It can fly on 1 engine.

Dear Curt,
Your following post is highly interesting and worthy of serious attention, but really, your poor analogy of the 747 and one engine is quite the opposite.

Of course a 747 uses, relies on and requires all 4 engines in order to achieve its designed performance, just like obviously Sandboxie uses, relies on and requires certain MS Windows security features in order to achieve its designed performance.

The 747 with only one engine is in a very serious, dangerous and precarious emergency situation, one which can barely maintain altitude, speed and level flight, where the skills of the crew become paramount, but sufficient dependent on distance and adequate fuel, to reach and hopefully safely land at the nearest airfield.

YES Curt, Dr. Peprer is 100% correct in what he has said - by design Sandboxie does need Windows security, just the same as by design the 747 does need all 4 engines.

[Curt@invincea]

Actually, I was not making an analogy. I was trying to point out that we are arguing over semantics. "rely" according to dictionary.com means "to depend on". That definition is highly subjective. All I am saying is that Sandboxie has many safeguards that have nothing to do with built-in Windows security. That's why you can run apps as admin, yet it still can't delete files outside the sandbox. If we "relied" on Windows security, then an admin can do anything he wants.