Great topics.
I'm a huge fan of sandboxes, but Dinis is right, the market hasn't really
gotten there yet. No question that it would help if it was possible to run
complex software like a browser inside a sandbox that restricted its ability
to do bad things, even if there are vulnerabilities (or worse -- malicious
code) in them. I'm terrified about the epidemic use of libraries that are
just downloaded from wherever (in both client and server applications). All
that code can do *whatever* it wants in your environments folks!
Sandboxes are finally making some headway. Most of the Java application
servers (Tomcat included) now run with their sandbox enabled (albeit with a
weak policy). And I think the Java Web Start system also has the sandbox
enabled. So maybe we're making progress.
But, if you've ever tried to configure the Java security policy file, use
JAAS, or implement the SecurityManager interface, you know that it's *way*
too hard to implement a tight policy this way. You end up granting all
kinds of privileges because it's too difficult to do it right. And only the
developer of the software could reasonably attempt it, which is backwards,
because it's the *user* who really needs it right. Also, applications don't
fail nicely when security exceptions are generated, so it's not like you can
really just slap a sandbox around an application you download and run it.
It's possible that sandboxes are going the way of multilevel security (MLS).
A sort of ivory tower idea that's too complex to implement or use. But it
seems like a really good idea that we should try to make practical. But even
if they do start getting used, we can't just give up on getting software
developers to produce secure code. There will always be security problems
that sandboxes designed for the platform cannot help with.
I'm with Dinis that the only way to get people to care is to fix the
externalities in the software market and put the burden on those who can
most easily avoid the costs -- the people who build the software. Maybe then
the business case will be more clear.
(Your last point about non-verified MSIL is terrifying. I can't think of any
reason why you would want to turn off verification -- except perhaps startup
speed. But that's a terrible tradeoff.)
http://www.owasp.org
Message
From: owasp-leaders-admin (AT) lists (DOT) sourceforge.net [mailto:owasp-leaders-
admin (AT) lists (DOT) sourceforge.net] Behalf Dinis Cruz
Sent: Saturday, March 25, 2006 6:39 AM
To: 'owasp-dotnet (AT) lists (DOT) sourceforge.net'; webappsec (AT) securityfocus (DOT) com; SC-
L (AT) securecoding (DOT) org; full-disclosure (AT) lists (DOT) grok.org.uk
Cc: xforce (AT) iss (DOT) net
Subject: [WASP-LEADERS] 4 Questions: Latest IE vulnerability, Firefox vs
IE
security, User vs Admin risk profile, and browsers coded in 100% Managed
Verifiable code
Another day, and another unmanaged-code remote command execution in IE.
What is relevant in the ISS alert (see end of this post) is that IE 7
beta 2 is also vulnerable, which leads me to this post's questions:
1) Will IE 7.0 be more secure than IE 6.0 (i.e. will after 2 years it
being released the number of exploits and attacks be smaller than today?
and will it be a trustworthy browser?)
2) Given that Firefox is also build on unmanaged code, isn't Firefox as
insecure as IE and as dangerous
3) Since my assets as a user exist in user land, isn't the risk profile
of malicious unmanaged code (deployed via IE/Firefox) roughly the same
if I am running as a 'low privileged' user or as administrator? (at the
end of the day, in both cases the malicious code will still be able to:
access my files, access all websites that I have stored credentials in
my browser (cookies or username / passwords pairs), access my VPNs,
attack other computers on the local network, install key loggers,
establish two way communication with a Internet based boot net, etc
(basically everything except rooting the boot, disabling AVs and
installing persistent hooks (unless of course this malicious code
executes a successful escalation of privilege attack)))
4) Finally, isn't the solution for the creation of secure and
trustworthy Internet Browsing environments the development of browsers
written in 100% managed and verifiable code, which execute on a secure
and very restricted Partially Trusted Environments? (under .Net, Mono or
Java). This way, the risk of buffer overflows will be very limited, and
when logic or authorization vulnerabilities are discovered in this
'Partially Trusted IE' the 'Secure Partially Trusted environment' will
limit what the malicious code (i.e. the exploit) can do.
This last question/idea is based on something that I have been defending
for quite a while now (couple years) which is: "Since it is impossible
to create bug/vulnerability free code, our best solution to create
securer and safer computing environments (compared to the ones we have
today), is to execute those applications in sandboxed environments".
Basically we need to be able to safely handle malicious code, executed
in our user's session, in a web server, in a database engine, etc
current security model is based on the concept of preventing malicious
code from being executed (something which is becoming more and more
impossible to do) versus the model of 'malicious payload containment'
(i.e. Sandboxing).
And in my view, creating sandboxes for unmanaged code is very hard or
even impossible (at least in the current Windows Architecture), so the
only solution that I am seeing at the moment is to create sandboxes for
managed and verifiable code.
Fortunately, both .Net and Java have architectures that allow the
creation of these 'secure' environments (CAS and Security Manager).
Unfortunately, today there is N BUSINESS case to do this. The paying
customers are not demanding products that don't have the ability to
'own' their data center, software companies don't want to invest in the
development of such applications, nobody is liable for anything,
malicious attackers have not exploited this insecure software
development and deployment environment (they have still too much to
money to harvest via Spyware/Spam) and the Framework developers
(Microsoft, Sun, Novell, IBM, etc) don't want to rock the boat and
explain their to their clients that they should be demanding (and only
paying for) applications that can be safely executed in their corporate
environment (i.e. ones where malicious activities are easily detectable,
preventable and contained (something which I believe we only have a
chance of doing with managed and verifiable code)).
I find ironic the fact that Microsoft now looks at and says 'We
are so much better than them on Security', when the reason why
has not cared (so far) about security is the same why Microsoft doesn't
make any serious efforts to promote and develop Partially Trusted .Net
applications: There is no business case for both. Btw, if Microsoft
publicly admitted that the current application development practices of
NLY creating Full Trust code IS A MASSIVE PRBLEM, and if Microsoft
spent considerable resources and focus in turning that boat around, the
resulting 'partially trusted application' environment (which could then
be enforced by default to all locally executed code) would have more
impact in creating a secure and trustworthy computing environment that
all LUAs and UACs put together :)
Finally, you might have noticed that whenever I talked about 'managed
code', I mentioned 'managed and verifiable code', the reason for this
distinction, is that I discovered recently that .Net code executed under
Full Trust can not be (or should not be) called 'managed code', since
the .Net Framework will not verify that code (because it is executed
under Full Trust). This means that I can write MSIL code which breaks
type safety and execute it without errors in a Full Trust .Net
environment.
in the hope that somebody is listening
Best regards
Dinis Cruz
.Net Project
www.owasp.net
Message
Subject: ISS ProIStection Brief: Microsoft IE createTextRange()
Remote Command Execution
Date: Fri, 24 Mar 2006 14:55:42 -0500 (EST)
From: X-Force <xforce (AT) iss (DOT) net>
To: alert (AT) iss (DOT) net
Internet Security Systems Protection Alert
March 24, 2006
Microsoft IE createTextRange() Remote Command Execution
Version: 1.0
Summary:
A vulnerability was reported in the way Microsoft Internet Explorer
handles unexpected method calls. Exploitation of this vulnerability
could lead to remote code execution under the security context of the user
viewing a malicious web page.
Description:
Internet Explorer does not properly handle the createTextRange()
method when invoked on a checkbox object. Because of this, a call is
made to a predictable location in memory. An attacker can easily
fill this predictable location in memory with malicious code to
be executed.
Business Impact:
Compromise of the operating system can lead to exposure of
confidential information, loss of productivity, and further network
compromise. Successful exploitation of this vulnerability could
be used to gain unauthorized access to one.s networks and machines.
Affected Products:
. Microsoft Corporation: Microsoft Internet Explorer 6.0
. Microsoft Corporation: Microsoft Internet Explorer 6.0 SP1
. Microsoft Corporation: Microsoft Internet Explorer 7 Beta 2
. Microsoft Corporation: Windows 95
. Microsoft Corporation: Windows 98
. Microsoft Corporation: Windows 98 Second Edition
. Microsoft Corporation: Windows Me
. Microsoft Corporation: Windows XP
. Microsoft Corporation: Windows 2000 Any version
. Microsoft Corporation: Windows 2003 Any version
. Microsoft Corporation: Windows NT 4.0
About Internet Security Systems, Inc.
Internet Security Systems, Inc. (ISS) is the trusted security advisor to
thousands of the world.s leading businesses and governments, providing
preemptive protection for networks, desktops and servers. An established
leader in security since 1994, ISS. integrated security platform
automatically protects against both known and unknown threats, keeping
networks up and running and shielding customers from online attacks before
they impact business assets. ISS products and services are based
on the proactive security intelligence of its X-ForceR research and
development team . the unequivocal world authority in vulnerability and
threat research. ISS. product line is also complemented by
comprehensive Managed Security Services. For more information, visit
the Internet Security Systems Web site at www.iss.net or call
800-776-2362.
Copyright (c) 2006 Internet Security Systems, Inc. All rights reserved
worldwide.
This document is not to be edited or altered in any way without the
express written consent of Internet Security Systems, Inc. If you wish
to reprint the whole or any part of this document, please email
xforce (AT) iss (DOT) net for permission. You may provide links to this document
from your web site, and you may make copies of this document in
accordance with the fair use doctrine of the U.S. copyright laws.
Disclaimer: The information within this paper may change without notice.
Use of this information constitutes acceptance for use in an AS IS
condition. There are N warranties, implied or otherwise, with regard to
this information or its use. Any use of this information is at the
user's risk. In no event shall the author/distributor (Internet Security
Systems X-Force) be held liable for any damages whatsoever arising out
of or in connection with the use or spread of this information.
X-Force PGP Key available on MIT's PGP key server and PGP.com's key
server, as well as at
Please send suggestions, updates, and comments to: X-Force
xforce (AT) iss (DOT) net of Internet Security Systems, Inc.
xforce (AT) iss (DOT) net of Internet Security Systems, Inc.
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
mailing list
@lists.sourceforge.net
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

