Here is a post I did to the webappsec mailing list which I is very
relevant to this newsgroups.

I also very interested if your comments about this issue.

Dinis

-------- Original Message --------
Subject: On sandboxes, and why you should care



[quoted text, click to view]

Hello Andrew,

As a response to your post, I will try to clarify why I believe that
Sandboxes are a fundamental piece in the security of Web Applications,
the hosting server(s) and the datacenter.

First of all, there are two issues with Verification. The first is
that you need verifiable code in both .Net and Java in order to run
that code in a Sandbox (Partial trust in .Net). The 2nd one is that if
you remove verification from the security benefits of .Net and Java,
and you admit that that is OK (which seems to be the current position
today), then you just eliminated some of the biggest security and
reliability features of these 'managed environments' (you also have
the problem that when (not if) you move your code to a secure sandbox
you will have many more problems to deal with (from performance to
unverifiable code issues))

[quoted text, click to view]

Really??? I am not so sure.

Lets look at some of your assets: The J2EE application, the supporting
database, the server(s) hosting your environment, the data center,
that companies internal network, the users (end-clients) and all users
(end-clients) that use all websites hosted in that data center (add to
this mix, items like: company public profile/confidence, customer's
private data, data privacy and SoX laws, and end up with a complex
multilayer mesh of assets)

Now, there are different levels of compromise here (I will just list some)

- J2EE application compromise
- Database compromise
- Web Server compromise
- Database server compromise
- Data center compromise

One of the main benefits of what I am defending (Sandboxing the
execution of code) is that you are able to dramatically limit the
damage created by (for example) malicious code executed on the
application's process space.

So for example, the damage of a file upload vulnerability (which
allows you to put a *.jsp file on the server and execute it) is
limited to the permissions allocated to the Sandbox.

The reality is that if you don't run that code with ANY sandbox, then
your entire Application, Server and Datacenter security is dependent
of the non existence of any malicious code in all applications running
on all web servers.

Also remember that more and more we will have to deal with malicious
developers, or with malicious attackers that are able to inject
malicious code into a website via:
- a library used by a developer
- a compromised developer account details (which tend to be sent by
email)
- a compromised developer computer (infected via Spyware) which
allows the malicious attacker to control remotely that computer and
(for example) path Eclipse or Visual Studio in memory so that every
time a piece of code its submitted (checked-in) , the malicious
payloads are inserted.

If you add up the number of people that have the capability to put one
line of malicious code on a web server, you will see that this is a
very large number indeed.

A couple more examples of ways malicious code can be uploaded to the
server: SQL Injection, XSS (payload deployed to the admin section),
authorization vulnerabilities which allow the editing of files on the
server (via for example the CMS (content management system)),
manipulating params which control which method is executed (when
Reflection is used to perform late binding on method calls based on
the commands received) ,Social engineering, etc...

Sometimes you will even find CMS (Content Management Systems) that
provide power users (or 'area x' admins) with powerful customization
features which when exploited (or not, depending if this is a
'feature') allow the injection of code.

Do you really think that it is a good idea to have your entire data
center security and CIA (Confidentiality, Integrity and Availability)
depended on such extraordinary set of circumstances?

So the first main security benefit that we have with using Sandboxes
is: Containment, Damage Limitation, and Risk Reduction (you went from
full data center compromise to a local and limited problem)

Note: the reason that I say data center compromise, is because most
(if not all) data centers (and even corporate networks) are not
designed to sustain an attack executed from inside (especially when
the malicious attacker as admin control over one server)

[quoted text, click to view]

Sure, but out of those 100, how many allow remote command execution or
upload of scripts to the server?

So ironically, you could find your self in a position where the first
thing you should do (from a security point of view) would be to
isolate that server/application so that a compromise of that
application is limited to that application's assets.
[quoted text, click to view]

Well that depends on what those issues are, but I agree with you that
converting existing applications designed to run outside a sandbox,
into 'Sandboxable' applications, is a massive project.

Also note that just turning on the verifier is not good enough. You
will need other protection layers.

What other Protection layers I am talking about? For example: "Offline
or realtime code profiling and analysis"

One of the reasons why I strongly believe that Full Trust code (and
the Java --noverify) should be verifiable, is because if it was, I
could analyse (offline and in real time) that code for security
problems and block its execution when malicious code is detected.

If the code is verifiable, I am able to make a series of security
decisions (with a high degree to certainty) based on the the 'risk
profile' of that code. For example: Does it make calls to unmanaged
code, does make calls to private members using reflection, does start
processes, etc...

If the code is not verifiable then It is as good as trying to analyse