Author Topic: Avast! Sandbox and OA Run Safer  (Read 7293 times)

0 Members and 1 Guest are viewing this topic.

sded

  • Guest
Avast! Sandbox and OA Run Safer
« on: February 28, 2011, 06:56:14 PM »
Currently trying running my browser (Opera 9.01) with both Avast! 6 virtualization and OA Run Safer applied. Checked with Process Explorer and Avast! that both features are actually active. The border is red, BTW, but may actually depend on which is activated first.  Tried SB both with and without saving downloads and bookmarks and all seemed to work fine.  So can now run with both reduced privileges and the browser sandboxed for really bad sites ;) .

Offline schmidthouse

  • VIRUS FREE A Long Time
  • Avast Evangelist
  • Starting Graphoman
  • ***
  • Posts: 7170
  • When you think you know, Think Again
Re: Avast! Sandbox and OA Run Safer
« Reply #1 on: February 28, 2011, 08:05:21 PM »
Currently trying running my browser (Opera 9.01) with both Avast! 6 virtualization and OA Run Safer applied. Checked with Process Explorer and Avast! that both features are actually active. The border is red, BTW, but may actually depend on which is activated first.  Tried SB both with and without saving downloads and bookmarks and all seemed to work fine.  So can now run with both reduced privileges and the browser sandboxed for really bad sites ;) .

Hey sded: Good to see you have tested this. There is also this question posed in the Emsisoft support forum (Online Armor Category).
I have provided your thread for reference.
Thanks, ;)
« Last Edit: February 28, 2011, 08:07:38 PM by schmidthouse »

sded

  • Guest
Re: Avast! Sandbox and OA Run Safer
« Reply #2 on: February 28, 2011, 08:23:25 PM »
Great; maybe you can give it a try with XP?  I will try some more browsers in W7 but don't have an XP system-and total lack of UAC is a little different.  Maybe one of the malware wonks will be interested testing it?

Offline schmidthouse

  • VIRUS FREE A Long Time
  • Avast Evangelist
  • Starting Graphoman
  • ***
  • Posts: 7170
  • When you think you know, Think Again
Re: Avast! Sandbox and OA Run Safer
« Reply #3 on: February 28, 2011, 08:39:38 PM »
Great; maybe you can give it a try with XP?  I will try some more browsers in W7 but don't have an XP system-and total lack of UAC is a little different.  Maybe one of the malware wonks will be interested testing it?

Certainly, no worries.
I'll report back after testing. ;)

sded

  • Guest
Re: Avast! Sandbox and OA Run Safer
« Reply #4 on: February 28, 2011, 09:56:15 PM »
Works fine with Chrome also.  All of the .exes show run safer and sandbox both active.
UPDATE  FF and IE look good too  :)
« Last Edit: February 28, 2011, 11:06:52 PM by sded »

Offline schmidthouse

  • VIRUS FREE A Long Time
  • Avast Evangelist
  • Starting Graphoman
  • ***
  • Posts: 7170
  • When you think you know, Think Again
Re: Avast! Sandbox and OA Run Safer
« Reply #5 on: March 01, 2011, 01:21:15 AM »
Works fine with Chrome also.  All of the .exes show run safer and sandbox both active.
UPDATE  FF and IE look good too  :)

Yeh, all seems fine here, running with both active. Personally, I don't think that's necessary but personal choice. :)

SafeSurf

  • Guest
Re: Avast! Sandbox and OA Run Safer
« Reply #6 on: March 01, 2011, 09:54:29 AM »
@ sded,

No conflicts with PrevX w/SOL either?  Good to hear the other news.  :D 

sded

  • Guest
Re: Avast! Sandbox and OA Run Safer
« Reply #7 on: March 01, 2011, 02:41:25 PM »
No, Prevx SOL works fine with the combination.  There is at least no conflict, but haven't tried to sort out the added protection benefits of even SB and RS together.  RS will stop things you download from executing and installing from the browser (not enough privileges) and SB should allow them to operate in a controlled environment if you decide to execute them anyway.  Something for the malware experts to look at to see if the potential benefits are real and how they actually play together in a malware attack.

