How Did Google Chrome Install as System Process?

[W]

I have always been intrigued by the Google Chrome installation process.
Somehow it manages to install under an account of an ordinary user under
Windows XP, without asking for admin permissions. Today I was viewing all
open file handles on my Windows XP workstation, and it appears that several
Google Chrome files are being maintained by "System Process". Can someone
explain to me how Google Chrome managed to wiggle its way from an
installation by an ordinary user - who does NOT have permission to write to
95% of the file system and doesn't have install permission for normal
applications - to being a system process?

I trust Google and Chrome, and they are great products. But from a pure
security standpoint I am really concerned how did this process elevation
happen.

--
W

[VanguardLH]

W wrote:

> I have always been intrigued by the Google Chrome installation
> process. Somehow it manages to install under an account of an
> ordinary user under Windows XP, without asking for admin permissions.

That's because it extracts its files under %userprofile% under the Apps
folder. Users have read, write, AND execute permissions on files under
their profile folder. Google Earth, MagicJack, and several other
programs do the same trick to circumvent the requirement of logging on
under an admin-level account to install software.

> Today I was viewing all open file handles on my Windows XP
> workstation, and it appears that several Google Chrome files are
> being maintained by "System Process". Can someone explain to me how
> Google Chrome managed to wiggle its way from an installation by an
> ordinary user - who does NOT have permission to write to 95% of the
> file system and doesn't have install permission for normal
> applications - to being a system process?

How Google and others deposit executable files and run them without
requiring admin privileges was explained above. For running a program
under the System account, well, I can think of a couple methods. One is
to use the 'at' command to immediately schedule a process to load.
Scheduled events using the 'at' command run under the System account.
Try it yourself by running the following in a command shell:

at hh:mm "c:\windows\system32\cmd.exe"

I tried adding parameters, like /c to run a command but the scheduler
didn't like that so I just specified the program to load. stdout
doesn't go to the current shell so you have to redirect it elsewhere.
Make the hh:mm (24-hour time format) to some value a few minutes in the
future. Once you run this command, go into the Scheduled Tasks applet
in Control Panel and you'll notice a new task got defined call "AT<n>"
where <n> is a number. Look at the properties of that task and you'll
see it is scheduled to run under the System account. That's how you get
scheduled tasks to run under the System account because you cannot use
that Scheduled Tasks applet to specify the System account. schtasks.exe
is a more robust command-line scheduler. After the scheduled task runs,
it will remain running. You loaded a command shell but with no console
so you cannot see it. Look in Task Manager's Processes tab and notice
you now have an instance of cmd.exe running under the SYSTEM account.
You'll have to use Task Manager or taskkill.exe to kill that hidden
(unwindowed) instance of the cmd.exe process (and then delete the AT<n>
scheduled tasks in Task Scheduler to get rid of the test case).

Read the following on how someone else used 'at' to run a program under
the System account:
http://blogs.msdn.com/b/adioltean/archive/2004/11/27/271063.aspx

Well, if I can add a process to run under the System account using the
'at' or 'schtasks' commands then obviously it is possible to
programmatically load a process under a specific account. Another
method to escalate privileges, for example, is to use SysInternal's
'psexec' to load a process under the System account. Then there are
exploits, if not patched (if there is a patch), can be used to escalate
privileges; see:

https://isc.sans.edu/diary.html?storyid=9988

Did you ever check Task Scheduler to see if there were some tasks
defined there for Google's product(s)? As I recall, Google embedded
their updater into Google Chrome but users figured out how to disable it
because they wanted to control when Google updated its products on their
host. So Google moved to scheduled tasks for its updater and maybe
those run under the System account.

> I trust Google and Chrome, and they are great products. But from a
> pure security standpoint I am really concerned how did this process
> elevation happen.

Privilege elevation wasn't something well protected until Windows Vista
and called UAC (User Account Control). Read:

http://en.wikipedia.org/wiki/User_Account_Control

You may trust Google but they are deliberately abusing the purpose of
the %userprofile% folder where data files are to be stored, NOT
executables; however, because users have execute privileges on files
under their %userprofile% folder, Google uses that loophole to let its
program "install" and run its programs from there without requiring
admin rights by the user that does the install. I had thought that
simply removing execute permissions from my profile folder (and its
subfolders) would prevent this type of abuse; however, I've run into
other problems with that scheme and has to restore execute rights there.

[W]

Is there a system setting that would prevent ordinary users from using AT
command to schedule a task running as SYSTEM?

Is it enought to exclude ordinary users from the normal local policy or
group policy option that allows the user to schedule tasks?

--
W


"VanguardLH" <V...@nguard.LH> wrote in message
news:jk396f$cm5$1...@news.albasani.net...

[VanguardLH]

W wrote:

> Is there a system setting that would prevent ordinary users from using AT
> command to schedule a task running as SYSTEM?
>
> Is it enought to exclude ordinary users from the normal local policy or
> group policy option that allows the user to schedule tasks?

In gpedit.msc, create a SRP (software restriction policy) that's a Path
rule to block loading of:

c:\windows\system32\at.exe

However, that won't stop other methods or programs that will do the same
to escalate privileges.

[VanguardLH]

W wrote:

> Is there a system setting that would prevent ordinary users from using AT
> command to schedule a task running as SYSTEM?
>
> Is it enought to exclude ordinary users from the normal local policy or
> group policy option that allows the user to schedule tasks?

I just checked and you are required to be logged into a Windows account
that is in the Administrators group to run the 'at' command. Probably
the same for schtasks. So while those commands can let you schedule a
task that will run under the SYSTEM account, you still must be logged in
as an admin user to run the command.

"Ordinary users" should be logging in under a LUA (limited user account)
to reduce their permissions. If you let multiple users login under an
admin account then, of course, you've granted them all to be admins to
do all the same actions you can perform as an administrator.

[maryper...@gmail.com]

[maryper...@gmail.com]

On Saturday, March 17, 2012 at 6:11:06 PM UTC-4, W wrote: