Service interact with desktop

[zion]

Hi,

How can I force my service to interact with desktop on Vista OS?
In xp/2003 it's OK.

Thanks

 

[Guest]

Factor it into two components and build an RPC mechanism to communicate
between the two. This is part of the service hardening work that went into
Vista to protect the system from compromise from bad usermode applications.

If all you need is to show a dialog box on the interactive desktop then you
can use WTSSendMessage
(http://msdn2.microsoft.com/en-us/library/aa383842.aspx) to do that.

 

[Alun Jones]

How can I force my service to interact with desktop on Vista OS?
In xp/2003 it's OK.

You only _think_ it's okay in XP / 2003.

For several years now, Microsoft has been warning that this is a bad
feature, and that it will be deprecated in some future version of Windows.
Apparently, we are now living in the future that we were warned would come.

As to why this is a bad idea, here's one example:

http://en.wikipedia.org/wiki/Shatter_attack

The brief synopsis is that if a privileged process opens up a window on the
user's desktop, that's a hole punched through a security boundary, which
could be used to allow an exploit to elevate privilege quite easily (because
the window message queues were not designed to be a security boundary).

Jesper's suggestion to create your own RPC mechanism to communicate from
desktop to server and back hints at this; that you need to create a secure
means of allowing data to cross that security boundary.

Alun.
~~~~

 

[Guest]

Jesper,

Would splitting the service into a service and a COM local server will have
the same design that you suggested? Thanks

 

[cquirke (MVP Windows shell/user)]

You only _think_ it's okay in XP / 2003.

As in "It just works... unfortunately" ;-)

For several years now, Microsoft has been warning that this is a bad
feature, and that it will be deprecated in some future version of Windows.
Apparently, we are now living in the future that we were warned would come.

As to why this is a bad idea, here's one example:

http://en.wikipedia.org/wiki/Shatter_attack

Ah, what a good article!

A common pattern with design and exploits is that often MS sees the
minutiae of code as being the exploit, whereas one might see this as
the sharp tip of a bad design that thrusts this into harm's way.

The "tip" here would be that mesages passesd from a lower-priv process
to a haigher one can include callback addresses (a risk that also
applies to viewing a listing of .CPL files as Control Panel)

The "mountain" here is that high-priv processes are accepting messages
from arbitrary low-priv processes in the first place. With the tip
removed, there still exists the opportunity to deliver malformed
content to an exploitable surface within the high-priv process.

So it's good to see Vista tackling not just the tip - as MS's
immediate response had to be - but the entire design. When was the
new design finalized? I ask, because if these sands were still
shifting late into the Vista beta, it may explain why so many
tightly-coupled-to-hardware apps (Nero, fax modem bundleware) have
been so tardy in being updated to work with Vista.

"One of the reasons why this vulnerability existed in
Windows was because when a user logged in, the
first interactive user session logged in as Session 0,
the same session that the Windows services run in.
In Windows Vista, this changes."

The brief synopsis is that if a privileged process opens up a window on the
user's desktop, that's a hole punched through a security boundary, which
could be used to allow an exploit to elevate privilege quite easily (because
the window message queues were not designed to be a security boundary).

It's good to see an explanation of deep security design changes that
lie behind obvious impacts, such as UAC prompts that black out the
screen (as they have to, to block possible inter-process interaction
from one UI to the hi-priv UAC dialog box?).

Jesper's suggestion to create your own RPC mechanism to communicate from
desktop to server and back hints at this; that you need to create a secure
means of allowing data to cross that security boundary.

I may not have the background to understand the answers, but I've
often wondered about theb safety of RPC, and the wisdom of waving
networking services such as RPC and LSASS at the Internet with just a
firewall as a band-aid between them. Lovesan and Sasser come to mind.

I assume RPC formalizes what can pass between processes in ways that a
generic message queue does not, but how safe is it?

There's a generic problem that arises, in that:
- non-trivial code has bugs
- to be bug-free, keep your code trivial

What this means, is the choice between:
- trivial parameter verification that passes exploits through
- complex parameter verification that is itself an exploit surface

This applies to firewalls as much as anything else, e.g. Witty vs.
Black Ice Defender. Then again, the deep destination code can also be
an exploit surface, e.g. the ASN1 flaw. So, it's hard to stop the
baloon of possibilities bulging out somewhere, as you try to design a
box that will safely contain it ;-)