Microsoft Windows Vista Community Forums - Vistaheads
Recommended Download



Welcome to the Microsoft Windows Vista Community Forums - Vistaheads, YOUR Largest Resource for Windows Vista related information.

You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so , join our community today!

If you have any problems with the registration process or your account login, please contact us.

Driver Scanner

Security Question

microsoft.public.windows.vista.security






Speedup My PC
Reply
  #1 (permalink)  
Old 09-29-2008
Paul Montgumdrop
 

Posts: n/a
Security Question
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.
Reply With Quote
Sponsored Links
  #2 (permalink)  
Old 09-29-2008
Alun Jones
 

Posts: n/a
Re: Security Question
"Paul Montgumdrop" <Paul@Montgumdrop.com> 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.



Reply With Quote
  #3 (permalink)  
Old 09-30-2008
rrm
 

Posts: n/a
Re: Security Question
This article by Mark Russinovich about "Inside Windows Vista User Account
Control" might be interresting...

http://technet.microsoft.com/da-dk/m...19(en-us).aspx

> "Paul Montgumdrop" <Paul@Montgumdrop.com> 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.
> ~~~~


Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Vista security question Matthew microsoft.public.windows.vista.general 14 01-21-2008 20:33
File Security Question Michael Gerbasio microsoft.public.windows.vista.security 1 09-22-2007 19:04
Security Breaches: A Question of 'When' Steve Security News 0 03-15-2007 05:07
Security question re IIS_IUSERS =?Utf-8?B?TGFycnkgUy4=?= microsoft.public.windows.vista.installation setup 0 03-11-2007 23:30
File security question =?Utf-8?B?d3luYW5kMzI=?= microsoft.public.windows.vista.security 6 01-18-2007 03:01




All times are GMT +1. The time now is 07:44.




Driver Scanner - Free Scan Now

Vistaheads.com is part of the Heads Network. See also XPHeads.com , Win7Heads.com and Win8Heads.com.


Design by Vjacheslav Trushkin for phpBBStyles.com.
Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.6.0 RC 2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120