App Review Comodo Sandbox (Auto-Containment) have a bug on Windows 10?

[Chimaira]

If this is how it is supposed to run or is the only way it CAN run with UAC and partially limited has been implemented in a way that completely protects the user I am fine with that. I just want to know just like all of you. CS has stated that partially limited has been beefed up and is completely secure.

This isn't a witch hunt against Comodo, it is just that those of us who are concerned about security need to know it can be trusted to protect us.

CS also has demonstrated many times with her great videos that CFW with her settings completely protects from infection with UAC on.

It may come down to us not gettings answers and we will just have to trust her. I don't know about you guys but I think that is good enough for me.

What do you guys think?

 

[Chimaira]

Also, I think I have managed a way to have UAC turned off while managing to keep admin privileges separate from the user.

Step 1: Turn off UAC completely through local security policy.
Step 2: Create a second user account and make it Administrator and set your main account as a standard user.
Do both of these steps before restarting your computer.

There will be no more UAC elevation, the privileges are completely separated, if you select the Run as administrator option any program simply will fail to acquire admin privilege. BUT while running as standard user if you need to run a program with Admin privileges what you do is hold down shift and then right click on the program .exe or shortcut, you will see an option in the context menu that says Run as different user. It will bring up a screen that asks for the user's name and the password for that account. Windows will then run the program as that user account with Admin privileges. This means that NO program can acquire Admin privileges under your standard user account. There is no UAC to allow it. This means no malware can acquire it either, it is impossible. When you select the run as different user option, the program is not running under the standard user account but your other Admin account. This can only happen when you select that option and enter the correct credentials.

I have run things this way and it works and CFW will run everything at the 'Restricted' sandbox level.

If you run process explorer it shows you the integrity level of all programs currently running. This shows you which level of privileges each program are allowed.
Running as standard user you will see all programs usually run at medium which is the default privilege level for a standard user and only programs granted Admin privileges are granted high integrity. Some programs run as low which is even more restricted.

If you compare running as a standard user with UAC on and with UAC off set up the way I've just described you will see that the same restricted standard user integrity levels are maintained meaning that standard user privileges are is the only level granted unless you have run that program as your Admin user account as mentioned before.

Please let me know what you all think.

 

[Av Gurus]

I set mine to BLOCK

 

[AtlBo]

I'm running W7 and I have it set to Partially Limited already. What a waste of a good thing I guess, since the elevation + restricted setting would work as intended in W7 (UAC on). I want to see what programs do though, and a good many unsigned will run in Partially Limited. I noticed, however, that there seem to be extensive write protections.

Couldn't find any way to get a P/L (virtualized) app to allow a write outside the sandbox. Like I tried to save to the Documents folder but no save. Same thing with remote drives. Actually, the list goes on and on. I finally managed to use a P/L virtualized app to save on the Root users folder inside the sandbox...also in the user profile folder in the VT root folder. Strangely I guess, I was able to save to appdata areas like Roaming and Local, etc. Still, apps at P/L seem to have access to data but very few write options. Some portables write to their folder. Forget about running them P/L from a remote drive if they require the ability to write user settings to their folder...

I used FullEventLogView from NirSofer. Delete the dev from the TVL then run the file from downloads or whereever. It's almost a portable. File->save selected events->to test the write locations. It won't trigger an elevation request, so Auto-contain should be set to "Partially Limited", unless in W10 w/UAC on lol...

Anyone know of a test of Petya against Comodo Partially Limited? It would be fun to work with the SUA based malwares (that do their dirty work without elevation) to see if they can be contained by that setting. I think Petya works without elevation if I recall.

Any information to see the limitations of P/L would be very helpful and maybe add some confidence!

 

[Nightwalker]

Thanks @Av Gurus for all your testing and posts about this bug

I'm running W7 and I have it set to Partially Limited already. What a waste of a good thing I guess, since the elevation + restricted setting would work as intended in W7 (UAC on). I want to see what programs do though, and a good many unsigned will run in Partially Limited. I noticed, however, that there seem to be extensive write protections.

Couldn't find any way to get a P/L (virtualized) app to allow a write outside the sandbox. Like I tried to save to the Documents folder but no save. It doesn't even save to the VT Root folder that way, much less the regular root directory. Same thing with remote drives. Actually, the list goes on and on. I finally managed to use a P/L virtualized app to save on the Root users folder inside the sandbox...also in the user profile folder in the VT root folder. Strangely I guess, I was able to save to appdata areas like Roaming and Local, etc. Still, apps at P/L seem to have access to data but very few write options. Some portables write to their folder. Forget about running them P/L from a remote drive if they require the ability to write user settings to their folder...

I used FullEventLogView from NirSofer. Delete the dev from the TVL then run the file from downloads or whereever. It's almost a portable. File->save selected events->to test the write locations. It won't trigger an elevation request, so Auto-contain should be set to "Partially Limited", unless in W10 w/UAC on lol...