Hi Jeff, comments inline

Jeff Williams wrote:
Great topics.

I'm a huge fan of sandboxes, but Dinis is right, the market hasn't really
gotten there yet. No question that it would help if it was possible to run
complex software like a browser inside a sandbox that restricted its ability
to do bad things, even if there are vulnerabilities (or worse -- malicious
code) in them.
Absolutely, and do you see any other alternative? (or we should just
continue to TRUST every bit of code that is executed in our computers?
and TRUST every single developer/entity that had access to that code
during its development and deployment?)
I'm terrified about the epidemic use of libraries that are
just downloaded from wherever (in both client and server applications). All
that code can do *whatever* it wants in your environments folks!

Yes they can, and one of my original questions was 'When considering the
assets, is there REALLY any major differences between running code as
normal user versus as an administrator?"
Sandboxes are finally making some headway. Most of the Java application
servers (Tomcat included) now run with their sandbox enabled (albeit with a
weak policy). And I think the Java Web Start system also has the sandbox
enabled. So maybe we're making progress.

True, but are these really secure sandboxes?

I am not a Java expert so I can't give you specific examples, but on the
Net Framework a Partially Trusted 'Sandbox' which contains an
UnamanagedCode, MemberAccess Reflection or SkipVerification Permission,
should not be called a 'Sandbox' since it can be easily compromised.
But, if you've ever tried to configure the Java security policy file, use
JAAS, or implement the SecurityManager interface, you know that it's *way*
too hard to implement a tight policy this way.
And .Net has exactly the same problem. It is super complex to create a
Net application that can be executed in a secure Partially Trusted Sandbox.
You end up granting all
kinds of privileges because it's too difficult to do it right.
And the new VS2005 makes this allocation of privileges very easy: "Mr.
developer, your application crashed because it didn't have the required
permissions, Do you want to add these permissions, Yes No?
(developer clicks yes) "You are adding the permission
UnamanagedCodePermission, do you sure, Yes No? (developer clicks yes
(with support from application architect and confident that all
competitor Applications require similar permissions))"
And only the
developer of the software could reasonably attempt it, which is backwards,
because it's the *user* who really needs it right.
Yes, it is the user's responsibility (i.e. its IT Security and Server
Admin staff) to define the secure environment (i.e the Sandbox) that 3rd
party or internal-developed applications are allocated inside their data
center,

