Security Question

[Guest Paul Montgumdrop]

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.

[Guest Alun Jones]

"Paul Montgumdrop" <Paul@Montgumdrop.com> wrote in message

news:uQxCZdlIJHA.1968@TK2MSFTNGP06.phx.gbl...<span style="color:blue">

> 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.</span>

 

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.

[Guest rrm]

This article by Mark Russinovich about "Inside Windows Vista User Account

Control" might be interresting...

 

http://technet.microsoft.com/da-dk/magazin...019(en-us).aspx

<span style="color:blue">

> "Paul Montgumdrop" <Paul@Montgumdrop.com> wrote in message

> news:uQxCZdlIJHA.1968@TK2MSFTNGP06.phx.gbl...<span style="color:green">

>> 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.</span>

>

> 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.

> ~~~~</span>