esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <vdic...@apache.org>
Subject Re: Scala interpreter action
Date Sun, 05 Jul 2009 20:52:49 GMT
> While this feature is interesting, I have to ask that we remove it.
>
> It's a security hole.  It's problematic in that it makes the messages sent
> to any server with the feature enabled insecure.  Once we get federation (I
> know, I know I keep promising and not delivering federation), then we're
> going to have to care more about trusting servers in the given federation.
> Allowing one of those servers to be compromised by simply having this
> feature turned on, then it makes the federation one of suspicion.
>
> Or, put another way, Outlook allowed for arbitrary execution of VB code in
> payloads which led to 10 years of virus/worm fighting.  Now, I know this
> feature is not arbitrary code execution of message payloads, there will be
> someone creates a script that has a code injection vulnerability in it.
>
> So, while this feature feels kind good, I'd much rather see the feature done
> as execution of JavaScript code via Rhino in a high security sandbox (which
> is possible with Rhino.)

Actually, the Scala interpreter is already creating a classloader
sandbox in a way which is probably similar to Rhino.

I just tried to load ESME or Lift classes and I couldn't. I thought
that's detracting from ESME's functionality, but now I see it is a
security bonus. The only classes accessible are from the Scala
compiler and library jars. The reason for this is that the interpreter
is creating a separate classloader:

http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/compiler/scala/tools/nsc/Interpreter.scala#L143

This would mean that the code executed is subject to a similar lever
of isolation as e.g. different J2EE apps running side-by-side in a
secure J2EE container. It is still possible to shut down the JVM, but
not tamper with the data of ESME running in the same JVM. Shutting
down the JVM and executing OS code can (and should) be controlled by
setting up security policies.

Anyway, one cannot trust a server if you cannot trust its
administrators. Nobody could stop a malicious administrator from
compiling a modified version of ESME, which would be compromised even
without the Scala embedded interpreter.

I do think the feature should be inspected by a security professional;
we have 2 choices here: remove it and wait for the expert to say yes,
or keep it and wait for an expert to say no. If David still insists
it's a vulnerability, I'll revert the commit.

Vassil

Mime
View raw message