Sandboxie: Can it protect from potential malicious programs?

Cobalt2112

[H]ard|Gawd
Joined
Jun 25, 2002
Messages
1,177
Hi Guys,

Would Sandboxie protect me from lets say a dropper or trojan type program, if I were to execute it?

Just like running questionable software in a VM for protection, can Sandboxie provide similar protection?

The Sandboxie website leans a bit to web surfing and possible nasties that can be obtained by surfing to questionable sites. But how good is it if for example I run a keygen or "crack" which may have a byproduct of dropping an unwanted .exe in the reg "run" key or maybe even worse replace a system file with it's own evil offspring.
 
Here's my opinion on third-party sandboxes.

UAC is integrated tightly into Windows, as you know. To-date, nothing has bypassed it.
Internet Explorer is tied right into this, too.

Sandboxie is third party software that runs inside of Windows. Thus, said software could become infected itself... All that it has to do is exploit some flaw in Sandboxie to gain entrance into Windows.

Contrast: UAC requires user intervention on everything.
 
So, you're saying that running in a non-admin state would make me "safe" from let's say a virus/malware inside a keygen or malicious site that does drive by infections? As long as I dont say "Yes/Allow" to the UAC dialog if it comes up.. which would lead me to believe that this nasty is trying to write/drop something where it shouldn't.

Would that idea also not mean that the end of antivirus is upon us for when the mass market moves past the XP O/S?
 
So, you're saying that running in a non-admin state would make me "safe" from let's say a virus/malware inside a keygen or malicious site that does drive by infections? As long as I dont say "Yes/Allow" to the UAC dialog if it comes up.. which would lead me to believe that this nasty is trying to write/drop something where it shouldn't.
Running as a user is always recommended.

It'll never make you 100% safe. While the chances are next to nothing, in reality, a malware residing out on the web somewhere could exploit a hole in SandProxie and gain entrance into Windows anyway.

That's my point. Whereas UAC, which is integrated with Windows, won't allow anything past it AT ALL without your consent.
Would that idea also not mean that the end of antivirus is upon us for when the mass market moves past the XP O/S?
UAC is not and never will be anti-virus.
Its main purpose is to keep your system running. Your user-level profile could still easily get infected, even without UAC. The difference is that UAC won't let it spread across the whole system.
 

I bow at your feet for linking me to a Google search page. :rolleyes:

Please link me to something in which UAC was actually disabled by malware.

The key here is no user intervention. Obviously if I'm Average Joe, and I tell it to Continue, there's nothing Windows can do to protect itself.
Why do you think Microsoft dismissed it as saying it's working as designed? It's because there's really nothing new. If a user allows shit to run, it's their own damned fault. No amount of software can protect them from that.
 
OK, so I guess that for "experimentation" purposes, I'll keep to VMWARE with no client VM NIC. I simply drag-n-drop what I want to test into it, and I hope as heck hope it doesnt jump from the client VM to the HOST.
 
I bow at your feet for linking me to a Google search page. :rolleyes:

Please link me to something in which UAC was actually disabled by malware.

The key here is no user intervention. Obviously if I'm Average Joe, and I tell it to Continue, there's nothing Windows can do to protect itself.
Why do you think Microsoft dismissed it as saying it's working as designed? It's because there's really nothing new. If a user allows shit to run, it's their own damned fault. No amount of software can protect them from that.


I agree that no amount of technical tricks can keep a user from doing stupid things himself. However, there are flaws with Win7's implementation of UAC that allow arbitrary apps to run with elevated privileges or disable UAC without notice. The old Vista implementation does still warn about it, but it has the downside of producing a lot of UAC prompts, desensitizing the user so they end up just clicking on anything to make it go away.

http://blogs.zdnet.com/igeneration/?p=1826
In Windows 7, the settings have changed for UAC, allowing the system to be more malleable and flexible for users. Certain applications which are digitally signed are fast-tracked through UAC by default to reduce the unnecessary user interaction. The vulnerability shows itself when this third-party application calls on malicious code “by proxy” through an existing Windows application, which never invokes the UAC prompt.

