Re: Win32 vulnerability? Or application vulnerability?

From: Stephen D. B. Wolthusen (wolt@IGD.FHG.DE)
Date: 08/08/02


Date:         Thu, 8 Aug 2002 18:13:43 +0200
From: "Stephen D. B. Wolthusen" <wolt@IGD.FHG.DE>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Hi,

(crosspost to BugTraq, could be of interest)

Chris Paget <ivegotta@TOMBOM.CO.UK> writes:

> >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.
>
> The scenario: A user has a Windows 2000 box running a personal
> firewall. The firewall only "trusts" Internet Explorer to access the
> Internet.
>
> Somehow or other, some malicious code gets onto the system. It fires
> up an IE window, and makes it invisible. It injects a DDoS client (or
> whatever) into IE, using exactly the same technique described in my
> paper. That malicious code within IE then accesses the network
> freely, since the personal firewall can't tell the difference. It
> could even send out its traffic as legitimate HTTP requests, so that
> it is more or less untraceable.
[...]

Don't wan't to put Chris down, but this really sounds like a re-run of a
discussion that came up after Martin Carlisle and Scott Studer from USAFA
presented a paper at last year's West Point Information Assurance Workshop

(the paper's copyright IEEE, can be downloaded from

 http://www.itoc.usma.edu/Workshop/2001/Authors/Submitted_Abstracts/paperT1B1(24).pdf).

Different mechanism, same issue. It's not as if the design principles for
separation of duty and trusted components hadn't been known for more than
three decades.

Another dirty little ``secret'' of a number of drivers is that very little
checking is done regarding who or what calls IOCTLs, and parameter
validation is just as much a problem in kernelland as it is in
userland. This is something that gets mentioned here and there (e.g.\@ the
NT Insider newsletter published by OSR) and is part of what the DDK Driver
Verifier is testing for, but as usual the virtuous thing doesn't get done
because of Ship the Damn Thing Already(tm) or We'll Do That Later(tm).

Window messaging as used in NT is evil. Besides making security rather
difficult, it is one of the main reasons why NT doesn't scale all that well
on SMP machines.

Looking at the network code you'll see holdovers from the
cooperative multi``tasking'' days of Windows 3.x (not NT!) when window
messages were used as the basis for the tasking model. But since retaining
backward compatibility to the clever but hideous hack called WinSock was
more important than just about everything else...

--
        later,
        Stephen

Fraunhofer-IGD | mailto: Stephen Wolthusen | wolt@igd.fhg.de Fraunhoferstr. 5 | swolthusen@acm.org 64283 Darmstadt | swolthusen@ieee.org GERMANY | | Tel +49 (0) 6151 155 539 | Fax: +49 (0) 6151 155 499



Relevant Pages

  • Re: Win32 vulnerability? Or application vulnerability?
    ... The firewall only "trusts" Internet Explorer to access the ... some malicious code gets onto the system. ... >up an IE window, and makes it invisible. ...
    (NT-Bugtraq)
  • Re: xp firewall and what it should do.
    ... >> I have windows xp firewall enabled but continue to be ... >Internet popups (meaning they are in Internet Explorer ... >browser window with pure crap floating in it you did not ... >Open Network Connections ...
    (microsoft.public.windowsxp.security_admin)
  • Re: xp firewall and what it should do.
    ... > I have windows xp firewall enabled but continue to be ... That is an Internet Web PopUp.. ... browser window with pure crap floating in it you did not ask to see. ... To enable or disable Internet Connection Firewall ...
    (microsoft.public.windowsxp.security_admin)
  • Re: bug in outlook express
    ... original message was in Andrew Z. Carpenter's ... as my firewall is in place and the ... window warning of rpc doom detected. ... >Internet connection, and the messenger spam itself is ...
    (microsoft.public.security.virus)
  • Re: P2P Groups and LinkLocal Cloud
    ... Also, I did leave the windows open in the netsh test, and that did not seem to help. ... You did mention the firewall disabled. ... > found the first node. ... the first window also failed to find the first ...
    (microsoft.public.win32.programmer.networks)