Win32 vulnerability? Or application vulnerability?

From: Steve Tibbett (stevex@JFLINC.COM)
Date: 08/08/02 

Date:         Thu, 8 Aug 2002 09:13:44 -0400
From: Steve Tibbett <stevex@JFLINC.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

>I have written a white paper documenting what I believe is the first
>public example of a new class of attacks against the Win32 API.

And what a lot of attention it's gotten. But why? The Win32 API
never promised or even hinted at security between windows
on the same desktop.

An HWND is also a public message port, with no inherent security. It's
like a TCP connection on Unix - it's up to the service on the receiving
end of the TCP connection to provide the security. Anyone can connect
to it.

Someone else pointed out that the right way to design an application
that needs both a UI and admin-level rights is to split it into two
parts: The trusted part and the non-trusted part. The non-trusted
part takes care of the GUI and uses an API like sockets or pipes to
talk to the service that's got admin rights.

Many desktop applications on Windows use messages sent to windows
as an IPC mechanism. Winamp, for example, suggests that you find
it's window and post messages to it, and they document what messages
to send.

This isn't something you can "fix" because it's not broken; it's
the assumption that there was any security there in the first place
that's broken. If you design your applciation right, where you don't
have GUI with admin rights in user space, then you never had a
problem. (This is how all the services that come with Windows work).

I wonder if an alert like "TCP ports vulernable to connection from
hostile processes" would get as much attention. Of course the TCP
connections aren't the problem, insecure services are - and in this
case it's the virus software that's at fault, not the API.

Why has this gotten so much attention? 

--
Steve Tibbett
stevex-ntbugtraq@oakburl.net

Relevant Pages

  • Re: bits 32 oddities in NASM
    ... extender or switch to pm yourself - and *then* dos interrupts won't work... ... stupid people who try to write DOS in Windows. ... without resorting to the C library or the evil Win32 API. ...
    (alt.lang.asm)
  • Re: Binding MFC dll onto .Net VC code because .net class never support
    ... ..NET *Compact* Framework is used on Windows Mobile and Windows CE devices, ... if you think about it; how big is the .NET Framework? ... Most of the Win32 API on Windows CE matches the Win32 API on the desktop. ... There's no way to 'bind MFC to managed code' and MFC is not a model for ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Force classic theme for application (windows)
    ... of the Win32 API, both documented and undocumented. ... which is able to defer some API functions to own custom made functions. ... involve a fair bit of detective work to figure out exactly how windows ...
    (microsoft.public.win32.programmer.ui)
  • Deeper look into Simulink RTWRTWinTarget
    ... Incompatibility with Win32 API Calls ... The Real-Time Windows Target kernel intercepts the interrupt from the ...
    (comp.soft-sys.matlab)