Re: [DotGNU]MS Exchange and .NET

[Rhys Weatherley]

Peter Waldschmidt wrote:

> There is a huge difference between ActiveX and .NET!  .NET uses
> verifiable bytecode similar to Java, so the execution engine can prove
> that there are no security violations (according to the rules set by the
> security configuration).  ActiveX is raw i386 code, which cannot be
> verified easily.

You are right that bytecode is different from native,
but they are still very similar.  Microsoft (finally)
realized that they needed a portable execution format
because Windows CE runs on non-i386 platforms.

> By the way, when is the last time you heard of a virus written in Java?

This is due not only to the bytecode nature, but also to the
Java class libraries.  Sun took great care not to plug in
native methods that may cause the system's security
to be compromised.

VBScript is actually a very secure language.  Because it
is script-based, it is compiled on the client, ensuring that
the runtime engine can filter out bad code while it is
being compiled.  Yet it has been used in countless
e-mail viruses over the last few years, causing large
amounts of havoc.

Why?  It's not the language that is a problem.  It is the
API's that Microsoft plugged into VBScript.  Only an
idiot would give a remote script access to address book
and e-mail transmission API's.  Yet that is what they
did, and the result has been horrendous.  If those API's
weren't there, the language would be safe.

The same would happen in Java if Sun accidently plugged
an unsafe API into the Java class library.  But they have
been careful.  Also, Sun's reference VM is open source
(sort of), allowing it to be reviewed by third parties to
find any accidental "API leaks".

Now let's look at IL.  It is not the same as Java, no
matter what the marketing FUD says.  There are extra
opcodes in the instruction set for accessing raw machine
pointers, circumventing the garbage collector, and for
calling arbitrary Windows API's in arbitrary DLL's.

To avoid problems, Microsoft has defined two main
execution modes: verifiable and unverifiable.  The
former is supposed to be Java-like, whereas the latter
has complete access to the entire system.  (The
system is actually a little more complicated because
of security permissions, but these two modes illustrate
the issue the best).

The problem is, how would we know if an unverifiable
API has "leaked" across to the verifiable side?  The
answer is, we can't.  Not with Microsoft's VM, because
the code is not open to public inspection.  If there is
only one such leaky API, viruses once again become
a concern.

Because Microsoft has provided so many ways to
get around verifiable code security, for interoperability
with older Windows code, the chance that there is a
leak is quite large.  As I poke around their system,
I am frightened at the number of places where they
abandon C# and drop down to the native level to
do things.  Native code isn't verifiable.

So yes, there will be viruses, because Microsoft will
not open source their engine, allowing the public to
help them make it secure.  Portable.NET will be open
to public inspection, of course, and so we have a better
chance to build a secure environment.

Cheers,

Rhys.