> 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
-------------------------------------------------------------------------
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
https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=701300000003gRl
--------------------------------------------------------------------------
Received on Mar 30 2006
Intro
