Re: [WEB SECURITY] On sandboxes, and why you should care

[dinis at ddplus.net (Dinis Cruz)]

(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 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.
> > <snip>
> >
> > 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) Eclipse or Visual Studio in memory so that every
> > time a piece of code its submitted (checked-in) , the malicious
> > payloads are inserted.
>
> I don't follow your argument here.  You're saying that by running in a 
> sandbox we would prevent a developer with malicious intent from 
> executing evil code(?).  Granted that a sandbox may limit specific 
> operations such as writing or reading from the OS or making network 
> connections, but that doesn't mean you would prevent them from 
> accessing all the private data in the database or from allowing one 
> user to view another's data.  
Of course you can.

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)
> 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?".

And even if somebody had vetted their developers and audited their code, 
how would you know?

Another thing that I like about the Sandboxed model is the fact that it 
would also allow the pragmatic analysis of different applications 
security (i.e. metrics)
> 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.
>
> And that one line of malicious code can do a lot of damage _even in a 
> sandboxed environment_.
That depends on the Sandboxed environment :)

If that Sandboxed environment is properly enforced, then the amount of 
damage created by this one line of could be controlled, limited and (if 
anybody was looking) detected
> > <snip>
> > 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.
> > 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.
> > authorization vulnerabilities which allow the editing of files on the
> > server (via for example the CMS (content management system)),
This is the easier one of solve since the current CAS contains ample 
support for File's (code and role based) security decisions
> > manipulating params which control which method is executed (when
> > Reflection is used to perform late binding on method calls based on
> > the commands received) 
Again, using CAS (Code Access Security) you can control what code can be 
executed by each layer of the Sandbox
> > ,Social engineering, etc...
If you do a Thread Model on a multi-layer Sandboxed application, you 
will see that the 'attack surface' for social engineering will be 
dramatically reduced (when compared with a similar non-Sandboxed 
application).
> > 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.
Yes, but if these powerful customizations are executed inside a Sandbox 
then its damage potential are dramatically reduced.

Another good example is Cookie's Generation.

Under normal circumstances, malicious .Aspx code could create a 'Cookie 
Generator' for a Forms Authentication website which would allow the 
impersonation of any user in a way which would make its detection almost 
impossible.

I could create a Sandboxed environment which would prevent that  'Cookie 
Generator' from working.
> > 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)
>
> This only applies to environment where the value (to an attacker) of 
> compromising the data centre and web server is more than the value of 
> compromising the application itself.  In the majority of web 
> applications, the data stored by the app itself is the nazi gold - not 
> the webserver or surrounding infrastructure.  So sandboxing the app 
> will not add any protection to the stuff I care about most: my data.
It will, the problem here is that we are looking at this issue from 
different points of view. You are thinking that the sandbox will go 
between the Operating System and the Application (where ALL assets are), 
and I am thinking that the Sandbox(es) will be placed between the Assets 
and the potential malicious code/activities.

But your comment "... This only applies to environment where the value 
(to an attacker) of compromising the data center and web server is more 
that the value of compromising the application itself..." is spot on!

And in fact it shows how ineffective (from a security point of view) is 
the current focus on Non-Administrator environments, since they are only 
protecting the hardware and not the assets.
> > <snip>
> >
> > So let's look at another application (App B) which has the same
> > functionality but, is executed in three Sandboxes:
> >
> >  - Sandbox A) 450,000 lines of code executed in very restricted
> > Sandbox (let's say Asp.Net Low Trust)
> >
> >   - Sandbox B) 48,000 lines of code executed in secure Sandbox (let's
> > say customized version of Asp.Net Medium Trust)
> >
> >   - Sandbox C) 2,000 lines of code executed in a Sandbox which allows
> > calls to unmanaged code.
> >
> > Given the same 1 week, you (as the security consultant auditing this
> > application) will spend most of your time in Sandbox C) code, less on
> > Sandbox B) code and even less on Sandbox A) code. Why? because only a
> > vulnerability in Sandbox C) would allow the compromise of the entire
> > App / Server / Datacenter.
>
> I disagree.  Any one of those 450,000 lines of perfectly sandboxed and 
> verifiable code could contain an SQL injection attack that would 
> compromise my entire database.
That depends on the run-time environment of those 450,000 lines of code.

On a proper Sandboxed environment, those 450,000 of code would be inside 
a Sandbox which would not allow direct database query manipulation 
(which cause SQL Injection), direct HTML manipulation (which cause XSS), 
Cookie Generation (which cause Session Hijacking), direct access to 
admin interfaces (which could cause Authorization issues), etc, etc, etc...

The idea is to protect with a strong Sandbox (or series of Sandboxes) 
the assets that those 450,000 of code can 'touch'
>   They could also contain access control flaws that let 
> unauthenticated users access private information.  Or allow an 
> attacker to use an XSS flaw to steal a session cookie.  Running in a 
> sandbox would not prevent _any_ of these serious security issues, all 
> of which could compromise the security of my data.
It could prevent those attacks if the the Sandbox was designed to do so.

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.
> 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?

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'

Namely, HOW can an environment be created where the development and 
deployment of such Sandboxes makes business sense.

Dinis Cruz
Owasp .Net Project
wiki.owasp.net