Microsoft does it again

[bogstad at pobox.com (Bill Bogstad)]

David Kramer wrote:
>On Tue, 6 Aug 2002, Bill Bogstad wrote:
>> So a command line overflow exploit in a setuid-root ps binary on a
>> UNIX machine is unimportant because you shouldn't ever let 'bad
>> people' have a login on your machine?  I thought security was about
>> being able to limit the resources that a user could access on a
>> machine even when they had some level of legal access.  You seem to be
>> advocating a security model of 'good' and 'bad' users where 'good
>> users' can do anything and 'bad users' can do nothing.  Maybe you
>> missed the part where this worked via terminal services as well.  You
>> don't need physical access, apparently you only need the equivalent of
>> a UNIX login.  I believe that any operating system vendor who claims
>> that something isn't a security issue because you have to have some
>> level of valid access to exploit it should be condemmed. PERIOD.
>
>OK, I should have been more explicit.  When you have a bad person sitting 
>in front of you WINDOWS computer, is what I meant.

I'm afraid I don't follow you.  The article clearly states that this
is exploitable even if you don't have physical access to the computer.
All you need is logical (Window's terminal server) access.  I agree
that physical access to the unit actually implementing the security
system means all bets are off.  Although what that means is subject
to discussion.  I don't think keyboard/mouse/monitor access is sufficient.
If I put you on the other end of long cables without access to the actual
CPU box that shouldn't automatically give you any more privileges then
if your access is via a network card.  

It would be interesting to know if this method lets you send messages
to windows in other people's active Windows terminal server sessions
or perhaps a login on the physical console.  Are the virtual GUI
environments actually seperate?  This is a two fold question:

1. Can you enumerate the windows handles for other people's windows?

2. If you have a windows handle for somebody elses window can you send
messages to it?

Even if #1 is false that doesn't make the problem go away.  It just
means that you have to start investigating how easy it is to guess
other peoples handles.  As an attacker, you really want to find
handles for windows attached to programs running as privileged users...

>And this was, at heart, not a buffer overflow exploit.  The security 
>hole is any program being able to talk to any other window as if it were 
>the operating system.  The buffer overflow was just one way he 
>showed to invoke the exploit, the main one not even needing the complexity 
>of a buffer overflow, just put a binary in memory somehow and pass
>WM_TIMER to execute it.  No buffer overflow needed.

Yup, no buffer overflow required.  I was just trying to come up with a
straightforward local only root exploit for UNIX which has occurred in
the past.  The issue is Microsoft's apparent claim that being in a
position to ATTEMPT to execute arbitrary instructions on a CPU
automatically means that security controls are no longer relevant.
The security bug that caused a controversy with HP recently (a way of
exploiting system calls under Tru64 Unix) wouldn't even be defined as
a bug anymore using this definition.

			     Bill Bogstad
			     bogstad at pobox.com