Chromium browsers and SRP

With software restriction policies enabled on all software files including libraries (DLL files), Chromium based browsers will not work properly. The browser gives the following error and you can not browse. This is under XP Pro SP3.

However, if you leave library (DLL files) alone but keep SRP enabled on everything else, the browser works fine.

I've even gone and added the Iron Portable folder as an exception under "Unrestricted" in group policy. So it must be trying to load libraries from elsewhere?

 

Iron works with SRP fully enforced. It did at least for me.

Later...

 

If you look in the event viewer it may tell you where the dll file is located. It works for .exe's but I've never blocked dll's so I'm not certain it will help.

 

i get similar screen if i run Iron portable browser( not chromium) inside geswall. I guess geswall stops iron's access to some file in system 32.

 

well, I tried Event viewer and there didn't seem to be a problem.

I gave process monitor from sysinternals a try and I think it should help but it was a bit overwhelming with the amount of information it gave.

That and it looked like all files Iron Portable was accessing are either located in it's own folder or C:\Windows\(System)(etc)

 

In my case it was solved by an allow rule in GesWall to acess

\Device\NamedPipe\chrome

 

Hm, well I don't run GesWall though.

Anyone else with this experience? I know that I had to suggest another Wilders forum user that they had to disable SRP to get Chrome working properly and it worked for him.


This is the screen I mean when I say I can't enable SRP on "all software files". This is the only way SRP can be enabled and Chrome still works.

 

It is most surely that a rule needs to be opened for one or more directory or files which chrome has dependencies on.

I will try later today to install chrome in vm and see what might come of it.

Sul.

 

Running Vista Home with LUA and SRP reg tweak by Lucy as shown elsewhere on this forum. Chrome, Chromium, Iron all give me the same message you see in your first post.

Running XP Pro and applying LUA and SRP per instructions on http://www.mechbgon.com/srp/index.html will allow chrome to open but not connect. (blank page)

I’m not really concerned as I prefer Fx ATM but it would be nice to find out why Chrome/Iron’s not working.

 

Interesting stuff going on, much to learn from.

My test vm box is XP Pro SP2 plus some choise updates. It is a default install but many services and registry tweaks are applied, mostly towards performance or appearance (get rid of default things like the tour, etc).

Install chrome latest version. Only IE exists othewise, no AV, no FW, just bare windows XP. Using Process Explorer and Process Monitor.

Start by running chrome, Explorer.exe is the parent (the shell), with an instance of chrome being a child process of explorer.exe. It is also found that after the first instance of chrome.exe appears, a second instance of chrome is made, this one being a child process (thread) to the first chrome instance. It works as expected in all senses.

Now, if you were to examine the security of either chrome process, you will note that it inherits many rich settings from it's parent the shell. Both instances of chrome do. In the process of chrome being created, many keys are read in the registry, and overall quite a lot going on both from the shell as well as chrome. Too much to digest quicly for sure.

Next step, run chrome with a Drop My Rights approach. I used my SaferZone tool, to demote it to a Basic User. In this instance, chrome starts not as a child of the shell, but as it's own parent object. The explorer.exe thread is closed so that explorer.exe is not the parent. After the first process is created, a second child chrome process is created. It works as expected in a DMR appraoch.

Next. I set up SRP policies for chrome.exe. First was to set chrome.exe to run restricted as Basic User. The option of enforcement in SRP is default to all files excluding dll's. I used the secpol snap-in to create the first tests, where in admin logon, the default rule is to allow. The SRP policies apply to all including admins, and the default restriction is all files excluding dlls. In this case, when chrome runs, chrome is a child process of explorer.exe, however there is no second process of chrome, only the first. When running chrome without restrictions or with DMR, there are always 2 instances of chrome, the second chrome.exe being a child of the first chrome.exe.

Next I use the same settings except I change the restrictions to include all files including dlls. The same resulst happens, where chrome.exe is the child of explorer.exe, but there is never a second instance of chrome.

Next I used my tool PGS. I got rid of all traces of SRP created with the snap-in and create the same tests with PGS. Again, exclude dlls and include dlls resulted in the same case where the first chrome.exe is a child of explorer.exe, and there is never the second instance of chrome.exe made.

I then chose the setting NONE for the restritions to apply with SRP. In the snap-in, you don't get this option. Using PGS I give you the option. It is just a registry value to toggle anyway. The results are suprising. When using the NONE option, chrome.exe is spawned as a child of explorer.exe. And the second instance of chrome.exe is spawned as a child of the first instance of chrome.exe. However, the strange part is that it exists under explorer.exe as a child, not on it's own like the DMR method does. I had thought that using the NONE option was akin to DMR, and that the options for including all files with or without dlls was giving more inheritance to the process being manipulated. I now don't know really what the difference is. But that is beside the point for now.

It is also interesting to note that when you start chrome with no restrictions, it inherits the shells rights, or in this case admin rights (because this is an admin login after all). But, when you start chrome in DMR, or any of the three options in SRP (via PGS for the NONE option), the rights are vastly reduced. So both DMR and SRP are capable of running chrome, as long as SRP is using the NONE option, and all options appear to drop the rights of chrome.exe.