To put it simply, through application piggybacking, it allows malware to be automatically elevated to administrator user status which in turn allows it full, unrestricted access to the computer and global settings.
This sounds very similar to the old issues with malicious apps bypassing firewalls by proxying requests through IE.


http://www.pcworld.com/businesscent...r_windows_7_uac_feature_still_vulnerable.html
A change to UAC is seen as a change to a Windows setting, so a user will not be notified if UAC is disabled, which Zheng said he was able to do remotely with some keyboard shortcuts and code.


Even if it's not perfect, any extra security is good. However, believing that your software is infallible sets you up for huge problems. "I can run anything without worry, because I have antivirus!" (Until your DATs don't get updated right away and something new sneaks in.) "I don't need to worry about what a program does, because UAC will stop anything bad!" (Until rundll32 is used to silently elevate the app's privileges.)
 
I agree that no amount of technical tricks can keep a user from doing stupid things himself. However, there are flaws with Win7's implementation of UAC that allow arbitrary apps to run with elevated privileges or disable UAC without notice. The old Vista implementation does still warn about it, but it has the downside of producing a lot of UAC prompts, desensitizing the user so they end up just clicking on anything to make it go away.

http://blogs.zdnet.com/igeneration/?p=1826

This is not a problem with UAC at all... In fact, anyone that supports UAC and realizes its purpose has been complaining about this.
This is why Windows 7's UAC setting, by default, needs to be 100% on. If it were 100% on, this wouldn't be an issue.

Of course you open yourself up to attacks. Anytime you create an exception: you open yourself up. That's why I'm a huge advocate for hoping Microsoft enables it 100% in UAC.

And FWIW, this is STILL not a vulnerability with UAC itself. It exploits a program which is already allowed through UAC via exception. That's all it does.
 
I've tried to get infected with Sandboxie (assuming you use it correctly) and have not. I use it all the time.
 
Sandboxie is great, my browser issues have been eliminated since I started using it a few years ago.
My torrent client is also run within the sandbox.
If ever there is a severe browser problem (maybe 3 times a year), I delete the Sandbox and am back to how it was set up originally, problem solved.
(I also delete the sandbox when I update my browser so it gets refreshed more often than 3 times a year)
Since using Sandboxie I have had a big drop in malware on my PC, as in I never get any now whereas my scans before would pretty much always pick something up.
Also my systems general stability has improved a lot and my Windows installs last a lot longer now (running XP :))

I agree that if Sandboxie requires elevated privileges to run that it becomes an attack vector.
I'm not seeing any issues with it here so far though, running XP with admin user.
I also use Comodo firewall (with some strict rules) and PeerGuardian 2, a damn good complement of live security tools overall.
 
There's nothing wrong with running Sandboxie for stuff in the user space. Just IMO the user-level can always be wiped clean if you have an issue... That's more for what an AV is for.
 
And FWIW, this is STILL not a vulnerability with UAC itself. It exploits a program which is already allowed through UAC via exception. That's all it does.

It's a vulnerability in Microsoft's implementation of UAC. It may not directly be a vulnerability due to bad code in the executable file that runs UAC, but it is a vulnerability in the whole "UAC system". By default, MS is whitelisting a program that can be used to run any arbitrary code.

It's like putting a 6' diameter pipe through the wall of your house and leaving it open and unmonitored because you know the pipe is safe. The reality is that regardless of how safe the pipe itself is, anyone and everyone can simply walk in through that pipe. Again not necessarily a vuln in the pipe directly, but the pipe system is creating a huge vuln in your house.


http://blogs.zdnet.com/security/?p=29 is another one. This one is specifically a Vista issue and well over two years old. Apparently if the fancy UAC engine detects something as a setup program, your only options are to run it with full admin privileges or not run it at all. To quote the hacker chick publicizing this, "Why should a Tetris installer be allowed to load kernel drivers?"

There are also a number of mentions of a low-rights process being able to monitor for higher-rights processes and inject code into them, due to the way the desktop is shared.


Again, I'm all for anything to help improve security. However, I would consider UAC a safety net to catch something I missed, rather than a complete defense against malicious programs.