sded

  • Guest
Re: Avast! Sandbox and OA Run Safer
« Reply #8 on: March 02, 2011, 02:43:34 PM »
Unfortunately it looks like running the browser in the sandbox with Run Safer can actually interfere with the virtualization.  I downloaded a file with the "Save downloads to outside sandbox" not checked, and the file was saved outside the sandbox anyway.  So if you use Run Safer, might be better to run the browser outside the sandbox and then go to Explorer and click on "run in sandbox" for the downloaded file.  Don't know what other interference it might cause or if there are offsetting benefits of running them together.
« Last Edit: March 02, 2011, 03:53:18 PM by sded »

VanguardLH

  • Guest
Re: Avast! Sandbox and OA Run Safer
« Reply #9 on: March 02, 2011, 03:41:05 PM »
I've used Online Armor and its Run Safer feature.  If you use Windows XP, or later, you can use policies available in Windows to restrict privileges on Internet-facing applications (web browser, e-mail client, newsreader, IM client).

Use SRPs (Software Restriction Policies) to run, say, the web browser (any of them), under a limited account even if you log under an admin-level account.  After adding the Basic mode, add a Path rule that points at iexplore.exe and forces it to run under Basic mode.  Whether a parent or child process, iexplore.exe runs restricted.  Sometimes (e.g., Windows Updates site) you need full privileges on the web browser.  For that, create a subfolder with a copy of iexplore.exe.  The Path SRP rule only applies against the specified program, not this alternate copy.  Use a shortcut that loads the alternate copy so it run unrestricted.

Run Safer was a big reason why I used to use Online Armor.  Path SRPs and Basic mode reduced the need for OA.

--- Canned article ---

