Win32 security limitations: why?

Hi,

Trying to spawn a process from an impersonated client from within IIS-ASP I
came across some (in my opinion) weird behaviour.

1) CreateProcess and ShellExecute both create the new process using the
current process-token, yielding in a process running under the IWAM_xxx
account. This happens even if the client was an anonymous user!
I just don't understand this behaviour. Other operating systems I know will
spawn the process from the *current* security context, so under the
imporsonated client.
Doing it on the MS-way enables anonymous users to create process with a
higher security level. Thats a major security risk! Or not? Can someone put
some light on it, or point me to more detailed information about why MS
implemented security the way thay did?

2) Its even impossible with CreateProcessAsUser() to create the process
under the imporsonated account because the SeAssignPrimaryTokenPrivilege
must be held (and by default nobody does...)

3) I also needed to load the user hive, so I tried LoadUserProfile().
Also this API needed a privilege: the SeRestorePrivilege. Since the
imporsonated user is a "normal" user, it didn't held this privilege, so the
account couldn't load its own profile! Why is that? I understand that
loading another user's profile is a security risk, but loading your own
profile is definitly not.

I would like to understand more about the why's. Please help.
Thanks a lot.

Peter

Roger
Thu Jun 16 09:23:34 CDT 2005

On your item 1 it would seem you are confusing impersonation with
delegation. Impersonation allows a process to run with the credentials
that are impersonated. It does not allow that process to start up other
process with that identity. Doing that requires delegation of the
credentials to the impersonating process.

You also mention with surprise that starting up a process in the context
of your IIS-ASP app starts as the Iwam-Machine account "even if the
client is the anonymous user". That is exactly when it should start as
the Iwam account, for support of the anonymous users. Then you say
this allows the anonymous user to have a process with a higher security
level, which comment I do not understand. Higher than what? The
Iwam is the context for isolated Com support of the anonymous browing
user, and it can be latched down to fairly minimal capability (define a
custom "Iwam-app" and set it as the launch account for the IIS component
of the web in Component manager). Certainly if you use only one Iwam
over many distinct webs they you have not configured the IIS to support
isolation/containment between the webs/websites.


On your item 2 I am thinking your process was started with login type 3
(or login over the network rights). When the login is a local login type
the HKCU hive is already loaded and the account has no need to load it,
hence no need for the grant of right to do so. When access is over the
network there is in theory no need for the hive to be loaded, and like
there are good cases to be made why it should not be.

Notice that things change based on the isolation level in use, and I have
needed to make assumptions about your scenario by implications in
your post. If those were off, some aspects of this post may also be off.

--
Roger Abell
Microsoft MVP (Windows Security)

"Peter" <nobody@nospam.nl> wrote in message
news:uO9snqmcFHA.1040@TK2MSFTNGP10.phx.gbl...
> Hi,
>
> Trying to spawn a process from an impersonated client from within IIS-ASP
I
> came across some (in my opinion) weird behaviour.
>
> 1) CreateProcess and ShellExecute both create the new process using the
> current process-token, yielding in a process running under the IWAM_xxx
> account. This happens even if the client was an anonymous user!
> I just don't understand this behaviour. Other operating systems I know
will
> spawn the process from the *current* security context, so under the
> imporsonated client.
> Doing it on the MS-way enables anonymous users to create process with a
> higher security level. Thats a major security risk! Or not? Can someone
put
> some light on it, or point me to more detailed information about why MS
> implemented security the way thay did?
>
> 2) Its even impossible with CreateProcessAsUser() to create the process
> under the imporsonated account because the SeAssignPrimaryTokenPrivilege
> must be held (and by default nobody does...)
>
> 3) I also needed to load the user hive, so I tried LoadUserProfile().
> Also this API needed a privilege: the SeRestorePrivilege. Since the
> imporsonated user is a "normal" user, it didn't held this privilege, so
the
> account couldn't load its own profile! Why is that? I understand that
> loading another user's profile is a security risk, but loading your own
> profile is definitly not.
>
> I would like to understand more about the why's. Please help.
> Thanks a lot.
>
> Peter
>
>
>

