[Full-disclosure] Question for the Windows pros
pauls at utdallas.edu
Wed Jan 18 18:07:14 GMT 2006
--On Wednesday, January 18, 2006 11:40:00 -0600 Frank Knobbe
<frank at knobbe.us> wrote:
> On Wed, 2006-01-18 at 11:30 -0600, Paul Schmehl wrote:
>> I can read. I need to know, from a practical application standpoint,
>> what does this mean. What are the exposures?
> Sounds to me like that right allows a user to assume the security
> context of another user. Think of "RunAs" where a user runs a procedure
> as a different user.
> *That* ability should tell you a lot of what the exposures are. It's
> seems similar to allowing your *nix users to use su (without password
> check) to assume another user. (As root you can "su username" and you
> are that user. Imagine of your normal users could do that).
I understand *that*. My question is, what are you granting them "su"
*for*? The entire kettle of fish? Or specific tasks. The privilege only
allows you to impersonate a *client* (as in server-client), so (I would
think) you can't do file browsing or http parsing (or can you?)
IOW, what are the *servers* that you can impersonate the client for? Is
Windows Explorer a server, for example? Does it allow clients to access
it? Is IE a server? Obviously, all the *services* (or at least the
majority of them) would be servers - such as the Computer Browsing service
- but does that service allow clients to access it? Or the Alerter
service. Does it allow clients?
The explanations on MS's site are vague enough that they're meaningless.
What services running on Windows allow clients to access them? And if they
do, do they restrict access to the Local Machine? Or do they allow Remote
Access? (For example, RPC is clearly remote. Is the Windows Time service?)
Knowing the answers to those would go a long way toward answering the
question - what exactly are the capabilities that this privilege grants you?
> I don't see why you would ever need to grant a normal user such a right.
> It may be of interest for service accounts, though.
Unfortunately, in the context of my problem, the users must have this
right. Before I grant it, I want to understand exactly what the
ramifications of that are. If it's too severe a risk, then I'll have to
find some other way to solve this problem.
Paul Schmehl (pauls at utdallas.edu)
Adjunct Information Security Officer
University of Texas at Dallas
AVIEN Founding Member
Full-Disclosure is hosted and sponsored by Secunia.