Anyone know of a test of Petya against Comodo Partially Limited? It would be fun to work with the SUA based malwares (that do their dirty work without elevation) to see if they can be contained by that setting. I think Petya works without elevation if I recall.

Any information to see the limitations of P/L would be very helpful and maybe add some confidence!

Interesting read, I will share my insights about this later.

About Petya, it should be contained easily because even at default settings Comodo Sandbox doesnt allow "direct disk access", so in theory even without restrictions (just virtualization) it shouldnt be able to infect the machine.

 

[AtlBo]

About Petya, it should be contained easily because even at default settings Comodo Sandbox doesnt allow "direct disk access", so in theory even without restrictions (just virtualization) it shouldnt be able to infect the machine.

Great thanks @Nightwalker. Looking forward to your insights on P/L.

I think, @cruelsister has been over this a few times about P/L, even in this thread mentioned it a couple of times. However, it seems the few write options I have (including the virtualized main drive root btw...forgot to mention that one) are ALL inside the sandbox and VERY limited. This is explained by no "direct disk access". No writes to virtual Windows folder->it points to the virtual documents folder->Error "There are no more files." Libraries, Downloads, Program folders, nothing even virtual is accessible. Again, this is ONLY in the virtualized areas and NOTHING outside. Only exceptions in the virtual areas where writes seem to be possible (that I have found so far) are the virtualized root of the main drive, users folder (root folder only), individual user folders (root folder only), and app data locations.

 

[AtlBo]

Found one other area in the virtual area where writes are possible. User\Downloads. Guess this is for browser downloads...EDIT also Favorites for the same reason I suppose...EDIT2 app data must be for temp internet files

 

[Deleted member 178]

Remember, UAC was originally a privacy boundary feature (not a security one) made to isolate users accounts (hence the datas) from others except for the admin who can access everyone user profiles.

Now i see people disabling UAC to make a buggy software work as it should...So for those who disabled UAC , can you access the others user profiles?

 

[Chimaira]

Remember, UAC was originally a privacy boundary feature (not a security one) made to isolate users accounts (hence the datas) from others except for the admin who can access everyone user profiles.

Now i see people disabling UAC to make a buggy software work as it should...So for those who disabled UAC , can you access the others user profiles?

I have described this above in detail but if you disable UAC and run as standard user you can run apps as the admin user after entering the correct credentials. This option is only available by holding down shift and right clicking any .exe or shortcut, in the context menu an option is there called 'run as different user'. I've have also noted that this option is not available with UAC on.

UAC is completely off so there is no elevation possible, run as administrator does not work, any program that needs it will fail, but for those apps that you choose to run through the admin account will have those elevated privileges. So as far as I'm aware there is no possible way for any program to acquire admin privileges unless you run the program through your admin account.

I have run it this way for a few days and no major issues showed up. I could perform the things that needed admin elevation with no issue. Except for one program TeraCopy which needs constant admin privileges at all times and would not work.

I also want to quote my previous post: "If you compare running as a standard user with UAC on and with UAC off set up the way I've just described you will see that the same restricted standard user integrity levels are maintained meaning that standard user privileges are the only level granted unless you have run that program as your Admin user account as mentioned before."

So running things this way as far as I'm aware allows one to maintain the separation between standard user and admin privileges and running CFW with the restricted sandbox settings always being applied, even when you run a program through our Admin account.

 

[abdou17]

Found one other area in the virtual area where writes are possible. User\Downloads. Guess this is for browser downloads...EDIT also Favorites for the same reason I suppose...EDIT2 app data must be for temp internet files

Those are the places where you can make changes
they are under DO NOT VIRTUALIZE ACCESS TO under containment settings

if you disable it you can't save changes made in the sandbox on your real system

 

[AtlBo]

Been meaning to get back to this. Yes, I had a number of locations in the sandbox blocked using protected folders. I had forgotten about this until I was reminded of the element by a Comodo forums poster. I had always thought that those choices were connected to the HIPs setting for "Protected Files/Folders". Well, they are not as far as I can tell. I left them enabled wondering why anything could still write to the locations LOL...I never got any HIPs alerts with them there for Protected Folders.

So, to clear it up. Using HIPs Protected Folders affects the sandboxing. Apps can't write in the sandbox in those locations (in the sandbox...no writes outside). Interestingly, it has no affect on the HIPs as I would have expected, so anyway. When I removed those locations, I can now running a virtualized app save in the sandbox to Documents, Desktop, etc. and "Do not virtualize access to..." seems to work now, where it did not before. I assume it was the same HIPs setting for Protected Folders that kept that from working, since removing them caused the setting to work for various areas I added to "Do not virtualize..."

I think Comodo should straight up attach the Protected Folders element to HIPs and not worry about where things write in the sandbox. Use the various levels of restrictions to define that. Then let HIPs monitor in the sandbox as it normally monitors and pick up on mysterious or possibly dangerous writes that way. All the HIPs settings have the capacity for exclusions (pic).



