Re: Win32 vulnerability? Or application vulnerability?

From: Thomas Dullien (dullien@GMX.DE)
Date: 09/08/02


Date:         Sun, 8 Sep 2002 10:31:30 +0200
From: Thomas Dullien <dullien@GMX.DE>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Hey Chris, all,

CP> Let me point out some other attacks you can use these techniques for,
CP> so that you understand fully what I'm saying here.
CP> The scenario: A user has a Windows 2000 box running a personal
CP> firewall. The firewall only "trusts" Internet Explorer to access the
CP> Internet.
CP> Somehow or other, some malicious code gets onto the system. It fires
CP> up an IE window, and makes it invisible. It injects a DDoS client (or
CP> whatever) into IE, using exactly the same technique described in my
CP> paper. That malicious code within IE then accesses the network
CP> freely, since the personal firewall can't tell the difference. It
CP> could even send out its traffic as legitimate HTTP requests, so that
CP> it is more or less untraceable.

This is not a vulnerability. If it was, one would need to immediately
remove OpenProcess(), DebugActiveProcess(), ReadProcessMemory(),
WriteProcessMemory() from the Win32 API, and ptrace() and procfs from
all *NIX implementations.

Under NT, priviledged processes should not be debuggable/openable from
non-priviledged code, and they should not accept windows messages
(thus not interact with the user desktop).

Your point about DDE and a bunch of other services being vulnerable is
good, but please refrain from announcing this as a "new bugclass" --
Dildog has worked on this back in 2000 (see his paper on Still Image
Service). It is "checking user input", nothing else.

And the fact that DeviceIoControl() can be oftentimes used to corrupt
kernel memory in bad drivers has already been mentioned.

It all boils down to a very simple thing: Closed source software input
checking sucks for the most part. For network daemons, the vendors are
slowly cluing up and checking properly, but localhost security on
closed-source platforms is more or less doomed due to many many
different components which have undergone very little scrutinity.
(who hasn't had a malfunctioning device driver bluescreen his NT box
yet ? )

And a general note: Whenever anyone finds something _really_ exciting:
Before writing a whitepaper and claiming a new "discovery", please
make sure you're not re-hashing something old without giving credit. A
simple google search for "postmessage exploit" would've turned up the
@stake advisory. And one has to give credit where it is due.

Cheers,
dullien@gmx.de
PS: Just because almost every RPC service has been/is buggy, doesn't
make RPC as a method "irredeemably broken"



Relevant Pages

  • Re: Win32 vulnerability? Or application vulnerability?
    ... The firewall only "trusts" Internet Explorer to access the ... some malicious code gets onto the system. ... I agree that localsystem windows running on the desktop are not ...
    (NT-Bugtraq)
  • Re: Zune installation experience
    ... the internals of Windows really are as bad as the externals, ... programming techniques. ... Development (RAD) published by Microsoft and endorsed as the Microsoft way ...
    (uk.comp.sys.mac)
  • Re: Corollas, Not Maseratis (Re: Whose Fish?)
    ... I done/do Windows development among others and in my opinion ... especially the current Windows OO architectural, and programming ... It is rare to hear techies claim that the MS Windows GUI framework is ... techniques. ...
    (comp.object)
  • Re: There is no market for a Delphi for .NET compiler
    ... But those in the Windows world are using ASP.NET? ... Data collection and transmission is a big deal - but it can usually be done ... interop techniques that will be better than others. ...
    (borland.public.delphi.non-technical)
  • Re: User account control
    ... I have heard that messing about with the BIOS could be ... Will your techniques well equally well? ... Windows you are running Windows. ...
    (microsoft.public.windowsxp.general)