Personally, I believe the best defense is still not doing dumb things. I'm using XP64, so I have no UAC. I've often run without AV. I generally install an anti-malware app about once a year to scan just in case. Despite frequenting seedier websites in the past, I have found viruses on my system exactly twice. In one case, I had a brainfart and double-clicked on a known-bad file instead of right-clicking on it. In the other, I put my hard drive in my friend's PC to copy some files, and his system had CIH on it (to give you an idea how long ago that incident was). None of my malware scans have ever turned up anything more than tracking cookies. As I don't have the source to all the code I run, I can't say with 100% certainty (just like everyone else) that I've never had malware. However, I've never run into indications of any malware (weird files, extra registry entries, poor performance, random traffic, etc.). I've had lots of experience cleaning lots of malware off others' PCs (most recently AntiVirus System Pro and Vundo from my parents'), so I consider myself knowledgeable as anyone else on the subject. I'm willing to say with 99.999% (or even a few more 9's in there) certainty that I've never had any virus or malware other than the two cases I listed above.
 
It's a vulnerability in Microsoft's implementation of UAC. It may not directly be a vulnerability due to bad code in the executable file that runs UAC, but it is a vulnerability in the whole "UAC system". By default, MS is whitelisting a program that can be used to run any arbitrary code.
Like I said: That's the problem with purposely creating holes. I'm not going to argue with you on that. That's why it needs to stay 100% ON in Windows 7. Make the user have to decrease their security, not increase it.

http://blogs.zdnet.com/security/?p=29 is another one. This one is specifically a Vista issue and well over two years old. Apparently if the fancy UAC engine detects something as a setup program, your only options are to run it with full admin privileges or not run it at all. To quote the hacker chick publicizing this, "Why should a Tetris installer be allowed to load kernel drivers?"
Runas is still there, just not on the GUI. It automatically assumes you want the Administrator account, because who uses Run As for other users? Administrators. Thus they didn't stick the GUI option on there for the common person. They even named it blatantly obvious: "Run As Administrator".

Alas, I guess enough people complained though. Run As is back in Windows 7.

So there's nothing wrong with "the engine" at all :rolleyes: All you're missing out on is the little GUI option in the context menu.

There are also a number of mentions of a low-rights process being able to monitor for higher-rights processes and inject code into them, due to the way the desktop is shared.
Link??? This is an issue with Windows 7's new decreased security mode, I am not aware of anything on Vista.

I would consider UAC a safety net to catch something I missed, rather than a complete defense against malicious programs.
Who ever said anything it was a complete defense?
The primary purpose of UAC is to enable users to not have to login to different accounts to do Administrative functions. A plus of that is it can protect the system space.
 
I'm just going on what I'm reading, as I don't have Vista to test this stuff myself (and don't intend to get it). I haven't bothered to reinstall VMware yet, so I don't have access to Win7 at the moment either.

Runas is still there, just not on the GUI. It automatically assumes you want the Administrator account, because who uses Run As for other users? Administrators. Thus they didn't stick the GUI option on there for the common person. They even named it blatantly obvious: "Run As Administrator".

Alas, I guess enough people complained though. Run As is back in Windows 7.

So there's nothing wrong with "the engine" at all :rolleyes: All you're missing out on is the little GUI option in the context menu.

Based on what I read, it sounded like the typical case of MS trying to be helpful and causing more problems. My understanding was that it would detect a setup program and give you only two options - administrator rights or cancel. You can't choose to run it as your current low-rights user, because MS only gives you the option to cancel it or to boost it to admin-level. The point is that a simple game installer that just needs to copy some files should be fine under your regular user account and should not need access to the kernel. However, MS knows better than you do what a setup program should have access to, so it's either all or nothing. This has nothing at all to do with RunAs, but rather UAC intercepting certain programs and giving them more rights than they need.


There are also a number of mentions of a low-rights process being able to monitor for higher-rights processes and inject code into them, due to the way the desktop is shared.
Link??? This is an issue with Windows 7's new decreased security mode, I am not aware of anything on Vista.
It's in that same article from 2-13-07, http://blogs.zdnet.com/security/?p=29. Here's a quote from Mark Russinovich:
Mark Russinovich said:
Even the ability of a process at low IL to manipulate objects of a higher IL isn’t necessarily prevented. Since processes running at different integrities are sharing the same desktop they share the same “session”. Each user logon results in a new session in which the processes of the user execute. The session also defines a local namespace through which the user’s processes can communicate via shared objects like synchronization objects and shared memory.

