
Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
> What you could do in create a list of packages that would have to be
> present for various types of error to be made. Then you could at
> least provide a list of source files with what needs to be checked.
> You could also create some regexes that looked for certain methods and
> could automate some check to decide : good, bad, irrelevant, unknown.
Grep is great for finding bugs, but I think byte code analysis will be
better for making sure you haven't missed any bugs.
It's like the difference between finding a counter example in a
mathematical hypothesis and creating a proof without flaws.
> Since you can wrap the crucial methods so many levels deep, I can't
> see how you would statically be able to check. Perhaps you could do
> it by adding monitoring code on crucial methods to log important facts
> as the program ran using the debug interface.
Tainting seems to have some success. Mark values from external sources
as tainted, and watch for their use in sensitive methods.
A different approach that seems to be becoming more popular recently is
fuzzing. Take a load of valid data, make random corruptions and see if
it is handled incorrectly. For example, in the late nineties testing for
the Kimera JVM found 21 errors (not necessarily exploitable security
bugs) in the Sun JVM.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Chris Uppal - 22 Apr 2006 18:29 GMT
> Tainting seems to have some success. Mark values from external sources
> as tainted, and watch for their use in sensitive methods.
A quick, distinctly limited, and very, very dirty approximation -- but one
which I nevertheless suspect would expose /lots/ of potential flaws -- would be
to check that the SQL String parameter to [implementations of]
java.sql.Statement.execute(), and the like, satisfies:
sql == sql.intern()
-- chris
Thomas Hawtin - 22 Apr 2006 18:20 GMT
> A quick, distinctly limited, and very, very dirty approximation -- but one
> which I nevertheless suspect would expose /lots/ of potential flaws -- would be
> to check that the SQL String parameter to [implementations of]
> java.sql.Statement.execute(), and the like, satisfies:
>
> sql == sql.intern()
Heh. I think the downside is that if you reported that sort of flaw to
the author, then the author would be the sort of person to fix it with
statement.execute(sql.intern())...
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Chris Uppal - 23 Apr 2006 10:35 GMT
> > sql == sql.intern()
>
> Heh. I think the downside is that if you reported that sort of flaw to
> the author, then the author would be the sort of person to fix it with
> statement.execute(sql.intern())...
Sadly, I agree that that would likely happen.
Then it's P45 time.
-- chris