Re: Privilege-escalation attacks on NT-based Windows are unfixable

From: David Hopwood (david.hopwood@zetnet.co.uk)
Date: 08/22/02 

Date: Thu, 22 Aug 2002 03:40:39 +0000
From: David Hopwood <david.hopwood@zetnet.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----

Alun Jones wrote:
> Edward Elliott <nobody@127.0.0.1> wrote:
> >If I understand correctly, it's not even possible to program defensively
> >against the Windows messaging exploit in question. The OS doesn't pass
> >any information about the source of messages. The application has no
> >way to distinguish a message from Admin and a message from JoeUser. A
> >setuid unix program can at least check the owner and permissions on a
> >file or set its own signal handlers.
>
> Sure it's possible. The application, since it's the one with the privilege,
> needs to make certain of its inputs. This is no different when the input is a
> Windows message queue than it is when the input is something sent over a
> network line, typed at a keyboard, or read from a file. You are correct in
> that the OS provides no information about message source to the application,
> but you are wrong in your conclusion that the application has no way to
> distinguish between messages from a privileged source and those from any other
> source -

If the OS doesn't provide any information about message source, how is the app
supposed to know? The OS kernel is the only component that can reliably provide
information about privilege levels. If we were talking about newly defined
message protocols, then there might be at least a possibility of rectifying
this problem, but we're not.

> again, it is the application that is privileged, it is the
> application that must pass and verify information validating its inputs.

No. The message protocols for GUI objects are fixed; the privileged app
can't require that the kernel pass some extra information that distinguishes
it from an unprivileged app. Also note that if Chris Paget's article is
correct, there are apparently some messages that the app doesn't have any
opportunity to validate:

# The final message that we're going to make use of is WM_TIMER. This is a
# slightly odd and very dangerous message, since it can contain (as the second
# parameter) the address of a timer callback function. If this second parameter
# is non-zero, execution will jump to the location it specifies. Yes, you read
# that right; you can send any window a WM_TIMER message with a non-zero second
# parameter (the first is a timer ID) and execution jumps to that address. As
# far as I know, the message doesn't even go into the message queue, so the
# application doesn't even have the chance to ignore it. Silly, silly, silly...

(I'm actually a little skeptical that there are messages that don't go into
the message queue, but I can well believe that it would be difficult to do
strict filtering of messages and still use any of the Windows common controls.)
 
> If there is no way for the application to communicate securely between its
> service component and its desktop component through Windows messages, then
> this simply says that the application must choose another avenue of
> communication that it can secure.

You seem to have completely missed the point. What I said in my original
post was:

  [...] it is impossible in principle on Windows {NT,2000,XP,CE} for any
  process that has a window on the desktop (including invisible windows)
  to protect itself from any other process running on the same machine,
  regardless of the privilege levels of either process.

You're saying that privileged processes should not have windows on the
desktop; they should communicate via IPC with an unprivileged process
instead (never mind that many privileged processes written by Microsoft
fail to do this). Fine, but that doesn't contradict the above statement,
and it also doesn't solve the problem: because the "desktop component" can
still be taken over, there's no way for the service component to require
that the unmodified desktop component is the only way to interact with it,
no matter what "validation" it does.

Also note that this approach at best only allows for two privilege levels.
If there are really only two non-equivalent privilege levels in NT, many of
the security APIs are ineffective and redundant. The original NT security
design based on VMS clearly wasn't intended to reduce to only two levels,
and it is disingenous for Microsoft or anyone else to try to claim that
this attack isn't the result of a design flaw.

Compare with, say, X-Windows, where it's perfectly possible to have windows
owned by processes with different privilege levels on the same desktop. If
by design, any process could simulate keystrokes in an xterm where the user
was logged into an administrative account, we'd consider X-Windows to be
hopelessly insecure and unfit for purpose.

- --
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPWRcczkCAxeYt5gVAQHF3ggAg5IXZ37lZKXb3MgY/4HNPRO6sB5O1LX8
SJx11LKT0mEALy7W195IsuIExSI1sMxwaIBUpL6JN73EyLY8LM+9fSruqrYZ46+T
jcU7LpkV0IrNqvdRafzmSRmj3f7y78T8jDt6nYgAilsNv4ZWbbKU6bmjovB6do2f
1Jv4zX5eMWlHuTEnpA2xC76QGDZ3fMyKbCp6CDN5RYu8/zpDpKhfGZpmYUkLBbyk
d+cuE9/zVlcvHFx6KcOGMGSVyPJ4afUE/8gqTdr3A2Ymw0Mp0UMT5XzfwtJHR7R6
UwodX+7JyU9tctzboAJZE/5xiQlDiuGATgvIQc1jQYjTmwiTx5pNmw==
=DBnR
-----END PGP SIGNATURE-----

Relevant Pages

  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... >>against the Windows messaging exploit in question. ... The application, since it's the one with the privilege, ... > service component and its desktop component through Windows messages, ... regardless of the privilege levels of either process. ...
    (comp.security.misc)
  • Re: Security - Permissions Configuration
    ... the ones found in the "Internet" permission set. ... on the User level Security Policy and Machine level Security ... already has under Windows. ... But even that privilege can be denied. ...
    (microsoft.public.dotnet.general)
  • [VulnWatch] Pipe Filename Local Privilege Escalation FAQ
    ... Pipe Filename Local Privilege Escalation" that was published by ... The actual vulnerability is at the Windows NT/XP/2000 platform level, ... it is an attack vector. ...
    (VulnWatch)
  • Pipe Filename Local Privilege Escalation FAQ
    ... Pipe Filename Local Privilege Escalation" that was published by ... The actual vulnerability is at the Windows NT/XP/2000 platform level, ... it is an attack vector. ...
    (Bugtraq)
  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... a Windows message queue attached to the user's desktop. ... One simple way for an application to cripple the WM_TIMER attack would be to ... > regardless of the privilege levels of either process. ... competent, secure design. ...
    (comp.security.misc)