Re: [SC-L] By default, the Verifier is disabled on .Net and Java
On 5/9/06, Dinis Cruz <[EMAIL PROTECTED]> wrote: Jeff Williams wrote: > > But Dinis is right. There is a real problem with verification, as > demonstrated in the message below. This is a clear violation of the > Java VM Spec, yet my messages to the team at Sun developing the new > verifier have been ignored. And it's a real issue, given the number of > applications that rely on libraries they didn't compile. I don't think > a real explanation of how the Sun verifier actually works is too much > to ask, given the risk. > And 9 days into this discussion, Sun's comment (or somebody from Sun) is still nowhere to be seen (Microsoft is not the online one MIA :). Anybody had any luck with their off list attempts to get a comment on this issue? What about the main Java Application Server developers? WebSphere , WebLogic, JBoss, Enhydra, Blazix, Resin, JOnAS etc... It is important that they participate in this discussion, because amongst other things I would like them to answer my next questions, which are: "What is the point of the verifier?' , 'Why use it? and 'What are the real security advantages of enabling the verifier if the code is executed in an environment with the security manager disabled?' Huh? You can find what it does here: http://java.sun.com/sfaq/verifier.html The security manager and the verifier are different. The security manager allows you to restrict runtime-knowledge type things. Connecting a socket, opening a file, exiting the vm, and so on. The verifier deals with other things. As you know, right? So far we have identified several cases where: * the Java verifier is NOT enabled by default - Local code (i.e. loaded from the local system) * the Java verifier is enabled by default - classes that come with the Java platform - classes running inside Tomcat - classes running inside BEA WebLogic Given that the main attack vector (to exploit the lack of verification) is the same for all cases mentioned above (the attack vector being the injection of malicious Java code on the application being executed) then I would like to know the reason for the inconsistency? I also would like to ask if the following comments are correct: Option A) 99% of the Java code deployed to live systems is executed in an environment with the verifier disabled Option B) 99% of the Java code deployed to live systems is executed in an environment with the verifier disabled OR with the security manager disabled I'd say no. We already know BEA/Tomcat/(And from my knowledge Websphere) all run with verification ON by default. All these 3 don't take up only "1%" of all java code. If not, what value should Option A and B be? 10%, 50%, 75? Download the app servers and check the documentation? I'd guess most have it on by default. Not off. Just my guess though ... -- Michael ___ 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
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
On 5/9/06, Dinis Cruz <[EMAIL PROTECTED]> wrote: Stephen de Vries wrote: > Java has implemented this a bit differently, in that the byte code > verifier and the security manager are independent. So you could for > example, run an application with an airtight security policy (equiv to > partial trust), but it could still be vulnerable to type confusion > attacks if the verifier was not explicitly enabled. To have both > enabled you'd need to run with: > java -verify -Djava.security.policy ... This is a very weird decision by the Java Architects, since what is the point of creating and enforcing a airtight security policy if you can jump strait out of it via a Type Confusion attack? In fact, I would argue that you can't really say that you have an 'airtight security' policy if the verifier is not enabled! You can't disable the security manager even with the verifier off. But you could extend some final or private class that the security manager gives access to. Is there a example out there where (by default) java code is executed in an environment with : * the security manager enabled (with a strong security policy) and * the verifier disabled Yes. Your local JRE. -- Michael ___ 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
RE: [SC-L] By default, the Verifier is disabled on .Net and Java
That's essentially correct kevin. The idea was to be able to run not remote, but untrusted code. Note that modern readers will understand that local code can be untrusted. There is a good picture of this in securing java. gem -Original Message- From: Wall, Kevin [mailto:[EMAIL PROTECTED] Sent: Mon May 08 19:17:22 2006 To: Dinis Cruz; Stephen de Vries Cc: Secure Coding Mailing List Subject:RE: [SC-L] By default, the Verifier is disabled on .Net and Java Dinis Cruz writes... > Stephen de Vries wrote: > > Java has implemented this a bit differently, in that the byte code > > verifier and the security manager are independent. So you could for > > example, run an application with an airtight security policy (equiv to > > partial trust), but it could still be vulnerable to type confusion > > attacks if the verifier was not explicitly enabled. To have both > > enabled you'd need to run with: > > java -verify -Djava.security.policy ... > This is a very weird decision by the Java Architects, since what is the > point of creating and enforcing a airtight security policy if you can > jump strait out of it via a Type Confusion attack? > > In fact, I would argue that you can't really say that you have an > 'airtight security' policy if the verifier is not enabled! > > Right? > > Is there a example out there where (by default) java code is > executed in an environment with : > > * the security manager enabled (with a strong security policy) and > * the verifier disabled Just a hunch, but I suspect that it was designed this way to support mobile code, or more specifically applets. There is a security manager enabled (policy not airtight though; see McGraw/Felten's book on the subject) with applets, and the byte code verifier only verifies *remotely* loaded classes, which are the only ones presumed to be hostile. Dumb assumption, I know, but initially applets ran so slow, Sun probably had little choice if they hoped to "sell" applets. Besides, back then most of the hostile code WAS coming from different attack vectors--infected floppies or ftp'ing / running infected code. AV software monitored that attack vector, but not executable code coming in via HTTP through your browser. (Many do today, though.) But the assumption Sun made back then was that all locally loaded classes could be trusted and therefore were type-safe. In retrospect, several wrong decisions were made regarding web security. (Don't even get me started on Radio-ActiveX! ;-) But as they say, backward compatibility is the curse of software design, so we probably are stuck with it. Fortunately the verifier is pretty simple to enable in Java. OTOH, coming up with a good security policy is not so easy. I've only done it twice and it's been a laborious process each time assuming you start with essentially a fail-safe "no permissions" approach and only add permissions as-needed. Anyway, I'd say that applets were probably what drove this security model. Curious that applets probably now comprise less than %1 of all Java code today. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 <... add your favorite pithy quote about hindsight here ...> This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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 This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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.securecodin
RE: [SC-L] By default, the Verifier is disabled on .Net and Java
Dinis Cruz writes... > Stephen de Vries wrote: > > Java has implemented this a bit differently, in that the byte code > > verifier and the security manager are independent. So you could for > > example, run an application with an airtight security policy (equiv to > > partial trust), but it could still be vulnerable to type confusion > > attacks if the verifier was not explicitly enabled. To have both > > enabled you'd need to run with: > > java -verify -Djava.security.policy ... > This is a very weird decision by the Java Architects, since what is the > point of creating and enforcing a airtight security policy if you can > jump strait out of it via a Type Confusion attack? > > In fact, I would argue that you can't really say that you have an > 'airtight security' policy if the verifier is not enabled! > > Right? > > Is there a example out there where (by default) java code is > executed in an environment with : > > * the security manager enabled (with a strong security policy) and > * the verifier disabled Just a hunch, but I suspect that it was designed this way to support mobile code, or more specifically applets. There is a security manager enabled (policy not airtight though; see McGraw/Felten's book on the subject) with applets, and the byte code verifier only verifies *remotely* loaded classes, which are the only ones presumed to be hostile. Dumb assumption, I know, but initially applets ran so slow, Sun probably had little choice if they hoped to "sell" applets. Besides, back then most of the hostile code WAS coming from different attack vectors--infected floppies or ftp'ing / running infected code. AV software monitored that attack vector, but not executable code coming in via HTTP through your browser. (Many do today, though.) But the assumption Sun made back then was that all locally loaded classes could be trusted and therefore were type-safe. In retrospect, several wrong decisions were made regarding web security. (Don't even get me started on Radio-ActiveX! ;-) But as they say, backward compatibility is the curse of software design, so we probably are stuck with it. Fortunately the verifier is pretty simple to enable in Java. OTOH, coming up with a good security policy is not so easy. I've only done it twice and it's been a laborious process each time assuming you start with essentially a fail-safe "no permissions" approach and only add permissions as-needed. Anyway, I'd say that applets were probably what drove this security model. Curious that applets probably now comprise less than %1 of all Java code today. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 <... add your favorite pithy quote about hindsight here ...> This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
Stephen de Vries wrote: Java has implemented this a bit differently, in that the byte code verifier and the security manager are independent. So you could for example, run an application with an airtight security policy (equiv to partial trust), but it could still be vulnerable to type confusion attacks if the verifier was not explicitly enabled. To have both enabled you'd need to run with: java -verify -Djava.security.policy ... This is a very weird decision by the Java Architects, since what is the point of creating and enforcing a airtight security policy if you can jump strait out of it via a Type Confusion attack? In fact, I would argue that you can't really say that you have an 'airtight security' policy if the verifier is not enabled! Right? Is there a example out there where (by default) java code is executed in an environment with : * the security manager enabled (with a strong security policy) and * the verifier disabled Dinis Cruz Owasp .Net Project www.owasp.net ___ 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
Re: [SC-L] By default, the Verifier is disabled on .Net and Java
Jeff Williams wrote: But Dinis is right. There is a real problem with verification, as demonstrated in the message below. This is a clear violation of the Java VM Spec, yet my messages to the team at Sun developing the new verifier have been ignored. And it’s a real issue, given the number of applications that rely on libraries they didn’t compile. I don’t think a real explanation of how the Sun verifier actually works is too much to ask, given the risk. And 9 days into this discussion, Sun's comment (or somebody from Sun) is still nowhere to be seen (Microsoft is not the online one MIA :). Anybody had any luck with their off list attempts to get a comment on this issue? What about the main Java Application Server developers? WebSphere , WebLogic, JBoss, Enhydra, Blazix, Resin, JOnAS etc... It is important that they participate in this discussion, because amongst other things I would like them to answer my next questions, which are: "What is the point of the verifier?' , 'Why use it? and 'What are the real security advantages of enabling the verifier if the code is executed in an environment with the security manager disabled?' So far we have identified several cases where: * the Java verifier is NOT enabled by default - Local code (i.e. loaded from the local system) * the Java verifier is enabled by default - classes that come with the Java platform - classes running inside Tomcat - classes running inside BEA WebLogic Given that the main attack vector (to exploit the lack of verification) is the same for all cases mentioned above (the attack vector being the injection of malicious Java code on the application being executed) then I would like to know the reason for the inconsistency? I also would like to ask if the following comments are correct: Option A) 99% of the Java code deployed to live systems is executed in an environment with the verifier disabled Option B) 99% of the Java code deployed to live systems is executed in an environment with the verifier disabled OR with the security manager disabled If not, what value should Option A and B be? 10%, 50%, 75? Thanks for your comments Best regards Dinis Cruz Owasp .Net Project www.owasp.net ___ 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
RE: [SC-L] HNS - Biggest X Window security hole since 2000
> >> So, it sounds like a single byte change in the entire X src tree > >> could fix a bug that could give an attacker complete control of a > >> system. Lovely... For the curious out there, it isn't one byte, it's two. It is a PAIR of parenthesis that are missing, not a single one, like many of the non-technical summaries imply. Basically, the flaw is: if (getuid() == 0 || geteuid == 0) doesn't do what you intended! -Tim P.S. Note that this can be considered a type error if you're pedantic enough ... it requires: (1) an OS that uses integral types as user identifiers (2) a language that will implicitly convert functions to pointers (3) a language that allows pointer comparisons to zero ___ 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
Re: [SC-L] HNS - Biggest X Window security hole since 2000
> Certainly that part is OS-specific. On my VMS machine, X-windows processes > do not run as root. The X Window server needs elevated privileges because it can trigger DMA on the graphics card (and thus read arbitrary memory, unless you've got an IOMMU). Chances are, however, that your VMS implementation does not even support the Xrender extension. Of course, the impact of this vulnerability is exaggerated in the article. Local privilege escalation vulnerabilties are numerous. ___ 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
Re: [SC-L] HNS - Biggest X Window security hole since 2000
der Mouse wrote:
> And, of course, nobody ever bothers to say just what the problem was.
> Grrr. (Fortunately, I don't care, since I am running pre-X11R6.9.0
> code, or I'd be trying to chase down the diff.)
Bad code:
/* First the options that are only allowed for root */
if (getuid() == 0 || geteuid != 0) {
if (!strcmp(argv[i], "-modulepath"))
Good code:
/* First the options that are only allowed for root */
if (getuid() == 0 || geteuid() != 0) {
if (!strcmp(argv[i], "-modulepath"))
The problem, of course, is that the address of geteuid is
always == true.
rCs
--
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC
Work: 412-268-7608
FAX: 412-268-6989
___
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
Re: [SC-L] HNS - Biggest X Window security hole since 2000
>> The author claims, "This flaw, caused by something as seemingly >> harmless as a missing closing parenthesis, allowed local users to >> execute code with root > Certainly that part is OS-specific. On my VMS machine, X-windows > processes do not run as root. OS- and installation-specific. Neither the above nor the article says just which piece of X is responsible, but I don't think any X code runs as root on my (NetBSD) machines unless I specifically do so, such as starting a terminal emulator from a root shell. >> So, it sounds like a single byte change in the entire X src tree >> could fix a bug that could give an attacker complete control of a >> system. Lovely... And, of course, nobody ever bothers to say just what the problem was. Grrr. (Fortunately, I don't care, since I am running pre-X11R6.9.0 code, or I'd be trying to chase down the diff.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ 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