Peter
Thu Jun 16 10:17:31 CDT 2005


"Roger Abell" <mvpNOSpam@asu.edu> wrote in message
news:O5iNz7ncFHA.1404@TK2MSFTNGP09.phx.gbl...
> On your item 1 it would seem you are confusing impersonation with
> delegation. Impersonation allows a process to run with the credentials
> that are impersonated. It does not allow that process to start up other
> process with that identity. Doing that requires delegation of the
> credentials to the impersonating process.
>
> You also mention with surprise that starting up a process in the context
> of your IIS-ASP app starts as the Iwam-Machine account "even if the
> client is the anonymous user". That is exactly when it should start as
> the Iwam account, for support of the anonymous users. Then you say
> this allows the anonymous user to have a process with a higher security
> level, which comment I do not understand. Higher than what? The
> Iwam is the context for isolated Com support of the anonymous browing
> user, and it can be latched down to fairly minimal capability (define a
> custom "Iwam-app" and set it as the launch account for the IIS component
> of the web in Component manager). Certainly if you use only one Iwam
> over many distinct webs they you have not configured the IIS to support
> isolation/containment between the webs/websites.

Let me take an extreme example: a process is running under the administrator
account and impersonificating a guest account. So, opening files, reading
registry-information etc is all done by the quest account. Assume that for
some reason the programmer needs to spawn a child-process. The child process
will suddenly be running in the administrator-account, and opening files etc
from the childprocess will be done via the administrator-account. I didn't
expect that at all. Its just not consistent.

>
>
> On your item 2 I am thinking your process was started with login type 3
> (or login over the network rights). When the login is a local login type
> the HKCU hive is already loaded and the account has no need to load it,
> hence no need for the grant of right to do so. When access is over the
> network there is in theory no need for the hive to be loaded, and like
> there are good cases to be made why it should not be.

OK, but that leaves the question WHY it's not allowed your own profile
unanswered...

<snip other lines>

Peter

Roger
Thu Jun 16 19:40:02 CDT 2005

"Peter" <nobody@nospam.nl> wrote in message
news:eczdLaocFHA.3328@TK2MSFTNGP09.phx.gbl...
>
> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
> news:O5iNz7ncFHA.1404@TK2MSFTNGP09.phx.gbl...
> > On your item 1 it would seem you are confusing impersonation with
> > delegation. Impersonation allows a process to run with the credentials
> > that are impersonated. It does not allow that process to start up other
> > process with that identity. Doing that requires delegation of the
> > credentials to the impersonating process.
> >
> > You also mention with surprise that starting up a process in the context
> > of your IIS-ASP app starts as the Iwam-Machine account "even if the
> > client is the anonymous user". That is exactly when it should start as
> > the Iwam account, for support of the anonymous users. Then you say
> > this allows the anonymous user to have a process with a higher security
> > level, which comment I do not understand. Higher than what? The
> > Iwam is the context for isolated Com support of the anonymous browing
> > user, and it can be latched down to fairly minimal capability (define a
> > custom "Iwam-app" and set it as the launch account for the IIS component
> > of the web in Component manager). Certainly if you use only one Iwam
> > over many distinct webs they you have not configured the IIS to support
> > isolation/containment between the webs/websites.
>
> Let me take an extreme example: a process is running under the
administrator
> account and impersonificating a guest account. So, opening files, reading
> registry-information etc is all done by the quest account. Assume that for
> some reason the programmer needs to spawn a child-process. The child
process
> will suddenly be running in the administrator-account, and opening files
etc
> from the childprocess will be done via the administrator-account. I didn't
> expect that at all. Its just not consistent.
>

Good example for the reasons for concern.
To fully address what you are experiencing we should move this over
to the IIS security newsgroup and clarify just exactly which config the
web is in (high isolation, anonymous vs not access and if not which
authentication methods are enabled, and which methods are being
negotiated and used by the browsing client). It actually turns into a
small matrix to get the context for the behaviors right.

