By default, the Verifier is disabled on .Net and Java

[leichter_jerrold at emc.com (leichter_jerrold at emc.com)]

| Kevin is correct, a type confusion attack will allow the bypass of the 
| security manager simply because via a type confusion attack you will be
able 
| to change what the security manager is 'seeing'....
| 
| So in an environment where you have a solid Security Policy (enforced by a

| Security Manager) but the verifier is NOT enabled, then to jump out of the

| sandbox all that you need to do is to create a Type Confusion exploit that

| allows you to access a private member that either: calls the protected 
| resource directly or disables the Security Manager (which based on the 
| description provided is the demo that I think Ed Felten did)....
| 
| I will stick to my guns and say that in a Virtual Machine environment like

| the JVM or CLR it doesn't make sense to have the overhead of a security 
| system (like CAS or Security Manager) if the verifier is disabled....
This is taking a bit too extreme a point of view.

The issue here is what's trusted, and for what purpose.  *Something* has
to be trusted.  The verifier, the security manager, the JVM - if you
can't trust these, you have no hope.

The Java/.Net defaults explicitly say:  (a) I trust the compiler not to
generate dangerous code; (b) I trust the local user not to put stuff
on the local disk where it can be executed unless it came from the
compiler and he trusts it; (c) I trust the OS to protect the stuff on
the local disk.  On the other hand, I *don't* trust stuff that comes
off the network.

Given the realities of the last 10 years of virus-like attacks, this
trust model may well be questionable.  But keep in mind that just
because a Java application passes every verification and is acceptable
to even a very strict security policy doesn't mean it isn't a trojan
horse at a higher semantic level!

Verifying bytecodes certainly blocks many attack vectors, and is a
fine idea - but things are not all black and white.  Runtime
checking will inherently cost you performance.  Someone will
always have an application where the extra cost is "too high"
relative to the risk of running unverified.

Rather than absolute statements about requiring verification
for all user-written code - while leaving it off for the
large volume of system-provided code - we need a more nuanced
view, a better way to quantify risks and costs and trade them
off.  Otherwise, the same forces that to this day argue that
Java is unacceptable because of the overhead of garbage
collection will continue to push for writing in completely
unsafe languages.
                                                        -- Jerry