What is unknow to me ATM is how the inclusion of applying SRP restrictions to all files including or excluding dlls affects overall security. It may well be that DMR, starting the program in question, and not being a child process of the shell is the more secure. Or it may be the other way around. I have not seen any documentation on that. You can also start other programs, such as notepad.exe, and see that when you start it with DMR, notepad.exe is its own process, but when you start it under any type of SRP config, it always starts with explorer.exe as it's parent. Indeed even starting notepad.exe with no restrictions sees it as a child process of the shell.

Like I said, this is pretty intersting. But it shows me so far no reason why chrome should not work in SRP. But then, I have a few hours worth of ProcMon logs to go through to really track it down.

Sul.

 

I'm not sure what all this information you've put forth exactly means but it's very interesting. I'll have to mull over it for a while.

Thanks, Sully. .

Later...

 

Sully, your analysis is quite interesting! I'd like to thank you for taking the time to do this

I'd also like to add that I run in a LUA environment with SuRun. Not sure why I forgot to mention that in my original post.

I did a quick search over at Google's support forum. One Italian user has the same issue and found that SRP might be preventing a DCOM server from starting for Chrome/Iron.

He posted this from his Event Viewer (I can't seem to find a similar error in my Event Viewer though)

"Tipo evento: Errore
Origine evento: DCOM
Categoria evento: Nessuno
ID evento: 10000
Data: 06/03/2009
Ora: 10.43.59
Utente: COMPAQ\Normale
Computer: COMPAQ
Descrizione:
Impossibile avviare un server DCOM: {2F0E2680-9FF5-43C0-B76E-114A56E93598}. L'errore
"Impossibile aprire il programma specificato perché un criterio di restrizione software lo impedisce. Per ulteriori informazioni, aprire il Visualizzatore eventi o contattare l'amministratore del sistema. "
è avvenuto durante l'esecuzione del comando
"C:\Documents and Settings\Amministratore\Impostazioni locali\Dati applicazioni\Google\Update\GoogleUpdate.exe" -Embeddi

He posted here
http://www.google.com/support/forum/p/Chrome/thread?tid=1be8b2728f07bc40&hl=en





On a side note, however, I was just looking through my Event Viewer when I noticed some SRP warning msgs unrelated to my Chrome issue. And boy am I ever glad I started using LUA+SRP!

I noticed that an executable file named "svchost.exe" located under my "Application Data" folder had been trying to launch all this time!

No anti-virus I've had installed ever picked up on it either. I uploaded it to virustotal and it only got 5/41 detections but I still don't trust it and I'm glad I've had SRP in place all this time. More proof that SRP works

 

Multiple instances of svchost.exe are a normal function of Windows,this article explains it's purpose:

http://www.howtogeek.com/howto/windo...is-it-running/

 

Thanks. Yes, multiple svchost files are normal but this one in particular was located in a folder under "C:\Documents and Settings\User\Application Data" and not C:\Windows\System32.

 

Not quite getting the full picture yet, as procmon has much to look at. But it would appear that if you make srp rules for chrome.exe, first rule is to restrict to basic user and exclude dll's (the default), then you start procmon monitoring. After chrome opens, stop procmon montoring and save the data.

Then set the srp rule to allow chrome.exe. Repeat steps of start monitoring procmon then immediately start chrome. (remember to start procmon, stop monitoring and clear the values, so that when you engage procmon monitoring again, then directly start chrome, it will contain much less). Anyway, save this output as well. I looked at them side by side, the values from Basic User in procmon in host OS, the values for Allow in vm box.

Anyway, what you see is, lol, a lot. But you can note one difference that seems to be repeated. Somewhere after samlib.dll is accessed, the SAFER registry values are examined. On the log that used Restrict as the option, there is a Close File operation on chrome.exe, and then the rest of SAFER is examined. On the log which chrome is Allowed, the examination of SAFER appears to finish, then the Close File operation is performed. Later in the Allowed log, you see the process creation and start of the child process chrome.exe, whose parent PID belong to the original chrome.exe.

I am a little bleary eyed examining these logs, but it seems somewhere there must be the reason why. I think a trip to MSDN may clear it up. This much is known, when you initiate a process to start, it will at some point examine the SAFER registry values. Depending on what it finds there, a process can be denied or allowed or restricted. It appears from the ProcMon logs this is happening just fine. It is after the SAFER values reveal they are applying to all files (either including or excluding dlls) that things start to radically differ in the logs.

I will imagine that there is more info needed on what exactly applying the restrictions to "All Files" means. It is my guess that whether or not dlls are included means nothing, but that the mere inclusion of all files that are dependents to chrome is the issue. I have a hunch it is also not relying on the rights of the User (or lack thereof), because chrome is itself desinged to be installed/ran in user space, unless I am missing something.

Fun stuff.

Sul.

 

Well, a trip to MSDN and some googling reveals some interesting issues. Seems SRP can be circumvented even from LUA if you execute arbitratry code that is SPECIFICALLY designed to do so. Here is a list of possible entry points. What I have now read shows simple macros like those in an office document or corel are capable of utilizing this exploit. Imagine, whether you are admin using SRP to reduce process rights or in LUA using SRP as default deny, it is possible to go around SRP. Granted, the liklihood of ever encountering this is dismally small. As well, it would have to get by your first line of defense, which is trust the source. But still, it is quite interesting.

On to the subject at hand, I have found some other registry values that pertain to SRP (SAFER) which give influence to this situation. I have not tracked any of them down yet in the ProcMon logs, lol, as I am still opening webpages. But, for those who are keen on this geeky stuff, some fresh reading for you.

Sul.