[Full-disclosure] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: LatestIE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
This comes back to that great concept called 'Faith-based' Security (see Gunnar Peterson's post http://1raindrop.typepad.com/1_raindrop/2005/11/net_and_java_fa.html ), which is when people are told so many times that something is secure, that that they believe that it MUST be secure. Some examples:This is also neatly summarized by Brian Snow thusly:We will be in a truly dangerous stance: we will think we are secure (and act accordingly) when in fact we are not secure.-gp1. Notes and links on "We Need Assurance!" paperhttp://1raindrop.typepad.com/1_raindrop/2005/12/the_road_to_ass.html___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/___ 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] Managed Code and Runtime Environments - Another layer of added security?
> Multics code was not immune to buffer overflows, but in most cases > the effect was blunted because the out-of-range index values could > only affect data beyond the current activation record--in contrast > with most linear addressing systems where an overflow is almost > always able to reach important values like the return address. This is only because the libraries used store later characters in a string at higher addresses (as compared to earlier characters). If the string libraries stored strings the other way around (with the earlier characters at the higher addresses), downward-growing stacks would have exactly this kind of buffer overrun protection. Hmm, I wonder if there's something useful lurking there. /~\ 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
Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?
While we're on Multics lessons, let's not forget upward-growing stacks (which were a natural consequence of the segmented addressing architecture). Multics code was not immune to buffer overflows, but in most cases the effect was blunted because the out-of-range index values could only affect data beyond the current activation record--in contrast with most linear addressing systems where an overflow is almost always able to reach important values like the return address. It is sobering to reflect how much of the current state of our art was laid out clearly in 1969 by Peter's own "The Role of Motherhood in the Pop Art of System Programing" paper and by the 1973 Saltzer/Schroeder paper "The Protection of Information in Computer Systems". These are always worth a read: http://multicians.org/pgn-motherhood.html http://www.cs.virginia.edu/~evans/cs551/saltzer/ -- Olin Sibert At 01:17 PM 3/29/2006, Peter G. Neumann wrote: Der Mouse is barking up the right rathole. *** BEGIN SOAPBOX *** Having cut my security eye-teeth in Multics from 1965 to 1969, I am continually drawn back into discussions of what Multics did right that has been systematically (!) ignored by almost all subsequent operating systems. For the younger folks among the SC-L audience, let me mention a few of the architectural strengths. There were no buffer overflows in the stack, because anything out of the stack frame was not executable. The ring-structured domain architecture and file system access controls permitted straightforward sandboxing. Dynamic linking and revocation were fundamental. Segmentation and paging enabled layers of virtual machines and protected virtual memory. The I/O system had virtual stream names, virtual I/O, and common device-driver software where appropriate, coupled with separate hardware for the input-output controller (GIOC). The programming language was the stark EPL subset of PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to have avoided some of the characteristic programming errors that are still common today. No software was written until there was an approved specification, with well defined interfaces and exception conditions that were explicitly characterized in EPL. And so on into a visionary sense of a future that has been largely lost for may perceived reasons, some of which are bogus, some of which are just seriously short-sighted. *** END SOAPBOX *** I'm sure this message may generate all sorts of Ifs and Ands and Buts. But the Butt we are kicking is our own. Cheers! PGN ___ 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 ___ 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] Managed Code and Runtime Environments - Another layer of added security?
> Der Mouse is barking up the right rathole. :-) That's a lovely mangled metaphor. And, thanks for the kind words; I'm glad to see I'm not totally out to lunch. (I haven't been at this for as long as you have - you write "from 1965 to 1969", during which time I was at most five years old - and it's good to get confirmation of some of what I think I've learnt.) > No software was written until there was an approved specification, > with well defined interfaces and exception conditions And here you come close, I believe, to one of the reasons this kind of security architecture is not more done. This kind of coding - heck, even just writing good specifications - is hard work, work that comparatively few people are competent to do. In all my years at this, I can count the number of times I've seen a really well-defined specification on the fingers of one hand. (The case I usually cite is the VAX Architecture Reference Manual, which is carful to call out all the cases where the behaviour is UNDEFINED or UNPREDICTABLE, those being technical terms defined early in the document, and to cover every possibility with defined behaviour or one of those.) Almost everything has holes, cases where the spec is silent; this is not the way to produce solid designs. In many cases a shaky design is no big problem (so your solitaire game crashes now and then, so what?). But in other cases it can be quite disastrous, with the kind of consequences everyone here surely knows far too much about. /~\ 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
Re: [SC-L] Managed Code and Runtime Environments - Another layer of added security?
Der Mouse is barking up the right rathole. *** BEGIN SOAPBOX *** Having cut my security eye-teeth in Multics from 1965 to 1969, I am continually drawn back into discussions of what Multics did right that has been systematically (!) ignored by almost all subsequent operating systems. For the younger folks among the SC-L audience, let me mention a few of the architectural strengths. There were no buffer overflows in the stack, because anything out of the stack frame was not executable. The ring-structured domain architecture and file system access controls permitted straightforward sandboxing. Dynamic linking and revocation were fundamental. Segmentation and paging enabled layers of virtual machines and protected virtual memory. The I/O system had virtual stream names, virtual I/O, and common device-driver software where appropriate, coupled with separate hardware for the input-output controller (GIOC). The programming language was the stark EPL subset of PL/I and the corresponding McIlroy-Morris EPL compiler, which seems to have avoided some of the characteristic programming errors that are still common today. No software was written until there was an approved specification, with well defined interfaces and exception conditions that were explicitly characterized in EPL. And so on into a visionary sense of a future that has been largely lost for may perceived reasons, some of which are bogus, some of which are just seriously short-sighted. *** END SOAPBOX *** I'm sure this message may generate all sorts of Ifs and Ands and Buts. But the Butt we are kicking is our own. Cheers! PGN ___ 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] Managed Code and Runtime Environments - Another layer of added security?
> Which brings us to the point of asking why we must have this run time > environment to protect the computing resources. Why isn't this a > function of and included in the Operating System code? Because "we" chose an OS that doesn't do that. > Is this like a firewall and IDS - just another layer we have to add > due to ineffective and insecure OS's? In a sense. But I'd put it in a way that slants it rather differently; I'd say that they are layers "we" have to add because "we" chose an OS that didn't include that stuff. It's not the OS's fault that it doesn't do something it's not designed to do. The real problem from this perspective is all the people who are picking Windows or Linux or something to run on their machines and then expecting it to have security properties it was never intended to have. Of course, if you try a "real" (from this security standpoint) OS, you will find that, as it must to achieve that level of assurance, it makes a lot of the things you've used to doing a lot harder. I suspect that between the additional up-front cost of such an OS and the inconvenience it imposes, most people prefer "add-on" security - less thorough but sufficiently less costly to tip the balance. (Actually, I suspect most people don't actually think about it and just grumble that the OS doesn't Just Do The Right Thing, even though that would require the mythical mind-reading peripheral.) > Are we dealing with symptoms or the real solution? Symptoms. The real problem is...well, depending on how you want to spin it, it could be "choosing the wrong OS for the job" or "the high cost of inconvenience" or various other things. /~\ 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
[SC-L] Software security efforts at DTCC
FYI, some more mainstream coverage of software security issues. This article -- http://www.securitypipeline.com/183702555;jsessionid=SF0AM1XSETTOEQSNDBECKICCJUMEKJVN -- describes some software security process improvements under way at the Depository Trust and Clearing Company (DTCC). What I find encouraging is hearing about companies that are bringing their security and software development efforts together. YMMV... Cheers, Ken -- Kenneth R. van Wyk KRvW Associates, LLC http://www.KRvW.com ___ 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
[SC-L] Managed Code and Runtime Environments - Another layer of added security?
Which brings us to the point of asking why we must have this run time environment to protect the computing resources. Why isn't this a function of and included in the Operating System code? Is this like a firewall and IDS - just another layer we have to add due to ineffective and insecure OS's? Are we dealing with symptoms or the real solution? Just wondering? ---Michael S Hines[EMAIL PROTECTED] ___ 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: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
This comes back to that great concept called 'Faith-based' Security (see Gunnar Peterson's post http://1raindrop.typepad.com/1_raindrop/2005/11/net_and_java_fa.html ), which is when people are told so many times that something is secure, that that they believe that it MUST be secure. Some examples:This is also neatly summarized by Brian Snow thusly:We will be in a truly dangerous stance: we will think we are secure (and act accordingly) when in fact we are not secure.-gp1. Notes and links on "We Need Assurance!" paperhttp://1raindrop.typepad.com/1_raindrop/2005/12/the_road_to_ass.html___ 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: [OWASP-LEADERS] Re: [Owasp-dotnet] RE: [SC-L] 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in 100% Managed Verifiable code
Hi Dinis, On 29 Mar 2006, at 05:52, Dinis Cruz wrote: Thanks for confirming this (I wonder how many other other Java developers are aware of this (especially the ones not focused on security)). Most I've worked with aren't really aware of the security manager, never mind bytecode verification. It is an issue, but the security risk in the real world may be a bit overstated. If I were a maliciously minded attacker that wanted users to execute my evil Java program, I wouldn't need to mess about with the lack of verification, I could just write evil code in perfectly verifiable format and rely on users to execute it. Can anyone come up with attack vectors that exploit lack of verification on downloaded code that couldn't be exploited by other (easier) means? Stephen, do you have any idea of what is the current percentage of 'real world' Java applications are executed: a) with verification b) on a secure sandbox Very few. As Jeff mentioned some Java Application servers ship with a security policy enabled, but the policy doesn't restrict anything (e.g. JBoss), other's show you how to run with a sec policy, but don't apply it by default (e.g. Tomcat). In some cases, with the more complex app servers a sec policy would be of little security benefit because the server needs so much access in order to function properly that the policy could be considered completely open. In some ways I think we're applying double standards here. Just because a virtual machine offers the facility for defining a security policy and verification doesn't mean that it _has_ to use it. There are native executable programs that I trust, so why should a program that runs in a VM be subject to more stringent security controls just because they're available? IMO whether code needs to be sandboxed and controlled by a policy should be decided on a case by case basis rather than a blanket rule. Note that for example I have seen several Java Based Financial Applications which are executed on the client which either require local installation (via setup.exe / App.msi) or require that the user grants that Java application more permissions that the ones allocated to a normal Sandboxed browser based Java App. This is quite common for an app, and granting more permissions is fine as long as those are tightly controlled by the java security policy. Humm, this is indeed interesting. Ironically, the 1.1 and 2.0 versions of the CLR will thrown an exception in this case (even in Full Trust). Since verification is not performed on that .Net Assembly, the CLR might pick up this information when it is resolving the method's relative address into the real physical addresses (i.e. during JIT). Using the same code with an Applet loaded from the filesystem throws an IllegalAccessError exception as it should. What do you mean by 'Applet loaded from the filesystem'? Where? In a Browser? If you load an applet in a browser using a url such as: file:///data/ stuff/launch.html then no verification is performed. But if you access the applet using http/s then it will be verified. cheers, -- Stephen de Vries Corsaire Ltd E-mail: [EMAIL PROTECTED] Tel:+44 1483 226014 Fax:+44 1483 226068 Web:http://www.corsaire.com ___ 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] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
> no, a browser written in java would not have buffer overflow/stack > issues. the jvm is specifically designed to prevent it ... And of course, we all know all JVM implementations are perfect. /~\ 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
[SC-L] Re: [Full-disclosure] Re: [Owasp-dotnet] Re: 4 Questions: Latest IEvulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in100% Managed Verifiable code
I just tried a few ways and couldn't figure anything out; It doesn't seem like you can modify a java.lang Class from outside the package (even unverified) and I also couldn't get my class _inside_ java.lang. Maybe BCEL can get further ... or maybe I missed something. -- Michael On 3/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I wonder if you could disable the default security manager with unverified > code. > > Probably. > > Hmm. > > -- Michael > > > On 3/29/06, Jeff Williams <[EMAIL PROTECTED]> wrote: > > > Jeff, as you can see by Stephen de Vries's response on this thread, > > > you are wrong in your assumption that most Java code (since 1.2) > > > must go through the Verifier (this is what I was sure it was > > > happening since I remembered reading that most Java code executed > > > in real-world applications is not verified) > > > > Wow. I ran some tests too, and Stephen is absolutely right. It appears > > that Sun quietly turned off verification by default for bytecode loaded from > > the local disk (not applets). They've apparently > > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4030988), acknowledged > > that it is a bug, and said that it will not be fixed. The change had > > something to do with compatibility with old bytecode. More details > > (http://www.cafeaulait.org/reports/accessviolations.html) > > > > This is a clear violation of the JVM Spec. And (regardless of protestation > > to the contrary) it IS a big security problem. Just because bytecode is > > loaded from the local disk does not mean it's trustworthy. Every > > application uses lots of libraries that developers download from the > > Internet (as compiled jar files) and loaded from the local disk. Unless you > > run with "java -verify" that code won't get verified. > > > > I'm sure that the percentage of applications that are running with both > > verification and sandbox is terrifyingly small. Probably only applets and > > maybe Java Web Start applications. As I mentioned before some of the J2EE > > servers are now enabling a sandbox, but their security policies are > > generally wide open. > > > > I think there are two relatively easy things we can do here. First, let's > > find out what plans Sun has for the new verifier -- we should strongly > > encourage them to turn it on by default. Second, we can work on ways to > > encourage people to use sandboxes -- tools, articles, and awareness. > > > > --Jeff ___ 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
[SC-L] Re: [Owasp-dotnet] Re: 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in100% Managed Verifiable code
I wonder if you could disable the default security manager with unverified code. Probably. Hmm. -- Michael On 3/29/06, Jeff Williams <[EMAIL PROTECTED]> wrote: > > Jeff, as you can see by Stephen de Vries's response on this thread, > > you are wrong in your assumption that most Java code (since 1.2) > > must go through the Verifier (this is what I was sure it was > > happening since I remembered reading that most Java code executed > > in real-world applications is not verified) > > Wow. I ran some tests too, and Stephen is absolutely right. It appears > that Sun quietly turned off verification by default for bytecode loaded from > the local disk (not applets). They've apparently > (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4030988), acknowledged > that it is a bug, and said that it will not be fixed. The change had > something to do with compatibility with old bytecode. More details > (http://www.cafeaulait.org/reports/accessviolations.html) > > This is a clear violation of the JVM Spec. And (regardless of protestation > to the contrary) it IS a big security problem. Just because bytecode is > loaded from the local disk does not mean it's trustworthy. Every > application uses lots of libraries that developers download from the > Internet (as compiled jar files) and loaded from the local disk. Unless you > run with "java -verify" that code won't get verified. > > I'm sure that the percentage of applications that are running with both > verification and sandbox is terrifyingly small. Probably only applets and > maybe Java Web Start applications. As I mentioned before some of the J2EE > servers are now enabling a sandbox, but their security policies are > generally wide open. > > I think there are two relatively easy things we can do here. First, let's > find out what plans Sun has for the new verifier -- we should strongly > encourage them to turn it on by default. Second, we can work on ways to > encourage people to use sandboxes -- tools, articles, and awareness. > > --Jeff > > > > > > --- > 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! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > ___ > Owasp-dotnet mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/owasp-dotnet > ___ 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
[SC-L] Re: [Full-disclosure] Re: Java integer overflows (was: a really long topic)
Obviously there is other issues around not sanitising the data
yourself, but in the context of the reply - i.e. buffer overflows for
arbitrary code exec - java is fully protected.
any access to an array is checked by the vm.
-- Michael
On 3/29/06, Eliah Kagan <[EMAIL PROTECTED]> wrote:
> > On 3/29/06, Andrew van der Stock wrote:
> > > This is not quite true.
> > >
> > > Java does not prevent integer overflows (it will not throw an
> > > exception). So you still have to be careful about array indexes.
>
> On 3/28/06, [EMAIL PROTECTED] replied:
> > No you dont.
> >
> > Arrays are all bounds checked; ..., that is, the following code will
> > throw an exception:
> >
> >
> > class Foo {
> > static {
> > int[] m = new int[2];
> > System.out.println(m[34]);
> > }
> > }
> >
> >
> >
> > What do you mean by "overflow"? Do you mean this?
> >
> >
> > class Foo {
> > static {
> > int m = Integer.MAX_VALUE;
> > int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
> > System.out.println(m);
> > System.out.println(k);
> > System.exit(0);
> > }
> > }
> >
> >
> > if so, I don't see how that is an issue.
> >
> > -- Michael
>
> That is an issue in a limited way--if you are trying to access a
> record with a high enough number (say by adding a number to a previous
> array index), you might end up accessing a record with a low number,
> which could potentially compromise the security of an application if
> certain assumptions are made. But this would only be within the same
> array that is already being accessed. The risk is minimal compared to
> the risks of accessing past the end of an array in, say, C.
>
> Even with bounds checking, there is no general way for a programming
> language to stop the programmer from writing a program that accesses
> the wrong piece of data in within a data structure, causing a security
> problem. Java was never designed to solve this sort of problem. Java
> does abstract data access so that many common bugs like buffer
> overflows are prevented, which is very useful.
>
> -Eliah
>
___
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
[SC-L] Re: Java integer overflows (was: a really long topic)
right,
but we're talking about unmanaged vs managed, and the earlier poster
(i think it might've been "pavel" [sorry if it wasn't]), said that
100% java is still vulnerable to buffer overflows. the fact is that it
isn't.
-- Michael
On 3/29/06, Andrew van der Stock <[EMAIL PROTECTED]> wrote:
> I'm not talking arbitrary code execution, I'm talking about odd code
> paths, bizarre outcomes, and DoS.
>
> For example (found via 19 Sins, Viega, Howard and LeBlanc):
> http://seclists.org/lists/bugtraq/2004/Nov/0097.html
>
> I know Michael reads webappsec, he may have more examples.
>
> In my own code testing, I look for silly behaviors if a user can
> insert a large or negative number. You'd be surprised how often it
> occurs. There is no excuse not to include basic range checks when
> performing data validation.
>
> thanks,
> Andrew
>
> On 29/03/2006, at 2:30 PM, [EMAIL PROTECTED] wrote:
>
> > No you dont.
> >
> > Arrays are all bounds checked; ..., that is, the following code will
> > throw an exception:
> >
> >
> > class Foo {
> > static {
> > int[] m = new int[2];
> > System.out.println(m[34]);
> > }
> > }
> >
> >
> >
> > What do you mean by "overflow"? Do you mean this?
> >
> >
> > class Foo {
> > static {
> > int m = Integer.MAX_VALUE;
> > int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
> > System.out.println(m);
> > System.out.println(k);
> > System.exit(0);
> > }
> > }
> >
> >
> > if so, I don't see how that is an issue.
> >
> > -- Michael
> >
> >
> >
> > On 3/29/06, Andrew van der Stock <[EMAIL PROTECTED]> wrote:
> >> This is not quite true.
> >>
> >> Java does not prevent integer overflows (it will not throw an
> >> exception). So you still have to be careful about array indexes.
> >>
> >> Andrew
___
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
[SC-L] Java integer overflows (was: a really long topic)
I'm not talking arbitrary code execution, I'm talking about odd code
paths, bizarre outcomes, and DoS.
For example (found via 19 Sins, Viega, Howard and LeBlanc):
http://seclists.org/lists/bugtraq/2004/Nov/0097.html
I know Michael reads webappsec, he may have more examples.
In my own code testing, I look for silly behaviors if a user can
insert a large or negative number. You'd be surprised how often it
occurs. There is no excuse not to include basic range checks when
performing data validation.
thanks,
Andrew
On 29/03/2006, at 2:30 PM, [EMAIL PROTECTED] wrote:
No you dont.
Arrays are all bounds checked; ..., that is, the following code will
throw an exception:
class Foo {
static {
int[] m = new int[2];
System.out.println(m[34]);
}
}
What do you mean by "overflow"? Do you mean this?
class Foo {
static {
int m = Integer.MAX_VALUE;
int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
System.out.println(m);
System.out.println(k);
System.exit(0);
}
}
if so, I don't see how that is an issue.
-- Michael
On 3/29/06, Andrew van der Stock <[EMAIL PROTECTED]> wrote:
This is not quite true.
Java does not prevent integer overflows (it will not throw an
exception). So you still have to be careful about array indexes.
Andrew
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
[SC-L] Re: [Full-disclosure] 4 Questions: Latest IE vulnerability, Firefox vs IE security, User vs Admin risk profile, and browsers coded in 100% Managed Verifiable code
No you dont.
Arrays are all bounds checked; ..., that is, the following code will
throw an exception:
class Foo {
static {
int[] m = new int[2];
System.out.println(m[34]);
}
}
What do you mean by "overflow"? Do you mean this?
class Foo {
static {
int m = Integer.MAX_VALUE;
int k = Integer.MAX_VALUE + Integer.MAX_VALUE;
System.out.println(m);
System.out.println(k);
System.exit(0);
}
}
if so, I don't see how that is an issue.
-- Michael
On 3/29/06, Andrew van der Stock <[EMAIL PROTECTED]> wrote:
> This is not quite true.
>
> Java does not prevent integer overflows (it will not throw an
> exception). So you still have to be careful about array indexes.
>
> Andrew
>
> On 29/03/2006, at 12:49 PM, [EMAIL PROTECTED] wrote:
>
> > no, a browser written in java would not have buffer overflow/stack
> > issues. the jvm is specifically designed to prevent it ...
> >
> > -- 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
[SC-L] Re: 4 Questions: Latest IE vulnerability, Firefox vs IE security, Uservs Admin risk profile, and browsers coded in100% Managed Verifiable code
> Jeff, as you can see by Stephen de Vries's response on this thread, > you are wrong in your assumption that most Java code (since 1.2) > must go through the Verifier (this is what I was sure it was > happening since I remembered reading that most Java code executed > in real-world applications is not verified) Wow. I ran some tests too, and Stephen is absolutely right. It appears that Sun quietly turned off verification by default for bytecode loaded from the local disk (not applets). They've apparently (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4030988), acknowledged that it is a bug, and said that it will not be fixed. The change had something to do with compatibility with old bytecode. More details (http://www.cafeaulait.org/reports/accessviolations.html) This is a clear violation of the JVM Spec. And (regardless of protestation to the contrary) it IS a big security problem. Just because bytecode is loaded from the local disk does not mean it's trustworthy. Every application uses lots of libraries that developers download from the Internet (as compiled jar files) and loaded from the local disk. Unless you run with "java -verify" that code won't get verified. I'm sure that the percentage of applications that are running with both verification and sandbox is terrifyingly small. Probably only applets and maybe Java Web Start applications. As I mentioned before some of the J2EE servers are now enabling a sandbox, but their security policies are generally wide open. I think there are two relatively easy things we can do here. First, let's find out what plans Sun has for the new verifier -- we should strongly encourage them to turn it on by default. Second, we can work on ways to encourage people to use sandboxes -- tools, articles, and awareness. --Jeff ___ 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
