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" <Paul@xxxxxxxxxxxxxxx> wrote in message news:uQxCZdlIJHA.1968@xxxxxxxxxxxxxxxxxxxxxxx
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.
~~~~

.

Relevant Pages

  • [NT] Cryptographic Flaw in RDP Protocol Can Lead to Information Disclosure
    ... The Remote Data Protocol (RDP) provides the means by which Windows systems ... The first involves how session encryption is implemented in certain ... An attacker who was able to eavesdrop on and record ...
    (Securiteam)
  • Re: How to prevent session stealing?
    ... Windows assumes that each user corresponds to one account. ... longer using the first session when a second session logs in. ...
    (microsoft.public.windowsxp.work_remotely)
  • RE: Spying, admin to user login?, Is it possible?
    ... shadow session could not be created directly on Windows XP computer. ... you could active only one user session at one time ... you need to remote desktop to a Windows 2003 ... Microsoft also publishes a KB to describe this work around in detail. ...
    (microsoft.public.windows.server.sbs)
  • Re: Remote Desktop Re-Connect
    ... does not include Windows 2003 or Windows Server. ... available target OS's are appropriate for Windows Server 2003 SE SP1? ... but my recollection was that the key is to look for event log errors at the ... remote session, and my local printer is not. ...
    (microsoft.public.windowsxp.work_remotely)
  • Re: Mapping network resources from a service
    ... > stations and desktops. ... I think I need to create a new windows station for each ... its own separate session id. ... so the TS session & security context represent the same boundary as ...
    (microsoft.public.win32.programmer.kernel)