Hi Dinis,
On 24 May 2006, at 05:34, Dinis Cruz wrote:
<snip>
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).
If I understand this correctly, then this implies a _huge_
architecture change for developers. It's already a difficult task
for developers to map a problem domain onto an Object Oriented
language, what you're suggesting is to throw another constraint in
the mix which may break a lot of the design. A very simple MVC
pattern for the web tier could become quite complex with multiple
nested sandboxes. This could mean that the sandboxing could become
central to the design of the app. Of course, this may be required in
certain high risk high value environments, but the additional cost of
implementing this for your average web app would be too high IMO.
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).
I can't speak for .NET, but the Java security manager can be defined
purely as a configuration item. There doesn't need to be anything
special in the code to take advantage of the security manager. This
means the sandbox doesn't intrude on the code at all, it merely sets
runtime restrictions.
So spending time and effort to strengthen the walls isn't going to
do any real good in preventing an attacker from getting hold of them.
The plan is to put has many walls as possible between the attacker
and the assets.
This is a good analogy, and I agree with you that sandboxes will
limit the kind of attacks that move from one layer to the next. But
they won't be able to stop attacks that don't traverse the walls,
such as SQL injection and XSS.
I can create a .Net environment which prevents those developers
from accessing directly the database (in the case where malicious
code was uploaded to the server).
CAS allows the creation of custom permissions which could be used
to implement 'Data-Sandboxed environments' which enforce
application-logic to the sandboxed code (for example not-allowing
access to private data stored within the database or other user's
data)
Not allowing access to certain database tables, fine. And preventing
access to stored procedures, also fine. But what about the tables
that _have_ to be accessed as part of the requirements? Example:
SELECT * FROM USERS WHERE USERID=10
How would a sandbox prevent a simple parameter manipulation attack to
gain access to someone elses data? So even though you may prevent
attackers from running xp_cmdshell or reading system tables, you
can't prevent them from accessing the USERS table.
Sandboxing is not going to make any difference here, but external
controls such as vetting your developers and auditing the code
would make a very real contribution to improving the security.
Although this is important, and will have to be done for certain
types of code (namely the ones we will place more trust (and will
pay more for)), this will not scale up (i.e. work for ALL software
that is executed in your computer).
Just do this simple test: analyze your computer and list every
single application that you have installed (if you have time, try
also listing the writers of the individual components (dlls, static
libraries, etc...) used by those applications), once you have that
list of applications which will have access to ALL your user-land
assets (let's ignore for now the ones that also have (or had)
administrative privileges to your box), ask yourself the question:
"Do I really trust every single developer that worked on this
applications/modules?".
It's a matter of degree of trust. I store all my sensitive data in a
Mac OS X keychain, and I trust that that data isn't worth someone
subverting a developer at Apple (and his colleagues who would have
spotted the malicious code) and the QA team and the code auditors
etc. BUT I would _not_ trust this process if I stored nuclear launch
codes in the app!
A couple more examples of ways malicious code can be uploaded to the
server: SQL Injection,
if the code 'injected' by an SQL Injection is executed in a
Sandboxed environment, then the damage potential for that SQL
Injection is very limited.
Limited yes, mitigated no. See my example above.
XSS (payload deployed to the admin section),
XSS (since being a client-side exploit) is one where the Sandbox
approach would be harder to implement (unless the affected user is
also using a Sandboxed browser where some types of exploits could
be prevented).
To prevent XSS via a Sandbox, one approach would be to use the
Sandbox model to clearly define the 'input chokepoints' and force
(via CAS Demands) that data validation was performed on those
requests. This way, the developers would have no option but to
validate their data. Another option would be to encode all inputs
and outputs from the untrusted sandboxes (i.e. only the 'trusted'
sandboxes would have the ability to manipulate Html directly.
Again, this makes the sandboxes central to the application design.
And for applications where security is a primary driver this is
appropriate. But this is not the case for the vast majority of apps.
Of course that somewhere, in one of those Sandboxes, there will be
code that will be able to access the database directly. But if we
are able to limit the amount of code that needs these privileges
(Sandboxes B and C in the example above), then the amount of code
that needs to be audited (and for example certified by a third
party security-audit-company) will be smaller and manageable.
Good point, and definitely a benefit of using sandboxes.
To summarise, sandboxing an app is useful in preventing specific
attacks such as executing OS commands, making unauthorized
connections and accessing arbitrary system resources but it will
not do anything to prevent the vast majority of serious security
issues affecting web apps, because the valuable stuff is inside
the sandbox.
After my explanations in this email do you still think that this is
correct? Or can you accept now that it is possible to build a
Sandboxed environment that is able to protect against the majority
of the serious security issues that affect web apps today?
I still don't see sandboxes addressing all the issues as explained
above. Another important disadvantage is the cost and impact of
implementing sandboxes in the first place. Creating multiple layered
sandboxes in the code is much more of an obstacle to their
implementation than simply defining constraints at runtime through a
configuration change, because it would make security _the central_
design constraint of the application (it may also break OO
patterns). And while this is fine for some high risk apps, this is
not the case for the majority of organisations who have other
functional concerns as the reasons they built the app.
Consider the JVM that provides a full sandbox model that's reasonable
easy to implement for almost any Java app, and then consider the 1%
(using your metrics) of java applications that enable this
sandboxing. If a simple configuration change is too much for
projects to manage, how much less so an entire new sandbox
development framework!
Saying that, I don't want to cast too much negativity on the idea -
it's a good idea, but for niche markets.
If you do accept that it is possible to build such sandboxes, then
we need to move to the next interesting discussion, which is the 'HOW'
The 'How' would also give us an idea of how difficult it would be to
implement these sandboxes and shed some light on exactly which
security issues they would prevent and which they would not.
regards,
--
Stephen de Vries
Corsaire Ltd
E-mail: [EMAIL PROTECTED]
Tel: +44 1483 226014
Fax: +44 1483 226068
Web: http://www.corsaire.com
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
