Re: Desktop Creation

Thanks for your reply. I read the book 'Writing Secure Code', second edition
(Michael Howard and David Leblanc) and when I develop an application I take
care about security. For instance, when I create any resource, I put always
the correct ACL. When I open a resource, I specify only the permission access
that I need. I use impersonation when it is necessary and restricted token
for risked operations. If I must store a secret I use CryptProtectData() API.
If I must retrieve a password, I use CredUIPromptForCredentials() API and
store the password in a SecureString.

But I don't understand what the resource creation is a potential security
risk. For instance, LSA process create some security tokens but do not use
this tokens. LSA create the token which is used for a process as primary
token or for a thread impersonation. LSA just create a resource but do not
use this resource. Winlgon creates three desktops but use only the secure
desktop and not the default. Create a resource for another process and not
use this resource is not a potential risk. I can create a file, a pipe, ...
but if I do not read/write/... this resources, no security risk can happen.
This is true that, when you create a resource (an object), you get a handle
on this resource with full access. But if you close the handle after creation
without any others operations, nothing can happen.

But with the deskop creation, it is a bit different. In fact, the API
CreateDekstop() use the attached window station of the processus that call
the API. In others words, I you want to create a deskop on a specific window
station, you have to 'impersonate' this window station. Perhaps that a
CreateDeskopEx() API with the handle of the window station could avoid this
'impersonation'. But after have created the desktop, your process should use
SetThreadDesktop() to attach it. If the process do not call this API, the
process is not attached with the desktop. This is the reason for which the
desktop creation in another window station or another session is not, for me,
a potential security risk.

Thanks for your response and the time that you give to me.

------------------------------------------------------------------------------------------

"David J. Craig" wrote:

Your statement only gives one small piece of the security picture. Your
service that runs using system credentials must check what it is given. It
must be written with security principles as the first priority. Depending
upon how the user application requests assistance from the service, it is
possible for the service to know which program made the call. The service
could run a check on the application to validate the digital signature of
the executable and not allow the 'open' to succeed if it fails. Some of
this might require a driver to provide assistance.

The reason for no desktop window access by services is that an unsecured
desktop is providing input and output for a service running with high
permissions. The major AV companies have fixed this long ago and it sure
isn't that difficult. It just takes time to examine all the use cases and
implement it with security in mind. The more secure you make your software,
the better for your customer. You don't want your product on one of the
major security sites as having major issues. If your product is intended
for the home consumer market it might not be fatal, but for enterprise
software it could lead to loss of sales and current customers dumping your
product.

There are no 'bad' messages, just bad code handling the messages. Malformed
data streams can occur from attacks or even hardware failures. It isn't
easy to test for everything, but a touch of paranoia is a good thing.

"Remember that just because I am paranoid, it doesn't mean the whole world
is not out to get me!", is one of my favorite sayings. Writing software in
today's environment where more and more we depend upon computers to assist
in banking and other financial matters means that those who would steal our
money have new attack vectors. It also means they have to worry less about
guards with guns that will try and prevent them from obtaining the money
they covet. If you can steal someone's money from thousands of miles away,
it lowers the risk for the thief. Luckily most thieves are not that bright,
but there are those who will target whoever they can find.

Paranoia is the missing vocabulary word in computer training.

"BT" <BT@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:512392EA-BD66-415A-AD65-92E574E5DCC9@xxxxxxxxxxxxxxxx
Ok, I should understand that I have to create another process running in
session 1 and communicate with an IPC with the SYSTEM service. But if my
other process running in session 1 and attached to interactive dektop
(dektop
of WinSta0), then this process can be attacked by 'virus' programs as my
service. I don't undestand what this solution is more secure because a
'virus' message can hack my process and send a 'bad' message to my
service. I
known very well the internal securty of NT as I known the internal
serurity
of VMS (remender that David N. Cutler, one of the core Ingineer of NT
kernel
worked before for Digital). I think that vista evolution has not create
the
API evolution. More, the real problem in thie security problem is that all
messages in NT do not contains the source, aka the mouse click of a user
is
the same message as the PostMessage(...) API from another process. But he
mouse click comes from kernel and the PostMessage() aPI come from API. To
have a real seurity, the message should contains the source of message
(kernel or user process).

Thanks very much but I will find a solution to workround this problem.

"Chuck Chopp" wrote:

I think that you're missing the point.

Microsoft separate the interactive sessions [Session ID > 0] from the
native
NT service session [Session ID 0] for purposes of tightening up security.
In the Word document that Microsoft published about this, titled "Impact
of
Session 0 Isoloation on Services & Drivers in Windows Vista", they made
it
extremely clear what you can and cannot do w/respect to a service opening
a
window on the desktop of an interactive windowstation.

http://www.microsoft.com/whdc/system/vista/services.mspx

http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Session0_Vista.doc

What you're trying to do is exactly what Microsoft is making changes to
prevent from happening.

The recommended way of having a service interact with an interactive user
session is to have a client application running in the context of the
user,
where the client application communicates with the service via some sort
of
IPC mechanism, such as a named pipe, a TCP socket, an RPC call, etc....



BT wrote:
The vista documentation say that all process running in SYSTEM context
(and
in session 0) can not attach to any station on another session. Why,
because
another program could inject code by message system. If a SYSTEM
process must
send a notification, the only API is WTSSendMessage(). If SYSTEM must
intecract with user, it have to do with another process running in
least
privileged security context and on the interactive session and
communicate,
for instance, with a pipe correctly ACLed.
But what I try to do it very different. My SYSTEM process must simply
create
a new process with a different security context and on another desktop
that
'Default' on the intercative session 1. For that, my SYSTEM process use
the
API CreateProcessAsUser with the token handle of security principal and
should specify the new desktop ('Winsta0\MyDesktop').

