|
|
|
date: Mon, 29 Sep 2008 13:17:52 -0400,
group: microsoft.public.windows.vista.security
back
Re: Security Question
"Paul Montgumdrop" wrote in message
news:uQxCZdlIJHA.1968@TK2MSFTNGP06.phx.gbl...
> Anyone out there know about this?
>
> <copied from a poster>
>
> Even if it never happens, if there is two users logged in at the same
> time, one is admin and has open a window, the other user can take
> advantage of the open window that the admin uses and do everything an
> admin would be able to do, as microsoft don't check from whom a command
> comes, it just assumes that the user who uses the window is the one who
> is logged into that session where it's displayed. There is a fix for
> this, but requires a rewrite of explorer and make all GUI using
> application to not work.
This is not quite as you describe.
1. First, let's state the obvious - if two people are physically using the
same computer, and one walks away without locking the session, or switching
it to the other user, yes, the user left in front of the keyboard can do
whatever he wants using the departed user's credentials, including setting
up a kind of 'back door' into the account.
2. Now, to the automated part of your discussion - if the two accounts are
in separate sessions - I.e. you have used the Switch User feature to keep
them separate, then no, there should be no way to have an unprivileged
program in the one session somehow break over to the other session and break
in to its administrative mode.
2a. If you are using 'runas', or 'run as administrator', or in some other
way running some processes as administrator, and other processes as a
restricted user, but both are running in the same session, on the same
desktop, there are almost certainly ways in which to have an unprivileged
program provide input to the privileged process, and perhaps interfere with
it more strongly.
The key is to consider what is meant by a "security boundary" - it's a line
that's drawn between two easily distinguishable partitions of the system's
operation, and it's a line that is guaranteed by the system's developer to
be a protected line over which all communication is carefully restricted so
as not to constitute a means to elevate or transfer privilege without having
the credentials required to do so.
A couple of keys here:
1. Easily distinguishable partitions - this comes from the concept of a
"line", as opposed to a "diffuse grey border". A line can be drawn between,
say, different sessions in an operating system, because it is clear which
session owns which piece of memory - but a line cannot be drawn between,
e.g., "code" and "data" (is a Javascript program "code" or "data"? It
depends.). Similarly, there is no sharp dividing line between two windows on
the same desktop - they share a communication to and from the desktop, and
sometimes between themselves. Because the operating system was not designed
to maintain separation between windows on a common desktop, this is not a
security boundary.
2. Guaranteed - there may be some apparent clear delineation between two
parts of a system, but unless the system's developers have guaranteed to
keep something as a security boundary, you cannot be sure that any effort
has gone into place to keep this delineation, or that the delineation is
anything other than your own hopeful delusion.
3. Elevate or transfer privilege without having the credentials to do so -
Obviously, the ability to switch to another session, enter the correct
password, and log on, requires that you know the correct password. Hence,
doing so is not considered an "elevation". To claim otherwise would be like
claiming that a lock is unsecure because "anyone with the right key can
unlock it". That is, of course, the function of the lock in a nutshell. It
is only when someone with the wrong key, or no key at all, can unlock it
that the lock is shown to be unsecure.
So, no, what the original poster describes is clearly _not_ the case - two
processes running in different sessions should not interfere, because there
is a security boundary between them. I'd say "cannot" instead of "should
not", except that bugs do happen - but because this is a security boundary,
if a means to cross that security boundary is found, that will be considered
a bug that needs immediate fixing.
Alun.
~~~~
--
Texas Imperial Software | Web: http://www.wftpd.com/
23921 57th Ave SE | Blog: http://msmvps.com/alunj/
Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.
date: Mon, 29 Sep 2008 10:52:31 -0700
author: Alun Jones lid
Re: Security Question
This article by Mark Russinovich about "Inside Windows Vista User Account
Control" might be interresting...
http://technet.microsoft.com/da-dk/magazine/cc138019(en-us).aspx
> "Paul Montgumdrop" wrote in message
> news:uQxCZdlIJHA.1968@TK2MSFTNGP06.phx.gbl...
>> Anyone out there know about this?
>>
>> <copied from a poster>
>>
>> Even if it never happens, if there is two users logged in at the same
>> time, one is admin and has open a window, the other user can take
>> advantage of the open window that the admin uses and do everything an
>> admin would be able to do, as microsoft don't check from whom a command
>> comes, it just assumes that the user who uses the window is the one who
>> is logged into that session where it's displayed. There is a fix for
>> this, but requires a rewrite of explorer and make all GUI using
>> application to not work.
>
> This is not quite as you describe.
>
> 1. First, let's state the obvious - if two people are physically using
> the same computer, and one walks away without locking the session, or
> switching it to the other user, yes, the user left in front of the
> keyboard can do whatever he wants using the departed user's credentials,
> including setting up a kind of 'back door' into the account.
> 2. Now, to the automated part of your discussion - if the two accounts
> are in separate sessions - I.e. you have used the Switch User feature to
> keep them separate, then no, there should be no way to have an
> unprivileged program in the one session somehow break over to the other
> session and break in to its administrative mode.
> 2a. If you are using 'runas', or 'run as administrator', or in some
> other way running some processes as administrator, and other processes
> as a restricted user, but both are running in the same session, on the
> same desktop, there are almost certainly ways in which to have an
> unprivileged program provide input to the privileged process, and
> perhaps interfere with it more strongly.
>
> The key is to consider what is meant by a "security boundary" - it's a
> line that's drawn between two easily distinguishable partitions of the
> system's operation, and it's a line that is guaranteed by the system's
> developer to be a protected line over which all communication is
> carefully restricted so as not to constitute a means to elevate or
> transfer privilege without having the credentials required to do so.
>
> A couple of keys here:
> 1. Easily distinguishable partitions - this comes from the concept of a
> "line", as opposed to a "diffuse grey border". A line can be drawn
> between, say, different sessions in an operating system, because it is
> clear which session owns which piece of memory - but a line cannot be
> drawn between, e.g., "code" and "data" (is a Javascript program "code"
> or "data"? It depends.). Similarly, there is no sharp dividing line
> between two windows on the same desktop - they share a communication to
> and from the desktop, and sometimes between themselves. Because the
> operating system was not designed to maintain separation between windows
> on a common desktop, this is not a security boundary.
> 2. Guaranteed - there may be some apparent clear delineation between two
> parts of a system, but unless the system's developers have guaranteed to
> keep something as a security boundary, you cannot be sure that any
> effort has gone into place to keep this delineation, or that the
> delineation is anything other than your own hopeful delusion.
> 3. Elevate or transfer privilege without having the credentials to do so
> - Obviously, the ability to switch to another session, enter the correct
> password, and log on, requires that you know the correct password.
> Hence, doing so is not considered an "elevation". To claim otherwise
> would be like claiming that a lock is unsecure because "anyone with the
> right key can unlock it". That is, of course, the function of the lock
> in a nutshell. It is only when someone with the wrong key, or no key at
> all, can unlock it that the lock is shown to be unsecure.
>
> So, no, what the original poster describes is clearly _not_ the case -
> two processes running in different sessions should not interfere,
> because there is a security boundary between them. I'd say "cannot"
> instead of "should not", except that bugs do happen - but because this
> is a security boundary, if a means to cross that security boundary is
> found, that will be considered a bug that needs immediate fixing.
>
> Alun.
> ~~~~
date: Tue, 30 Sep 2008 17:50:14 +0200
author: rrm
|
|
