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

[Andrew van der Stock]

Dinis,




* all types of cross-site scripting
* SQL injection

* LDAP injection
* XML injection
* authentication attacks, such as brute forcing etc

* second order injections (ie batch integrity issues)
* middleware attacks
* web service attacks








http://support.microsoft.com/?kbid=842419









thanks,
Andrew


On 24/05/2006, at 8:34 AM, Dinis Cruz wrote:

Sandboxing prevents a machine from having bad system() and buffer overflows causing system compromise. Sure that's bad enough. However, sandboxing does not prevent: * 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 * 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 * 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: 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.

(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

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.

- a compromised developer account details (which tend to be sent by

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

depended on such extraordinary set of circumstances?

So the first main security benefit that we have with using Sandboxes

full data center compromise to a local and limited problem)

center security and CIA (Confidentiality, Integrity and Availability) is: Containment, Damage Limitation, and Risk Reduction (you went from

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)


say customized version of Asp.Net Medium Trust)


calls to unmanaged code.

Given the same 1 week, you (as the security consultant auditing this

vulnerability in Sandbox C) would allow the compromise of the entire
App / Server / Datacenter.

- Sandbox B) 48,000 lines of code executed in secure Sandbox (let's - Sandbox C) 2,000 lines of code executed in a Sandbox which allows 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

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?

Dinis Cruz
Owasp .Net Project
wiki.owasp.net


_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org

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. List information, subscriptions, etc - http://krvw.com/mailman/ listinfo/sc-l List charter available at - http://www.securecoding.org/list/ charter.php

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
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