That means that a process with a low IL could create a shared memory object (called a section or memory-mapped file) that it knows a higher IL process will open, and store data in the memory that causes the elevated process to execute arbitrary code if the elevated process doesn’t properly validate the data.
This is a very sophisticated attack, but the point is that UAC doesn't completely separate the different access levels.


Who ever said anything it was a complete defense?

I was basing that on your previous statement:
While the chances are next to nothing, in reality, a malware residing out on the web somewhere could exploit a hole in SandProxie and gain entrance into Windows anyway.

That's my point. Whereas UAC, which is integrated with Windows, won't allow anything past it AT ALL without your consent.

We're talking about malware exploiting a bug in Sandproxie to actually get increased access (it wouldn't be the first time a bug in a security program actually reduced your security), and your statement made it sound as if UAC were completely immune to anything like this. However, a bug in UAC could allow admin access to an app running under a regular Vista user account, whereas a regular user in XP wouldn't be able to do this since UAC isn't present at all. Just like with Sandproxie, it is theoretically possible for a bug in UAC to actually allow more access to an app.


The primary purpose of UAC is to enable users to not have to login to different accounts to do Administrative functions. A plus of that is it can protect the system space.
The primary purpose of UAC is to enable users to not have to login to different accounts to do Administrative functions, so that they can run as regular users instead, which is supposed to keep any malware they do get from being able to do anything bad outside that user's space. The idea is that any attempted actions beyond the user's space will trigger a UAC prompt. You determine the shadiness of a program by whether or not it triggers a UAC prompt (i.e. no prompts means it's not trying to do anything to the system). But if UAC flaws allow apps running in a low-rights account to silently get admin rights via one of these issues, then you simply cannot rely on that UAC prompt. Rather than UAC not prompting for acceptable user-space actions and prompting for special admin actions, UAC is now sometimes prompting for some things.

I assume the worst, because things can only get better from there. I'm saying that if there is any doubt that UAC can catch all admin actions and trigger a prompt, then UAC cannot be considered a reliable defense. It must be considered only a secondary defense, and therefore you should treat all apps the same way regardless of whether or not the system has UAC. You should know ahead of time via your due diligence whether or not an app will trigger UAC. Unfortunately, the apps that are sophisticated enough to get around UAC are probably the ones most likely to be missed by manual inspection as well. Rather than layering your defenses so that a hole in one is covered by another, your holes line up and create a straight shot through.
 
I'm just going on what I'm reading
.
.
.
.
Based on what I read,
Honestly, after reading those two comments, reading anything more is a complete and total waste of time. You're arguing over something you are pulling knowledge from what "you've read"??? :rolleyes:
 
Honestly, after reading those two comments, reading anything more is a complete and total waste of time. You're arguing over something you are pulling knowledge from what "you've read"??? :rolleyes:

I was simply trying to be 100% transparent. If you can refute any of the the claims that I've researched but not personally verified, I'll gladly concede. Can you show that Vista's UAC does offer options for running heuristically-detected installers at a level other than full admin (contrary to Joanna Rutkowska's claim)? This should be very easy to test, and is quite likely to have changed in the past two years. Can you prove Mark Russinovich wrong and show that UAC does truly keep processes of different integrity levels completely separated from each other? Just because I don't currently have the tools necessary to verify their claims, doesn't instantly invalidate them (especially with their reputations).

I understand the concept of not believing everything you read on the intarwebs. However, this isn't some random guy's blog or my uncle Joe Bob's cousin's friend's brother "who's really good with computers." Mark Russinovich is one of the most knowledgeable people on earth regarding Windows. Rutkowska is a malware researcher with a history of breaking Vista's security. When you tell someone that video card A should be 10% faster than video card B in a certain game at a certain resolution, have you personally tested that scenario or are you just relying on [H]'s review showing those results?

I'll see about installing Vista on a work PC tomorrow (Yay for SA!) to verify their claims, so that we can get back to our debate.
 
Back
Top