Re: On sandboxes, and why you should care

[Stephen de Vries <stephen () corsaire com>]

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.  The fundamental point of departure between  
our points of view is that I would argue that, the crown jewels are  
already inside the sandbox!  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.

> <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) path 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.  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.

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

> <snip>
> 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)

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.

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

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.

cheers,

--
Stephen de Vries
Corsaire Ltd
E-mail: stephen () corsaire com
Tel:    +44 1483 226014
Fax:    +44 1483 226068
Web:    http://www.corsaire.com






-------------------------------------------------------------------------
This List Sponsored by: SpiDynamics

ALERT: "How A Hacker Launches A Web Application Attack!" 
Step-by-Step - SPI Dynamics White Paper
Learn how to defend against Web Application Attacks with real-world 
examples of recent hacking methods such as: SQL Injection, Cross Site 
Scripting and Parameter Manipulation

https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl
--------------------------------------------------------------------------