... by leaving a message for Intuit's Quicken application (which many
people use to manage their finances), if the Trojan-horse ActiveX
control finds Qucken installed.
But, this is boring. ActiveX controls are x86 machine code which is
taken off the net and run; they can basically do anything at all to
the user's machine (and anything else to which the user has access)
after that. So, you can write a program that makes Quicken send money
to a named third party. Well, you can write a program to do a lot of
things.
What's more interesting are the interactions between this scenario,
and Microsoft's gesture towards "security" for ActiveX. This gesture
is to support code-signing --- meaning that you can instruct the
browser to treat some arbitrary byte-stream off the net as trusted
machine code only if it has been cryptographically signed by one of a
set of trusted authorities. The idea is that the users are supposed
to trust the signatories to look over the code, and make sure that it
only does *safe* things (and doesn't, say, rifle their bank accounts).
However, if one of those authorities ever signs buggy code, that code
(and signature) can be used by a malicious third party. And therein
lie the truly *interesting* possibilities.
For instance, suppose that TechnOstrich, Inc. is in some user's set of
trusted authorities, and they sign an ActiveX control which reads some
files on the users' local disks, spits the data over the net, and
maybe even writes some stuff back on the disks --- perhaps something
as simple as a preferences file. (An ActiveX control implementing
some sort of collaborative conferencing tool might be a lot more
active than even this, but let's keep thing simple).
However, the ActiveX code may or may not take precautions to see that
it only reads and writes stuff on the local disk that it was really
meant to see --- and it is up to the ActiveX control to make all those
checks, as it runs with the full privilege of the user running the
browser. If TechnOstrich forgot about this, and didn't add the
checks, then a malicious third party --- say, badunov.com --- who got
their hands on the signed ActiveX control could:
*) Put the control on their own pages, and...
*) Give it an *environment* that causes it to misbehave. For
instance, they could declare autoexec.bat to be the location of
the preferences file, and use this to cause the computer to
misbehave in any number of "useful" ways on the next reboot. Or,
they could screw up the configuration in such a way that the
user's private information from the Quicken database is treated
as preferences data and sent to badunov.com in order to, ermmm.
optimize display parameters. (Further possibilities are left to
the reader's imagination).
Once the users who trust TechnOstrich hit these pages, they're screwed.
A few things are noteworthy about this scenario:
*) It doesn't matter whether TechnOstrich's *own* use of the buggy
control is entirely benign. Before signing it, if they want to
be conscientious about it, they have to make sure that no
malicious third party, no matter how determined and resourceful,
can *make* it misbehave. This is a tall order, particularly if
the control is meant to interact in nontrivial ways with VBscript
on the same HTML page (something Microsoft seems to encourage ---
note that VBscript interacting with an ActiveX control is not,
itself, subjected to any kind of a signature test).
*) If TechnOstrich does screw up, and sign a buggy control even
once, it becomes unsafe to trust any other control signed by
TechnOstrich, ever.
What makes this particularly interesting to me is a RISKS item from
volume 18, issue 61, by Richard Smith, which appeared Nov. 11, and
which claims that he's found a number of signed controls with
potentially nasty behavior "in the wild"; among the problems listed
are "save file" functions which can be used by VBScript on the same
HTML page to cause the ActiveX control to save a file anyplace. I've
seen no response to the item from Microsoft in RISKS; it's possible,
but unlikely, that I missed something.
BTW, I remember hearing that IE3.0 did not allow you to disable
ActiveX controls signed by Microsoft itself by any means short of
disabling ActiveX completely. Perhaps our Microsoft mole knows better,
though. NB that at least one of the ActiveX controls cited by Smith
--- an animation player which can easily be made to crash the client's
machine --- was in fact written, and presumably signed, by Microsoft
itself. (FWIW, I haven't yet heard of any Microsoft-signed control
that can be used by a malicious third party for an attack nastier than
denial-of-service, but as I said above, it only takes one).
rst