To do that, my SYSTEM service should only create the desktop and not
attach
to it. I do not seen any security risk to simply create an 'object' and
attach it to another process. The only risk in the process creation is
to
take care that specify FALSE for the 'bInheritHandles' parameter of
CreateProcessAsUser API.

What to do that ? Because the process that is created by SYSTYEM
process
must run on another desktop that 'Default' for the same reasons that
all
SYSTEM process run on different station that 'intercative' process.

Thanks for your quick response. Perhaps that the response is in the new
API
of the winsta.dll of Vista but still undocumented.

Best regards.
Bernard Tollet.

"David J. Craig" wrote:


I would suggest you look at the documents released on Vista. What you
want
to do is prohibited, unadvisable, and dangerous. The OS finally stops
it.

"BT" <BT@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:850C84E0-B978-48AE-8B3F-07A9A82937F7@xxxxxxxxxxxxxxxx

Ok, the problem happens only on Vista (tested on XP, XP SP1, XP SP2
and
Windows Server 2003).
My version of Vista is Vista Ultimate English.

I use Visual Studio 2005 Pro in C#.

The problem is the following. I have a service started by SCM
(services.exe)
which have to launch a GUI application with a different security
context
and
attached on a new deskop of the interactive window station (WinSta0).
First,
I logon the user with LsaLogonUser() API and after I have to create
the
new
desktop. As my service runs without interactive desktop, I open the
WinSta0
(OpenWindowStation), 'impersonate' my service using
SetWindowStationProcess()
and use CreateDekstop() to create a desktop. The impersonation must be
done
because CreateDesktop has not parameter for window station :

HDESK CreateDesktop(
LPCTSTR lpszDesktop,
LPCTSTR lpszDevice,
LPDEVMODE pDevmode,
DWORD dwFlags,
ACCESS_MASK dwDesiredAccess,
LPSECURITY_ATTRIBUTES lpsa
);

Win32k.sys use internally the window station attached to current
process.
After have created the desktop, I launch the GUI process with
CreateProsessAsUser and specify the newly created desktop. That works
very
fine on old NT kernel (XP, 2003, ...). But with Vista, the service
runs in
another session (Session ID 0). The session is not depend on process
but
security context (aka, token attached to the process). As no API
exists to
create a deskop in a specific session, I tried to change the session
Id of
the service process token (SYSTEM) after have duplicate it. But this
means
failed (using SetTokenInformation with TokenSessionId parameter). I
also
tried to impersonate a logged user but without good results. My
question
is
simple : how a process which runs in Session N can create a desktop in
another session M ? A workaround is, from the service (Session N), to
create
a process with a security context associated with the session M and
delegate
to this new process the desktop creation. But this is strange that no
API
exists to create a desktop in another session.

Do not hesitate to ask me for more informations.
Thanks very much for you response.

Best regards.

"David J. Craig" wrote:


Restate your problem. Include minor details such as compiler used,
SDK
version, OS (including 32 or 64 bit), and how the process is created.

"BT" <BT@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:71ACD29C-0EB1-43A2-8193-2DD42890DF74@xxxxxxxxxxxxxxxx

Thanks for you response, but it just works when a process A start
another
process B in another desktop but in the same session. If session is
different, it is impossible to create a desktop in the WinSta0 of
the
other
session. The OpenWindowStation() does not work to open station on
another
session, event if object manager namespace like name '<depend on
system>\Session 1\WinSta0' is used.

Sorry, but this response dos not answer to my question.
Thanks very much for your response.

"Kellie Fitton" wrote:


On Sep 13, 9:58 am, BT <B...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

From a processus running in SYSTEM security context and Session 0,
how
can I
create a desktop on another Session. It seems that API like
OpenWindowStation() and CreateDekstop() apply always on the
processus
session
even if a duplicated secuirty token with other session number is
used
as
impersonation. For instance, I use a security token with session 1
but
desktop creation continue to apply on session 0. Create a new
deskop
and ACL
it from session 0 to another session is not a potential security
risk.

If this question is out of subject here, could you tell me where I
can
post
this question.

Thanks.


Hi,

The following weblink should give you some pointers:

http://msdn2.microsoft.com/en-us/library/Aa379608.aspx

Kellie.












.

Relevant Pages

  • Re: Desktop Creation
    ... Your statement only gives one small piece of the security picture. ... The reason for no desktop window access by services is that an unsecured ... session 1 and communicate with an IPC with the SYSTEM service. ... API evolution. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Desktop Creation
    ... NT service session for purposes of tightening up security. ... If a SYSTEM process must send a notification, the only API is WTSSendMessage. ... If SYSTEM must intecract with user, it have to do with another process running in least privileged security context and on the interactive session and communicate, for instance, with a pipe correctly ACLed. ... My SYSTEM process must simply create a new process with a different security context and on another desktop that 'Default' on the intercative session 1. ...
    (microsoft.public.win32.programmer.kernel)
  • [UNIX] TWiki Arbitrary Code Execution in Session Files
    ... Get your security news from a reliable source. ... TWiki Arbitrary Code Execution in Session Files ... or via an HTTP vulnerability of a third party web application. ...
    (Securiteam)
  • Re: Login in dynamically
    ... different from or nothing to do with the provisions of Access ULS. ... I mean, there's enough damn security permissions to set, how many do you want ... security as per transaction and not per application session. ...
    (microsoft.public.access.security)
  • Re: Web session tracking security prob. Vulnerable: IIS and ColdFusion (maybe others)
    ... IIS and ColdFusion ... Because we perceive this as a security problem, our intent is to be wary of any web application that relies on IIS' session tracking. ...
    (Vuln-Dev)