> >
> >
> > On your item 2 I am thinking your process was started with login type 3
> > (or login over the network rights). When the login is a local login
type
> > the HKCU hive is already loaded and the account has no need to load it,
> > hence no need for the grant of right to do so. When access is over the
> > network there is in theory no need for the hive to be loaded, and like
> > there are good cases to be made why it should not be.
>
> OK, but that leaves the question WHY it's not allowed your own profile
> unanswered...
>

Indeed . . . but for that we would need to dive into what rights are
needed to load a hive into the registry and why it was not designed
to be sensitive to "ownership" of the hive compared to the loading
identity. In general I believe the thinking was - the registry is a
fundemental config repository and acts like composing the hives
in it should by under the control of the system. Then, this was next
moderated to allow admins to use the reg to access "offline" hives.
Why would a network login session need access to the HKCU of
the account of the network connection? They probably did not see
a justifiable reason why, and likely saw validatable reasons why
not. For local login, the account's HKCU is already there.
The way ACLing works is all or none, not all or none depending
on relationship (owner, accessor) and the same holds for how
user/security rights are defined for accounts (load any reg hive,
not load one's own). So, this fine-tuning, for a not foreseen, validated
scenario, was not possible without deltas to be basic grant design,
and the drivers to make the deltas are what ??

> <snip other lines>
>
> Peter
>
>

Roger
Thu Jun 16 19:48:15 CDT 2005

Can you supply sample asp code for this?
In the early morn blur I mixed up spawn on-box and off-box,
and your later post make clear you are speaking of on box.
As that does not involve new authentication, the impersonating
process should just pass copy of its own token to the child
process, unless a RevertToSelf call is involved.

--
Roger Abell
Microsoft MVP (Windows Security)

"Peter" <nobody@nospam.nl> wrote in message
news:uO9snqmcFHA.1040@TK2MSFTNGP10.phx.gbl...
> Hi,
>
> Trying to spawn a process from an impersonated client from within IIS-ASP
I
> came across some (in my opinion) weird behaviour.
>
> 1) CreateProcess and ShellExecute both create the new process using the
> current process-token, yielding in a process running under the IWAM_xxx
> account. This happens even if the client was an anonymous user!
> I just don't understand this behaviour. Other operating systems I know
will
> spawn the process from the *current* security context, so under the
> imporsonated client.
> Doing it on the MS-way enables anonymous users to create process with a
> higher security level. Thats a major security risk! Or not? Can someone
put
> some light on it, or point me to more detailed information about why MS
> implemented security the way thay did?
>
> 2) Its even impossible with CreateProcessAsUser() to create the process
> under the imporsonated account because the SeAssignPrimaryTokenPrivilege
> must be held (and by default nobody does...)
>
> 3) I also needed to load the user hive, so I tried LoadUserProfile().
> Also this API needed a privilege: the SeRestorePrivilege. Since the
> imporsonated user is a "normal" user, it didn't held this privilege, so
the
> account couldn't load its own profile! Why is that? I understand that
> loading another user's profile is a security risk, but loading your own
> profile is definitly not.
>
> I would like to understand more about the why's. Please help.
> Thanks a lot.
>
> Peter
>
>
>

Peter
Fri Jun 17 05:27:50 CDT 2005

"Roger Abell" <mvpNOSpam@asu.edu> wrote in message
news:eFwb%23YtcFHA.2288@TK2MSFTNGP14.phx.gbl...
> Can you supply sample asp code for this?
> In the early morn blur I mixed up spawn on-box and off-box,
> and your later post make clear you are speaking of on box.
> As that does not involve new authentication, the impersonating
> process should just pass copy of its own token to the child
> process, unless a RevertToSelf call is involved.
>
> --
> Roger Abell
> Microsoft MVP (Windows Security)

Roger, I don't need to send source code because this behaviour is by design:

--- doc from the platform SDK ---
The CreateProcess function creates a new process and its primary thread. The
new process runs the specified executable file in the security context of
the calling process.

If the calling process is impersonating another user, the new process uses
the token for the calling process, not the impersonation token. To run the
new process in the security context of the user represented by the
impersonation token, use the CreateProcessAsUser or CreateProcessWithLogonW
function.

--- end doc from the platform SDK ---

So, this leaves the question "why"?

Peter