It's possible that sandboxes are going the way of multilevel security (MLS).
A sort of ivory tower idea that's too complex to implement or use.
I don't agree that the problem is too complex. What we have today is
very complex architectures / systems with too many interconnections.

Simplify the lot, get enough resources with the correct focus involved,
are you will see that it is doable.
But it
seems like a really good idea that we should try to make practical. But even
if they do start getting used, we can't just give up on getting software
developers to produce secure code. There will always be security problems
that sandboxes designed for the platform cannot help with.

course, I am not saying that developers should produce insecure code,
I am the first to defend that developers must have a firm and solid
understanding of the tools and technologies that they use, and also as
important, the security implications of their code.
I'm with Dinis that the only way to get people to care is to fix the
externalities in the software market and put the burden on those who can
most easily avoid the costs -- the people who build the software. Maybe then
the business case will be more clear.

Yes, but the key here is not with money (since that would also kill
large chunks of the Source world).

of the solutions that I like, is the situation where all software
companies have (by law) to disclose information about the
vulnerabilities that they are aware of (look at the Eeye model of
disclosing information about 'reported but unpatched vulnerabilities').

Basically, give the user data (as in information) that he can digest and
understand, and you will see the user(s) making the correct decision(s).
(Your last point about non-verified MSIL is terrifying. I can't think of any
reason why you would want to turn off verification -- except perhaps startup
speed. But that's a terrible tradeoff.)

See my previous post (on this same thread) about this issue, but I think
that .Net is not alone in skipping verification for locally executed code :)

