Dinis,
Sandboxing prevents a machine from having bad system() and buffer
overflows causing system compromise. Sure that's bad enough. However,
sandboxing does not prevent:
* all types of cross-site scripting
* SQL injection
* Command injection via SQL injection (xp_cmdshell and similar Oracle
library calls)
* Command injection as the limited capabilities allowed by the
sandbox ... until the attacker can work out how to get out of the
sandbox, say via a friendly unpatched service or tunnelling terminal
services outbound, or similar
* LDAP injection
* XML injection
* authentication attacks, such as brute forcing etc
* failure of authorization code to protect controlled resources,
operations or transactions
* file operations on the files the app is authorized to touch, often
quite sensitive in themselves
* second order injections (ie batch integrity issues)
* middleware attacks
* web service attacks
* SMTP attacks - ie formmail.pl - if it's badly written, there's no
way a sandbox will help
* or the usual sorts of transactions which can lose a business money,
like ship X widgets to Y (phishing).
Sandboxing reduces but does not eliminate the risk that the app
server process can go ahead and destroy the rest of the box, which is
important in a shared environment. But if the attacker can run
arbitrary code on your host, it's just a matter of time before they
work out how to go from loading netcat to 0wning you. That's why
PHP's "safe" mode is not really all that safe and in fact, is more
than occasionally easier to 0wn than the normal way.
For example, look at the code that Microsoft suggests for users of
the SQL Server Reporting Services add-on:
http://support.microsoft.com/?kbid=842419
They recommend giving any SQL-calling code
PermissionState.Unrestricted access to the SQL server. Guess what?
The permission flood gates are now opened, and SQL injections are all
back if there's dynamically constructed queries in the code.
Plus, those instructions are so long winded, if that's what is
required for every assembly which asserts CAS permissions, there is
the reason it's not done. Developers are under the pump, and unless
it's easy, trivial and automatic, it will not be done.
Sandboxing and partial trust is a defense in depth mechanism that
solves a small subset of issues and has the potential to reduce
damage from other types of attack as long as keys to the kingdom are
not granted by the asserted permissions.
It would be nice if it was on by default and programmers used it, but
I'm not losing sleep over it. If I come across code which needs help
with cross-site scripting or injections or worse, a process which is
easy to conduct fraud with, I will fix that before telling them to
turn the verifier on or insert code to demand permissions from the
underlying CLR or VM.
thanks,
Andrew
On 24/05/2006, at 8:34 AM, Dinis Cruz wrote:
(sorry for the long time that it took for this response, see
comments inline)
Stephen de Vries wrote:
Hi Dinis,
I think you're overestimating the effectiveness of a sandbox in
preventing common web app vulnerabilities, and you're instead
focussing on the tiny fraction of specific attacks that can be
stopped with sandboxes.
Well Stephen, I would argue that you are underestimating that
effectiveness :)
I also don't think that I am focusing on a tiny fraction of
specific attacks. Sandboxes have the capability to resolve most of
the current types of attacks we have today. And the ones that it is
not able solve, it will make them easy to detect.
In fact, I would argue that Sandboxing could actually make the
'Sandboxed Application' more simple, effective, cheaper to develop
and easier to audit.
The fundamental point of departure between our points of view is
that I would argue that, the crown jewels are already inside the
sandbox!
I think that you are thinking of a unidimensional Sandbox model
similar to the one created by the Operating system between user-
land process and kernel, or the one implemented by .Net / Java for
mobile code executed on a web browser.
In the solution that I am envisioning, you will have multiple
Sandboxes, one inside the other, separated by very clearly defined
layers (the input choke points / attack surface) where each sandbox
is allocated privileges accordingly to what it needs to get the job
done (principle of least privilege), the amount of trust that we
have in that code (Code Access Security) and the identity used to
executed it (Role Based Security).
Unfortunately the Partial Trust Sandboxes that currently exist on
the .Net Framework (namely Medium Trust) are not good examples of
Sandboxes since they still allow the creation of easy exploitable
Asp.Net code (i.e. the security vulnerabilities that you mention
below would still occur on a web application executed under Medium
Trust).
So spending time and effort to stre
