Seems to me that such ranges are application specific and
therefore your problem, not the JVMs. You're describing a bug
in your code, due to failure to validate, not a bug in the
JVM which behaves exactly (and quite possibly provably)
according to its specification.
So you're saying that if I write code that fails to validate
array bounds, and something bad happens, it is the
compiler/runtime's fault, but if I write code that fails to
validate integer bounds, it is the programmer's fault?
That's a rather circular defense of JVMs, in which JVMs are
praised for stopping the types of errors they choose to
check, and also praised for not stopping the ones they
could (but don't!). There *ARE* languages where integer
variables have checked ranges, after all.
The point (which too many people in this thread seem to be missing)
is that there are lots of kinds of security relevant code
flaws. Better tools, OSs, runtimes, etc catch more of them,
but none catches all of them (for example, serious race
conditions are still possible in almost all development styles
and environments). The world is not going to be saved by managed
code or JVMs or signed code or nonexecutable stacks or better
education of developers or users. Finally being immune to
classes of security flaws that were first used four decades
ago is nice, but don't let it lull you into a false sense of
security.
Tim Hollebeek
Research Scientist
Teknowledge Corp
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
