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

From: david20@alpha1.mdx.ac.uk
Date: 08/26/02 

From: david20@alpha1.mdx.ac.uk
Date: Mon, 26 Aug 2002 18:04:38 +0000 (UTC)

In article <Q0t99.941$gs1.105988194@newssvr30.news.prodigy.com>, alun@texis.com (Alun Jones) writes:
>In article <ak5kaj$ju8$1@aquila.mdx.ac.uk>, david20@alpha2.mdx.ac.uk wrote:
>>>From the Orange Book documentation on C2 security
>>(http://www.radium.ncsc.mail/tpep/library/rainbow/5200.28-STD#HDR2.2.3)
>>
>>"
>>2.2.3.2.1 Security Testing
>>
>> The security mechanisms of the APD system shall be tested and found to
>> work as claimed in the system documentation. Testing shall be done to
>> assure that there are no obvious ways for an unauthorized user to bypass
>> or otherwise defeat the security mechanisms of the TCB. Testing shall
>> also include a search for obvious flaws that would allow violation of
>> resource isolation, or that would permit unauthorized access to the audit
>> or authentication data. (See the Security Testing guidelines)
>>
>>"
>>
>>The argument that the flaw is documented and it is upto the application writer
>>to be aware of this and take action in his programs does not wash.
>>Imagine an OS where it is documented that by compiling and linking an
>>application it was automatically given full privileges unless the application
>>developer made a call in his program that turned all privileges off.
>>That system could not be called secure and given a C2 security classification
>>even if all the programs running on the system as it was being evaluated had
>>been written to make that call.
>
>That may be so - but I don't see how your claimed analogy matches. Your
>proposed system will be marked as unsecure, because there is a point in the
>execution of the program where it has elevated privileges - a modification of
>the executable will automatically elevated your privileges. The system under
>discussion, or particularly, the flaw under discussion, does not present the
>same way.
>

I do apologise for not making clear that I expected that hypothetical turn-off
privs call to be made as the first call in the program ie before any windows
were opened, input accepted etc. This is very similar to one of the "solutions"
suggested where each application would have to set itself up to handle the
incoming windows messages. If it did it after the window was opened then there
would be a small period where the windows message would be handled by the
default library.

The fact that a program at some point in its execution has elevated privileges
is not in itself proof of the insecurity of that program or system.

Hence I still regard this as a valid analogy.

  
>In the "shatter" attack, there is a process running with elevated privileges
>that has used those elevated privileges to make itself vulnerable to unchecked
>user input - the Windows message queue, and the default window procedure.
>
>It has used its system privileges to cross the security border that is defined
>between system services and the user's desktop. It is well known, and well
>documented, that the desktop/workstation _is_ the security boundary. An
>application whose programmers choose to deliberately cross a security boundary
>without adding any extra checks (though I'm not sure how feasible a task it
>would be to filter every window message for suitability sufficiently to
>provide operation of dialogs and controls) is a disaster waiting to happen.
>

So you are asking the application programmer to fix something which you are not
even sure it is feasible for him to fix !!
One of your later messages shows just how well documented this security
boundary is :-

">>Windows is (currently) written around the desktop as the security barrier -
>>anyone programming secure services on Windows should already know that.
>
>Is this documented anywhere? Is there a good central place for principles
>like this one that (it seems) underlie the design of the Windows security
>architecture?

No - developer documentation is one place where Microsoft falls down
frequently over the last several years.
.
.
.
However, in answer to your question as to the desktop being the security
boundary between the user and the rest of the system, there's a very quick and
simple note in the documentation for SetProcessWindowStation (it's one of the
three sentences that describes the function's purpose):

"All subsequent operations on the window station use the access rights granted
to [the new window station]"

The same phrase, directed at desktops instead of window stations, appears as
one of the two sentences that describes the purpose of SetThreadDesktop.

It could do better, perhaps, but it's also obvious that this is an environment
where any process with write access to the desktop object can send any message
to any other process whose windows message queue is attached to that desktop,
and that there is no means provided for an application to determine the source

or validity of any of these messages.

Of course, a developer who's on the ball would be on the lookout for other
programming articles that discuss security. Only recently, another article
was published on the MSDN web site about this topic - I've linked to it
already, but here it is again:
<http://msdn.microsoft.com/library/default.
asp?url=/library/en-us/dncode/html/secure08192002.asp>

Alun.
~~~

"

Even if this were well documented this does not excuse this design fault.
The desktop should be insecure only in the sense that the user could go away
for a coffee and someone else could then start typing in keystrokes to
applications he had left running. The fact you have privileged and unprivileged
applications running with windows on the desktop should not matter.
The OS should maintain segregation of those applications. That is one of the
main functions of a secure OS.
 

>XP may or may not be a C2-securable operating system. This particular
>exposure doesn't indicate that in either direction, at least against the
>documentation you've posted (heck, I haven't read the whole C2 documentation -
>it may say "no system can be C2 secure if it uses the desktop/workstation as a
>security boundary", but then again NT 3.51 wouldn't have gotten through).
>
>But, since this behaviour of the operating system was in NT 3.51 (and versions
>before, and after), what you're saying is that the certification of NT 3.51 as
>C2 secure was incorrect. Perhaps the people that did the certification could
>tell us whether you're right or not?

The people who did the certification are only human. They missed this.
But yes if this behaviour is in NT 3.51 then IMHO it should not have been
certified.

David Webb
VMS and Unix team leader
CCSS
Middlesex University

>
>Alun.
>~~~~
>
>[Please don't email posters, if a Usenet response is appropriate.]
>--
>Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at
>1602 Harvest Moon Place | http://www.wftpd.com or email alun@texis.com
>Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to
>Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for XP/2000/NT.

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: Process security
    ... the WIndows security API set. ... The following article discusses some various privileges and how they can be ... and the user is running as a limited user without ...
    (microsoft.public.vc.mfc)
  • 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.security.misc)
  • 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. ... (See the Security Testing guidelines) ... >developer made a call in his program that turned all privileges off. ...
    (comp.security.misc)