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

[vanderaj at greebo.net (Andrew van der Stock)]

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 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
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/ 
> listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/ 
> charter.php

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2234 bytes
Desc: not available
Url : http://krvw.com/pipermail/sc-l/attachments/20060525/751de65e/attachment.bin