Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RE: How to proper use sendinput to a elevated window from a service

761 views
Skip to first unread message

Jeffrey Tan[MSFT]

unread,
Apr 2, 2007, 2:20:45 AM4/2/07
to
Hi,

Yes, elevated UI process runs under high IL level and the Vista UIPI
feature protects the high IL process windows from receiving
input(SendInput) from medium or low IL processes(non-elevated processes).
If you want to use SendInput to control the input of an elevated process
window, your calling process must also be elevated.

In Vista, the official documented way to elevate a process is only using
the shell API ShellExecute(Ex)(not CreateProcess or CreateProcessAsUser).
So your application must call ShellExecute(Ex) to launch a helper elevated
to call SendInput. Furthermore, due to Session 0 isolation, a service can
only use CreateProcessAsUser or CreateProcessWithLogonW(can not use
ShellExecute(Ex)) to specify the interactive desktop.

By combining all the above analysis and restrictions, I think there is no
direct way to spawn an elevated process from a windows service. We can only
first use CreateProcessAsUser or CreateProcessWithLogonW to spawn a
non-elevated process into the user session(interactive desktop). Then in
the non-elevated process, it may use ShellExecute(Ex) to spawn an elevated
process for the real task. Since the final elevated process runs under high
IL level, it can use SendInput to manipulate other elevated windows.

Yes, this may sound a little complex, however, due to the new security UAC
model, we have to input more effort to obey the rules.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.


Jeffrey Tan[MSFT]

unread,
Apr 3, 2007, 11:11:16 PM4/3/07
to
Hi,

Have you reviewed my reply to you? Does it make sense to you? If you still
need any help or have any concern, please feel free to tell me, thanks.

Rudi De Vos

unread,
Apr 5, 2007, 3:34:05 PM4/5/07
to
Thanks for the answer,

This is indeed the way i'm trying to do it, but the shellexecute(ex) still
have another issue.
When you shellexecute, the function does not return until you have pressed
the UAC OK (in the secure desktop).
To be able to press the UAC, the master application need to switch to the
secure desktop, this cause the shellexecute to exit.

The only way i found, is making a shortcut on the desktop, and start the
helper app
external (clicking).

You can close this, it's seems the UAC team has done anything to avoid
this...and possible any working solution would be locked in next update :(

I prerequisition of our software will be to disable UAC..

Rudi De Vos

unread,
Apr 6, 2007, 8:10:02 AM4/6/07
to
We try to make vnc back working in Vista.
This indeed include programmical dismissal of the UAC box, else it's hard to
remote
control anything. The problem is not dismissal of the popup, this can be
done programmical in an easy and proper way, the problem is that an elevated
application lock sendinput....
After you dismiss the popup, the elevated app become the forground app and
lock the remote access...unfortunable this happen after you elevated, the PC
is open
in full admin and elevated mode. The local user, who called for remote
support, get full acess while the admin is remote locked...

Disabling UAC is less risk then leaving a remote PC full open...
At this point, we need to recommend to disable UAC, until we find a proper way
to prevent is from locking remote access.

Unless UAC was also made to disable every remote control application, there
need
to exist a proper way of doing it...

requiring administrative privileges: This will not work, as you need to be
able to logon, app need to be start before logon, only possible from a
service and special
(manifest) privileges can not be used by services.

"Eric Perlin [MSFT]" wrote:

> If your goal was the auto-dismissal of the UAC dialog by code, then it was
> far from recommended in the first place...
> Why make it a pre-requisite that UAC be disabled?
> How is marking your application as requiring administrative privileges not
> sufficient?
> --

> This posting is provided "AS IS" with no warranties, and confers no rights.

> Eric Perlin [MSFT]

Jeffrey Tan[MSFT]

unread,
Apr 10, 2007, 4:40:00 AM4/10/07
to
Hi,

Sorry for the late response, I am taking sick leave at home yesterday.

I have no knowledge about VNC, can you tell me some context information
about it?

Based on my knowledge, programmatically dismissing UAC consent dialog is
not a possible option(it is protected in another secure desktop, also
consent.exe process is marked with system MIC level), can you tell me how
do you dismiss it programmatically?

After dismissing the consent dialog, why is your elevated application
blocking the remote access? I am not sure I understand the problem
completely.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

Rudi De Vos

unread,
Apr 11, 2007, 5:50:03 AM4/11/07
to
VNC is a remote control application, that clone the console desktop and allow
you
to remote logon and manage servers...

UAC consent dialog
Issue solved.
dismissing UAC consent dialog: Is possible, sendinput from the correct
desktop.
(helper app in secure desktop)

After you press OK, the elevated application is in foreground.
Unless you minimize ( via local keyboard) the elevated app, the sendinput
messages
are "eaten". Messages from non elevated (VNC) to elevated app is not allowed.
Issue solved
Play with the token and security, then CPAU start your app elevated.
Your elevated app can send messages to all.

Everything solved for me, VNC should be back working in a few weeks :)

Jeffrey Tan[MSFT]

unread,
Apr 12, 2007, 3:21:26 AM4/12/07
to
Hi,

Thank you for the feedback and information.

Although your problem is resolved, personally, I am very curious about your
solutions and technical details.