Dinis Cruz
.Net Project
www.owasp.net

Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia - http://secunia.com/

Hi Jeff, comments inline

Jeff Williams wrote:
Great topics.

I'm a huge fan of sandboxes, but Dinis is right, the market hasn't really
gotten there yet. No question that it would help if it was possible to run
complex software like a browser inside a sandbox that restricted its ability
to do bad things, even if there are vulnerabilities (or worse -- malicious
code) in them.
Absolutely, and do you see any other alternative? (or we should just
continue to TRUST every bit of code that is executed in our computers?
and TRUST every single developer/entity that had access to that code
during its development and deployment?)
I'm terrified about the epidemic use of libraries that are
just downloaded from wherever (in both client and server applications). All
that code can do *whatever* it wants in your environments folks!

Yes they can, and one of my original questions was 'When considering the
assets, is there REALLY any major differences between running code as
normal user versus as an administrator?"
Sandboxes are finally making some headway. Most of the Java application
servers (Tomcat included) now run with their sandbox enabled (albeit with a
weak policy). And I think the Java Web Start system also has the sandbox
enabled. So maybe we're making progress.

True, but are these really secure sandboxes?

I am not a Java expert so I can't give you specific examples, but on the
Net Framework a Partially Trusted 'Sandbox' which contains an
UnamanagedCode, MemberAccess Reflection or SkipVerification Permission,
should not be called a 'Sandbox' since it can be easily compromised.
But, if you've ever tried to configure the Java security policy file, use
JAAS, or implement the SecurityManager interface, you know that it's *way*
too hard to implement a tight policy this way.
And .Net has exactly the same problem. It is super complex to create a
Net application that can be executed in a secure Partially Trusted Sandbox.
You end up granting all
kinds of privileges because it's too difficult to do it right.
And the new VS2005 makes this allocation of privileges very easy: "Mr.
developer, your application crashed because it didn't have the required
permissions, Do you want to add these permissions, Yes No?
(developer clicks yes) "You are adding the permission
UnamanagedCodePermission, do you sure, Yes No? (developer clicks yes
(with support from application architect and confident that all
competitor Applications require similar permissions))"
And only the
developer of the software could reasonably attempt it, which is backwards,
because it's the *user* who really needs it right.
Yes, it is the user's responsibility (i.e. its IT Security and Server
Admin staff) to define the secure environment (i.e the Sandbox) that 3rd
party or internal-developed applications are allocated inside their data
center,

It's possible that sandboxes are going the way of multilevel security (MLS).
A sort of ivory tower idea that's too complex to implement or use.
I don't agree that the problem is too complex. What we have today is
very complex architectures / systems with too many interconnections.

Simplify the lot, get enough resources with the correct focus involved,
are you will see that it is doable.
But it
seems like a really good idea that we should try to make practical. But even
if they do start getting used, we can't just give up on getting software
developers to produce secure code. There will always be security problems
that sandboxes designed for the platform cannot help with.

course, I am not saying that developers should produce insecure code,
I am the first to defend that developers must have a firm and solid
understanding of the tools and technologies that they use, and also as
important, the security implications of their code.
I'm with Dinis that the only way to get people to care is to fix the
externalities in the software market and put the burden on those who can
most easily avoid the costs -- the people who build the software. Maybe then
the business case will be more clear.

Yes, but the key here is not with money (since that would also kill
large chunks of the Source world).

of the solutions that I like, is the situation where all software
companies have (by law) to disclose information about the
vulnerabilities that they are aware of (look at the Eeye model of
disclosing information about 'reported but unpatched vulnerabilities').

Basically, give the user data (as in information) that he can digest and
understand, and you will see the user(s) making the correct decision(s).
(Your last point about non-verified MSIL is terrifying. I can't think of any
reason why you would want to turn off verification -- except perhaps startup
speed. But that's a terrible tradeoff.)

See my previous post (on this same thread) about this issue, but I think
that .Net is not alone in skipping verification for locally executed code :)

Dinis Cruz
.Net Project
www.owasp.net

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