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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
15 matches
Mail list logo