It wouldn't take long to have the Protected Files/Folders setting trained as long as user didn't try too many files. So any time an app wants to make a change in a protected location, you should get the prompt from HIPs, unless there is already a "Remember this setting" exclusion in Modify for the Protected Folders HIPs rule. Didn't see that behavior here on Safe Mode when I named Protected Folders. Comodo HIPs monitoring category options:



Maybe one of you guys knows why or if I am doing something wrong. Can't understand why adding to the HIPs Protected Files or HIPs Protected Folders would affect only where virtualized or restricted apps can write in the sandbox without a HIPs alert. HIPs setting affects only Containment output...

 

[cruelsister]

Hi Guys- Yes, there is indeed an issue in Win10 that when running a file that requests Privilege elevation Comodo will run it at the PL setting no matter what. By the way, this will occur with UAC on or UAC off. The question is, is this in any way significant for protecting the system? The answer is absolutely not. Although the PL setting will allow stuff to make some trivial environmental changes, actual infection of the system will be prevented.

I'm being purposefully vague on this matter, but will (if time permits) post a video about this topic, contrasting Wi7 with Win10, and showing the rare (and stupid) worst case scenario that could occur. Until then this matter can be resolved for CF users on Win10 by selecting the Block option on the "Do not show privilege elevation alerts" setting in Containment.

ps- I hope that there will be as much outrage about certain other products when I post my 2nd opinion scanner video in April...

 

[Deleted member 65228]

UAC is completely off so there is no elevation possible, run as administrator does not work, any program that needs it will fail, but for those apps that you choose to run through the admin account will have those elevated privileges. So as far as I'm aware there is no possible way for any program to acquire admin privileges unless you run the program through your admin account.

Are you sure about this?

If UAC is completely disabled then I would suspect that if a standard rights program attempted to restart as elevated, it would succeed, because nothing would be there to stop it?

Have you actually tested all of this properly? Not being able to spawn as administrator yourself is not the same as other programs being unable to do it.

Never tested so that is why I am asking.

 

[Av Gurus]

Hi Guys- Yes, there is indeed an issue in Win10 that when running a file that requests Privilege elevation Comodo will run it at the PL setting no matter what. By the way, this will occur with UAC on or UAC off. The question is, is this in any way significant for protecting the system? The answer is absolutely not. Although the PL setting will allow stuff to make some trivial environmental changes, actual infection of the system will be prevented.

I'm being purposefully vague on this matter, but will (if time permits) post a video about this topic, contrasting Wi7 with Win10, and showing the rare (and stupid) worst case scenario that could occur. Until then this matter can be resolved for CF users on Win10 by selecting the Block option on the "Do not show privilege elevation alerts" setting in Containment.

ps- I hope that there will be as much outrage about certain other products when I post my 2nd opinion scanner video in April...

Did you know about that issue before it came to light or is this news for U2?

 

[cruelsister]

Yes, but I found the so trivial that I was afraid by mentioning it that it would cause the unwarranted storm that you have seen. I kind of hinted around it by stating that the baseline PL setting is more robust currently than in previous builds (which is true).

You may note that nowhere do you see any proof that a Win10 system was infected because of this issue. It saddens me that other products can be proven to but a system at risk and this will go without comment, but if Comodo decides to change the colors of the taskbar icon it will be the Issue Of The Ages.

 

[abdou17]

but if Comodo decides to change the colors of the taskbar icon it will be the Issue Of The Ages.

True LOL

 

[AtlBo]

Anyone have any information on the risk of running contained applications virtually without restriction? Would this setting stop Petya and other SUA defeating malware? Only asking because the containment of Comodo seems so complete. In SUA I am really curious if I could run without restriction much less with PL.

I agree with @cruelsister in principle. I mean if Windows 10 UAC strips Comodo users of their option for Limited or Restricted, so be it. I expect those are trade offs for running an OS with more kernel protection and more refined UAC protection of the user space. If PL does the job, maybe Comodo should remove those options for W10 users. I am assuming that the issue is something in W10 and not a true bug, since Comodo via Umesh has stated that there is a limitation associated with W10...

 

[Av Gurus]

Yes, but I found the so trivial that I was afraid by mentioning it that it would cause the unwarranted storm that you have seen. I kind of hinted around it by stating that the baseline PL setting is more robust currently than in previous builds (which is true).

You may note that nowhere do you see any proof that a Win10 system was infected because of this issue. It saddens me that other products can be proven to but a system at risk and this will go without comment, but if Comodo decides to change the colors of the taskbar icon it will be the Issue Of The Ages.

What is the point of placing "Restricted" in the settings when these settings change themselves?
Enough is to leave the settings in "Partially Limited".

 

[abdou17]

What is the point of placing "Restricted" in the settings when these settings change themselves?
Enough is to leave the settings in "Partially Limited".

Even PL will get the job done and prevent your real system from being infected
i've seen many test on CIS with default settings and none of the tested malware could bypass the containment

 

[Av Gurus]

OK, no problem about that.
I'm interested in why she put in her video test/suggestion (about setting Comodo) to "Restricted" mode when "Partially Limited" is enough?
Why didn't just say/show let it run in "Partially Limited"?