#1, Is the VNC application the service+SendInput.exe? What account and MIC
IL is the SendInput.exe? So the UAC dialog is prompted when the
SendInput.exe is trying to use ShellExecute to launch other application
elevated, yes? So your task is helping the end user to dismiss the UAC
dialog programmatically so that the elevation can be automatically, yes?

#2, UAC consent dialog.
Based on my knowledge, there are 2 walls to protect the UAC consent dialog:
secure desktop and UIPI. It seems that you(I assume it is the service
instead of sendinput.exe) have modified the DACL setting of the secure
desktop and allows your application to break the first wall. Then, can you
tell me how do you break the second wall? The UAC dialog process runs at
System UI IL level, which protects lower UI level applications from sending
input. Microsoft introduced this to prevent the shatter attack.

#3,

>Play with the token and security, then CPAU start your app elevated.
>Your elevated app can send messages to all.

Do you mean that your service mainpulate the token before calling CPAU so
that the SendInput.exe is started with elevated token and high IL level? If
so, there is one caveat: some system processes are started with System IL
level, so your elevated high IL level SendInput.exe still can not go
through the MIC checking. For example, you still can not read Winlogon.exe
or CSRSS.exe processes memory, because of NO_READ_UP policy on the process
object and the System IL level of process object.

Rudi De Vos

unread,
Apr 12, 2007, 9:04:03 AM4/12/07
to
OK, let try to clarify it better

VNC
VNC exist of a service and application.
(vnc_service.exe and winvnc.exe)
service= start winvnc.exe via CPAU in the correct session(1...9) and
desktop(default, winlogon)
winvnc.exe= Capture the screen (via biblt or mirror driver) and input mouse
and keyboard events. The winvnc.exe is connected via tcp with a viewer
runnning on anothyer PC.
http://www.uvnc.com

session0: run vnc_service.exe (system)
session1\deault\applications
session1\winlogon\logon and UAC dialog

logon and UAC dialog
The service temporal start a winvnc.exe (CPAU) instance in the secure
desktop (session1, desktop "winlogon"). This allow winvnc.exe to capture the
display and send events to other application runnning in this desktop.

applications
The service start winvnc.exe (CPAU) in the default desktop, this allow to
capture
the display and send event to all low and middle elevated level applications.

applications running elevated.
We don't need to access the memory, sendinput is the only function that need
to work.

Solution (1) : Create a seperate application, embed a manifest with uiaccess
set to yes, ( place it correct and sign the exe). When you start this
application ( manual or via shellexecute " never got it working with
shellexec) this application can send
events to all applications (uiaccess=yes).
Winvnc.exe and winvnc_helper.exe then need to exchange data via shared memory,
the sendinput data is placed on shared mem and read and executed by helper.

Solution (2): Let the service change the token to elevated high, then use CPAU
to start winvnc.exe. Winvnc is now runnning elevated and can send events to
all
desktop applications.
I guess System IL is not needed, or service start winvnc.exe with system IL,
but sendinput() work to all applications.

All exe are authenticode signed and cert is trusted, possible this have an
impact on
on the security protections.

Jeffrey Tan[MSFT]

unread,
Apr 13, 2007, 5:13:42 AM4/13/07
to
Hi,

Thanks for your detailed background information!

It appears much clear to me now. Yes, I agree that normally high IL with
elevated token is enough to send input to almost all of the UI
applications. But I am still a little confused with "logon and UAC dialog".
Yes, I see your service has broken the desktop boundary and created the
winvnc.exe in the secure desktop(the same desktop as UAC consent dialog).
However, based on my verification, UAC consent application will still run
at System IL level while winvnc.exe runs under high IL level, yes? Then I
suspect UIPI will prevent your simulated button click for the consent. Or
do you just manipulate the winvnc.exe token so that it also has System IL
level?

Anyway, the logic is interesting and similar to that AIS does :-). Thank
you for the sharing!

Rudi De Vos

unread,
Apr 13, 2007, 5:58:00 AM4/13/07
to
When a service start an application in another session and desktop, You use the
owner of that desktop to avoid security and access problems.

Default== logged user
Security== owner winlogon.exe process (System IL)

Just wondering, what's AIS ? If it does the same can it be used for it .


Jeffrey Tan[MSFT]

unread,
Apr 16, 2007, 3:02:24 AM4/16/07
to
Hi,

AIS is the "Application Information Service" which is the key service of
UAC elevation feature. While an application elevates throug ShellExecute
API, this API actually sends a RPC request to AIS. After getting this
request, AIS will invoke the consent.exe in the secure desktop for user
consent. And after the user consent, AIS will launch the elevation
application with the full admin token.

Thanks.

Jeffrey Tan[MSFT]

unread,
Apr 19, 2007, 12:00:06 AM4/19/07
to
Hi,

Oh, further research and discussion internally reveals my confusion. It
seems that Vista RTM does not use Desktop UI for the UIPI protection, it
will merely leverage the MIC IL level for the UIPI checking. However, to
enable some accessibility applications to manipulates all the UI processes,
we introduced UIAccess flag. If UIAccess is set to true in the token, it
will be allowed to bypass the UIPI checking. So your helper application in
the secure desktop is allowed to dismiss the UAC dialog, because it has
UIAccess=true.

Thank you again for sharing the result with us.

0 new messages