Hi,

(crosspost to BugTraq, could be of interest)

Chris Paget <ivegottaTOMBOM.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              | woltigd.fhg.de
Fraunhoferstr. 5               | swolthusenacm.org
64283 Darmstadt                | swolthusenieee.org
GERMANY                        |
                               |
Tel +49 (0) 6151 155 539       | Fax: +49 (0) 6151 155 499

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]