Security experts usually recommend that users log into a limited user account (LUA) to more securely surf the web.  When logged under a LUA, privileges are reduced on the web browser and severely curtails the damage that malware can perform when the web browser is the infection vector into your computer.  Under a limited account, the user cannot install software.  This all sounds nice except that users often need the privileges of an admin-level account to run their applications, plus they cannot install updates to Windows when using the web browser to visit the Windows Update site (after all, the web browser has limited privileges so it can't install anything).  So how does the user that wants to log under an admin-level account make sure their web browser is running under limited privileges to afford the extra security that it offers but also occasionally run the web browser with unrestricted privileges so they can perform software installs when they so choose?  Some choices are shown below.  Software Restriction Policies (SRPs) uses the power of the OS to exercise control on privileges for a process.

- Use the 'runas' command to specify that the web browser runs on another account which is a limited account.  That's a pain in the arse.  Every time you use 'runas' (interactively or with a shortcut), you will get prompted for the password of that limited account.  This won't work if that limited account has no password (it is blank) or you have no limited accounts (i.e., they're all admin accounts).

- Windows XP, and later, has its Fast User Switching (FUS) feature which lets you stay logged in under your current account while simultaneously logging under another account.  You could login to your limited account to do most of your everyday tasks there including your casual web browsing.  When you need admin-level privileges, use FUS to login and switch to your admin-level account.  Windows Vista's UAC (User Access Control) eliminates having to do this switching back and forth between limited and admin accounts; however, many users disable the UAC nuisance soon after getting acquainted with Vista.  Using FUS to switch between limited and admin accounts (which can remain logged in) might be more comfortable for these users.

- 3rd party utilities can load a program under a LUA token.  The process gets the same privileges as the token.  Since the LUA token has reduced privileges so does the process loaded under a LUA token, and so are all child processes of that parent LUA-tokened process forced to run under reduced privileges.  One such old utility was DropMyRights.  An alternative is SysInternals' psexec utility (with its -l command-line parameter).  The problem with this method is that only the program started by DropMyRights or psexec would have its privileges reduced by running under an LUA token.  It does not handle when the program is started as a child process of another program, like when you click on a URL in an e-mail that loads the web browser.  The shortcut that runs DropMyRights or psexec to run the web browser under an LUA token has no effect when the web browser is started by some other program.  You can define shortcuts that use DropMyRights or psexec to reduce privileges on the program that they load but you can still have instances of that program started that will run with unrestricted privileges (i.e., they get the same privileges as the program that loaded them which probably will be the privileges of your admin-level account that you logged into).

- The last method doesn't require any additional software if you are using Windows XP, or higher.  It involves using software restriction policies which are a feature of those operating systems.  In Windows Vista and up, there is a "Basic User" protection level that can be specified in a SRP rule which will run the specified program under a LUA token.  Alas, this policy level is available but hidden in Windows XP.  To add the "Basic User" policy level to Windows XP, run the following command to add an entry into the registry:

reg.exe add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers" /v "Levels" /t REG_DWORD /d 0x20000

The above line may be wrapped.  It is one line that runs reg.exe (command-line registry editor) with a whole lot of parameters.  Then to see if this policy level got added, run the group policy editor (gpedit.msc) and navigate to the following node:

Computer Configuration -> Windows Settings -> Security Settings -> Software Restriction Policies -> Security Levels

Note: gpedit may not be available in Home editions of Windows.

You should see the following security levels:

Disallowed: A program with this policy level cannot load.
Unrestricted: A program has all privileges of the account under which it was loaded.
Basic User: A program runs under the reduced privileges of a limited account.

Now you can define an SRP path rule to a program that will force that program to be managed by one of these policy levels.  The Disallowed level can be used to keep programs from loading.  You may install a program that you want but it keeps trying to run another program that you don't want to let run (like Quicktime that keeps trying to run qttask.exe or RealPlayers realsched.exe program to check for updates).  To force the web browser to run under the Basic User policy level (so it has the reduced privileges of the LUA token):

- Go under "Additional Rules" tree node.
- In the right panel listing the rules, right-click and select "New path rule".
- Browse to the web browser's executable file (e.g., iexplore.exe).
- Select "Basic User" for the security level.
- Add a comment, like "Force web browser to run under reduced privileges".
- Click OK.

Close all currently loaded instances of the web browser and reload it.  Now when you load the web browser whether directly with a shortcut or indirectly as a child process, like a URL link in an e-mail, the web browser will run under the Basic User security policy which reduces privileges on that process. 

Okay, you've now choked the privileges of every instance of your web browser but you know there are times when you need an unrestricted instance to, say, apply updates through the web browser to Windows or to install AX controls into the web browser.  Well, remember that the SRP policy is a *path* rule.  It will apply the policy to THAT program that you specified, not to a file in some other path.  So, and using Internet Explorer as an example, just make another copy of the web browser's executable file that is in a different path (some, like IE, won't run if you merely make another copy of iexplore.exe and call it another name, like iexplore2.exe).  Go to the web browser's install folder (C:\Program Files\Internet Explorer), make a subfolder called, say, NoSRP, and copy iexplore.exe under that new folder.  The SRP policy won't apply to that copy of the web browser's exectuable file because the path to it is different.  Then create a shortcut to that alternately pathed executable file and use that for your unrestricted copy of the web browser.

SafeSurf

  • Guest
Re: Avast! Sandbox and OA Run Safer
« Reply #10 on: March 03, 2011, 07:40:56 AM »
Thanks everyone.  I know sded and I used to have similar machine setups, but I see you now upgraded to Win7.  I'm still on XP, XP-Pro, and Vista with OA Premium and PrevX w/SOL and Avast for quite a while.  So far I've been fine without conflicts with Avast but haven't yet run the SB.  I just wanted feedback from others and sded answered it for me.  Thanks.  :)

sded

  • Guest
Re: Avast! Sandbox and OA Run Safer
« Reply #11 on: March 03, 2011, 10:17:07 PM »
Tried running the same download experiment today with FF, and virtualization seemed to work fine.  Download  was visible in FF, but did not appear when I switched to Explorer unless I told Avast! not to virtualize downloads.  Back to Opera to see if there was something else going on previously or if this is an Opera issue.
UPDATE Download still comes out of the sandbox with Opera no matter what the download virtualization settings are. ???
UPDATE2 Chrome seems to work OK
Will keep running them to see if anything else appears of interest.
« Last Edit: March 03, 2011, 11:03:52 PM by sded »