[Techtalk] why is Active X in web pages evil, but not Perl/PHP/Javascript?

[Devdas Bhagat]

On 19/01/05 09:05 -0800, Carla Schroder wrote:
> hola techtalkers,
> 
> As the subject line says, why is Active X in web pages evil, but not 
> Perl/PHP/Javascript? I have some vague notions about operating system 
> architecture and being too friendly to remote code execution, but I would 
> appreciate some precise notions from people who know. 

To add in my 0.02 USD:

PHP is a server side scripting language. Perl is usually used on the
server (commonly as CGI, but there are mod_perl and mason). 

These extend the simple Server Side Include technniques and allow for a
significant amount of processing to be done on the server.
A browser typically parses HTML input (but with the help of helper
applications can handle other formats as well). 
A typical PHP or CGI script spits out some form of HTML (or nowadays
XHTML or XML) which is interpreted and parsed by the user agent.

Javascript, JSCript, ECMAscript [1], VBscript [2], etc are client side 
scripting technologies, i.e, they run in the context of the user agent. 
These parsers can take limited action, but only in sandboxes and in the
context of the user agent.

Under most circumstances, you will not find Perl in client side scripts.
IIRC, Perlscript exists, but it really hasn't become popular.

ActiveX is not a scripting technology, but more of an embedded plugin
technology. It is similar to Java applets, but it has far too much power.
Java applets run in a sandbox mode, and cannot directly access the
filesystem.
An ActiveX plugin is a bit of code which runs in the context of the user
and is not sandboxed. ActiveX plugins are bits of code which the user
agent downloads and executes on behalf of the user. Since the plugin is
not sandboxed, it can do anything that the user is authorised to do to
that system. This is used by a very large number of "web" applications,
which are basically activeX applications with a layer of HTML on top.

The reason why ActiveX is loathed and feared is that the trust model
that it depends on is flawed. Microsoft did not really understand how
hostile the Internet was as an operating environment. 
This was rather pervasive of their applications till recently.

Microsoft favours a trust model with centralised control of that trust.
This is typically known as the tree of trust, and is commonly seen in
the TLS world, with certificates and certificate authorities in
hierarchical order.

In this model, any node below the root trusts the node above it to do
its job right and verify and validate information given to it.
However, there were really no implemented provisions to deal with failure 
of a root node to perform its job correctly. 

This leads to a situation:

Malicious programmer writes ActiveX control. "Trusted" authority signs it
(for payment). Now, the user is automatically required to trust this CA
without being able to verify that the CA is really trustworthy. Hence,
the User Agent downloads and executes the ActiveX plugin on behalf of
the user. Given the freedom this plugin has, it can copy data from user
accessible folders, send email, format the hard disk, or anything else
that the user has privileges to do.

All this is done by just "viewing" a web page, which should have been a
commonplace, harmless activity.

To summarise, ActiveX changes the harmless activity of viewing a web
page into downloading and executing an unknown application on your
system with no way of being able to verify the code itself.
That lack of verifiability of the code, coupled with the lack of ability
for the user to choose an appropriate level of trust is what makes it so
truly dangerous.

I hope that this summarised the situation.

Devdas Bhagat

[1] Javascript, JScript and ECMAscript are similar, but slightly
different variations of the same scripting language, commonly grouped
together as Javascript. This results in browser specific scripts,
depending on the browser.

Javascript was the original Netscape proposed language.
Microsoft responded by changing some stuff, and handing it to the ECMA,
resulting in ECMAscript.
Netscape responded with JScript (IIRC).

This makes for critical differences in the languages supported by
Internet Explorer and Netscape/Mozilla and derivatives.

[2] VBscript is both client and server side scripting. The server side
VBscript is usually seen in Active Server Pages.