What you want is byte-code engineering. Apache has an implementation. it
allows you to look at class files and discern all that byte code as objects
and variables (and alter them if you want). That will help you more than
grep.
Requiring a security manager, while a good idea, is risky. If you really
need to use an application and it was written without a security manager, it
might not work at all if you use a security manager. Some code will break.
It's a shame but this is the case I see everywhere: the Java authors never
thought about how important it is that a security architecture be easy to
use. Since it's a pain in the butt for most people to program with, people
simply don't use it. And that makes poor security.
Now if you know Java, what you could do is write a dynamic proxy that wraps
the classes of this application and either blocks actions or pops up message
boxes with prompts asking if you want to terminate the action. Again, you
might break the application doing that, but at least you'll be safe.
>From: Mark Curphey <mark_at_curphey.com>
>Reply-To: mark_at_curphey.com
>To: "Scovetta, Michael V" <Michael.Scovetta_at_ca.com>,"Peter Lee, Kah Chen"
><peterlee_at_crimsonlogic.com>,<webappsec_at_securityfocus.com>
>Subject: RE: Java Code Scanning
>Date: Wed, 07 Jan 2004 12:49:40 -0500 (EST)
>
>I am sure you understand the limitations of just grepping for strings etc
>but that said a while back when I was teahcing myself Java I wrote a small
>app to automate finding the Ten Issues in the Securing Java book.
>
>www.securingjava.com
>
>I checked the online version and I can't see the checks now but . the app I
>wrote is ....
>
>http://cvs.sourceforge.net/viewcvs.py/owasp/codespy/
>
>It looks for things like access modifiers and so on. May be of help.
>
>---- "Scovetta, Michael V" <Michael.Scovetta_at_ca.com> wrote:
> > Peter,
> > If your application is running in a "secure" context (applet or with
> > a specific security manager in place) then there shouldn't be anything
>that
> > could be malicious (you can disable the ability to access the filesystem
>and
> > network). If not, then you might want to look for calls using:
> > java.io.File
> > java.net.*
> > keyword 'native' (implied JNI calls, which are not protected
> > by the Java security model)
> > java.lang.Process
> > java.lang.Runtime
> >
> > I'm sure there are more, but other than running up your CPU, if an
>application
> > can't use the network or the file system, can't break out to another
>process,
> > and can't use JNI, I think you might be maybe 90% safe.
> >
> > Michael Scovetta
> >
> > -----Original Message-----
> > From: Peter Lee, Kah Chen [mailto:peterlee_at_crimsonlogic.com]
> > Sent: Wednesday, January 07, 2004 1:57 AM
> > To: webappsec_at_securityfocus.com
> > Subject: Java Code Scanning
> >
> >
> > Hi there and a good day to you,
> >
> > Cutting to the chase; if I am to do a textual scan of a piece of Java
> > application code for potential malicious code embedded, what are the key
> > words to scan for?
> >
> > For example in the case of C/C++ program; I might look for memory
> > handling code i.e memcpy(), strcpy(), strdup(), memset(), system
> > execution code sys(), exec(), fork(), etc. IPC & RPC calls. Codes which
> > try to access password directory that sort of thing.
> >
> > The idea is not to look for bad code writing, but to identify/flag code
> > which may have security implications for more detailed sturdy or even
> > code walkthrough.
> >
> > Anyone have a list of keywords to search with?
> >
> > Thanks!
> >
> > Peter
> >
> >
> >
_________________________________________________________________
Expand your wine savvy — and get some great new recipes — at MSN Wine.
http://wine.msn.com
Received on Jan 07 2004
Intro
