full-disclosure - Java integer overflows (was: a really long topic)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060329224305.4B2E3DD4@lists.grok.org.uk>
Date: Thu Mar 30 00:40:57 2006
From: tholleb at teknowledge.com (Tim Hollebeek)
Subject: Java integer overflows (was: a really long
	topic)

> 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