Re: Process security


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:mrjf35tl6lpj0i74aetpaiam18fngdpg70@xxxxxxxxxx
As most of you know, I'm not a security guru, and in fact have used
virtually nothing in
the WIndows security API set. So here's a question for those of you who
have:

Suppose I want to create a process that I do not want the user to be able
to attach a
debugger to, or do VirtualAllocEx, CreateRemoteThread, or any of the a
number of
techniques that might result in modifying the executable image of the
process. Is it
possible to put ACLs on the .exe file that would prevent this.

Strictly speaking, the answer is no. When a process is running, the
credentials under which the process runs determine the security of the
process. Setting the ACLs on the executable image can control which
principles have access to the executable and therefore the credentials under
which the process may run, but other principles on the system may still be
able to access the process depending upon the privileges granted to them and
what the process does.

In your example, regardless of the permissions and ownership of the
executable, once running, a principle with the SeDebugPrivilege on the
computer could access the object.

The following KB article describes that a user/principle with
SeDebugPrivilege can do all the things you describe above:
http://support.microsoft.com/kb/185215

The following article discusses some various privileges and how they can be
used.

http://www.microsoft.com/msj/0899/security/security0899.aspx

It seems to me that the confusion here is between ACLs and privileges that
principles may be granted on a system.

Assume that it is in the
Program Files folder, and the user is running as a limited user without
admin privileges;

If this is indeed the case and the user has only the 5 standard rights of a
limited user and is running on Vista or Windows 7, at first glance it seems
to me that the things you mentioned above would not be possible barring a
serious administrative mishap.

also, there is a question as to whether if Vista supports the suggested
approach whether
XP SP? or Win2K SP? would also support it.

By default, Vista security is far more restrictive than that of Windows XP
or Windows 2000. Windows Vista also enforces additional security boundaries
such as desktops and adds other such as integrity levels. However, it *is*
possible to run as a limited user underneath earlier versions of Windows but
the additions within Vista really help shore up the defences of the system
and make it easier to secure the system.

The following article describes how to run internet facing applications as a
limited user on a version of Windows prior to Vista..

http://blogs.technet.com/markrussinovich/archive/2006/03/02/running-as-limited-user-the-easy-way.aspx

The caveat is, as Russinovich states "There are some limitations, however:
because the limited-user processes are running in the same account and on
the same desktop as other processes running with administrative privileges,
sophisticated malware could potentially inject themselves into more
privileged processes or remotely control them using Windows messages. "


Can I get a process token and use AdjustTokenPrivileges in a way that
would violate any
protection? Again, assume I am *not* running with admin privileges.

In general, you can only adjust your privileges to the maximum extent of the
privileges of your account. If the account is a limited user account without
any additional privileges such as SeImpersonatePrivilege, barring any
administrative mishaps or bugs in the security subsystem, you shouldn't be
able to increase the privileges of your token.

With that being said, it would be naive to think that all the security flaws
found in Windows over the years were a result of the Win32 API behaving as
advertised!


I saw this issue raised in a paper I'm reviewing. I don't have time to
create the test
example (I'm up to my ears in a new project), so if anyone knows the
answer, or where to
find a definitive statement, I'd appreciate it (the idea is not central to
the paper, but
I'd like to tell the authors if they've made unwarranted assumptions that
would not be
viable under UAC, or perhaps already don't work if you are not the owner
of the .exe or
running as an administrator)


Hopefully the links I have provided my help you.

-Pete


.

Relevant Pages

  • Re: Security - Permissions Configuration
    ... >permissions to principals and not only codebases with Java Policy Files. ... different philosophies to the implementation of security. ... being) .NET does not duplicate Windows Security. ... While privileges are associated with an account or windows ...
    (microsoft.public.dotnet.general)
  • Re: Of mice and men
    ... Security does *NOT* depend on my users at all. ... the traditional Unix file security mechanism is Discretionary Access ... Windows not derived from NT don't count - they're essentially single- ... under reduced privileges and only elevating privileges when required. ...
    (comp.lang.cobol)
  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... >>>From the Orange Book documentation on C2 security ... >> work as claimed in the system documentation. ... >>developer made a call in his program that turned all privileges off. ... incoming windows messages. ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... >>>From the Orange Book documentation on C2 security ... >> work as claimed in the system documentation. ... >>developer made a call in his program that turned all privileges off. ... incoming windows messages. ...
    (comp.security.misc)
  • Re: removing "my computer" icon from limited account
    ... a limited user should not be able to what your son is doing. ... you wanting to limit access to specific programs, I think that there may be ... called "Doug's Windows XP Security Console." ...
    (microsoft.public.windowsxp.customize)
Loading