[Owasp-guide] Should ESAPI and/or the OWASP Dev Guide address insider malware?

Kevin W. Wall kevin.w.wall at gmail.com
Sat Apr 24 13:44:39 EDT 2010


Yesterday, I just finished reading the paper "Back Door into Java EE
Application Servers" by Philippe Prados that was published as part of
the Macaron project. (The English version of the paper is at:
http://macaron.googlecode.com/files/en-macaron.pdf)

While there isn't too much earth-shattering news here, it does describe
several techniques of how one--especially a rogue insider--can
surreptitiously introduce a back door into a Java EE application.
An while these techniques are (to my knowledge) not yet common,
they look rather easy to pull off, especially if one is only trying
to inject some malevolent logic bomb rather than a full-blown back
door.

As far as I can tell, ESAPI presently has nothing that would assist
in preventing the types of exploitations outlined in the paper and
the example working code.

I believe that future versions of ESAPI (e.g., 2.1 and later) could
add classes to assist in remediation.  For instance, one possibility
would be to provide a class loader that would only load classes
that came from signed (or signed and sealed) jars. That is not too
difficult to write, but it can really be a performance hit, so
one would probably wish to require certain critical classes to be checked,
maybe based on package name or jar file name, etc. and other classes
would not be examined to see if they are signed / sealed. (Alternately,
one could do this checking at deployment time outside of the application,
but that given that classes can be defined dynamically or the classes can
be loaded explicitly, it is somewhat less accurate.)

Another way that ESAPI could provide assistance to provide a "audit only"
version of a security manager that would do something very similar to
what SELinux's audit2allow program does, which is to audit all security
checks and record a list of resources being checked along with requested
permissions and the current identity and set of roles / principals held.
This information would be then used (possibly by another tool) to turn it
into a security policy. (Perhaps something like this already exists. You
would think that it should, but I honestly haven't checked because where I
work, is interested in using a Java security manager, in part because it's
so hard to get the security policy correct.)

If future versions of ESAPI doesn't address things like issues identified
on the Macron paper, perhaps in should be addressed in some section of the
OWASP Dev Guide? (Or both, for that matter.)

Anyhow, just interested in hearing people's thoughts on this.

-kevin
-- 
Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME



More information about the Owasp-guide mailing list