Re: detecting nasty class/jar files - statically ?
- From: "Chris Uppal" <chris.uppal@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 16 Mar 2007 14:10:16 -0000
Tom Hawtin wrote:
There are so many things that can be done by an adversary. You need to
get lucky right across all APIs. An attacker only needs one hole. Your
chances of anything other than security by obscurity are slim.
It's something of a truism of security that, in any complex system, attempting
to create a "blacklist" of disallowed operations is going to leave holes. The
"normal" (i.e. best) practise is to use a whitelist of allowed operations, and
forbid everything else.
But I wonder how close you could get...
I think (ignoring the possibility of bugs in the JVM) you could automate part
of the generation of the whitelist. A method is safe if and only if:
1a) it cannot be overridden, or
1b) it is only overridden by safe methods;
2) it is not native[*];
3) it does not use the facilities of sun.java.unsafe.* or any other
JVM-level backdoor[**];
4) it calls no other method which is not itself safe;
[*] There are several independent reasons to treat any code which touches JNI
as unsafe:
a) JNI code is completely unregulated and can do /anything/ (e..g
substitute its own code for any chosen class's own native methods...
b) JNI code cannot be verified by the above algorithm, so you have to
assume that it's unsafe.
c) JNI code is likely to include exploitable holes (like buffer overflows,
etc).
d) (most importantly) ultimately, any code which /does/ anything/ is going
to do it via JNI so this is the place to look for things which shouldn't
be allowed, or which are susceptible to abuse.
[**] There are quite a few JVM-level backdoors, but I think most of them could
be certified safe by inspection.
Note that:
+ (1b) can only be verified by whole-program analysis unless (1a) is
already satisfied.
+ Whole-program analysis is impossible if there is any mention of
classloaders anywhere,
(even in platform code, and even if restricted to platform supplied
Classloader subclasses).
+ (4) excludes most reflective calls.
+ (4) excludes instantiating or referring to any [member of any] class
whose <clinit> method is not safe.
At a rough guess, and assuming you whitelist System.out.println() (and
friends), you might be left with enough features to be able to certify as safe
solutions to the exercises from the first couple of chapters in a beginner's
Java book ;-)
But then, perfect security is a mirage -- there is no such thing, and even
thinking in those terms is misleading. It would be better to consider if any
of the above techniques would usefully /improve/ the safety of the application
(bearing in mind the degree of risk involved and the costs of reducing it).
-- chris
.
- References:
- detecting nasty class/jar files?
- From: Andreas Leitgeb
- Re: detecting nasty class/jar files?
- From: Andrew Thompson
- Re: detecting nasty class/jar files - statically ?
- From: Andreas Leitgeb
- Re: detecting nasty class/jar files - statically ?
- From: Tom Hawtin
- detecting nasty class/jar files?
- Prev by Date: Re: query regarding static metods
- Next by Date: Re: Learning Eclipse
- Previous by thread: Re: detecting nasty class/jar files - statically ?
- Next by thread: Re: detecting nasty class/jar files?
- Index(es):
Relevant Pages
|