Marc Schoenefeld wrote:
:
Even if there is a security manager, you need still to make sure that no
privileged code (having access rights to sun.*) forwards tainted data
to the
vulnerable sun.* functions.
Until 2007 you could use the sun.misc.MessageUtils.toStderr bug to
reliably crash OpenOffice in the OObase startup database/script
by calling sun.* via HSQLDB (CVE-2007-4575) .
SET DATABASE COLLATION "Latin1_General"
[...]
SELECT * FROM "FirstTable"
WHERE ID="sun.misc.MessageUtils.toStderr"(NULL);
To my knowledge Java in Openoffice still does not use a security manager
in all places yet, so this problem was fixed by blocking arbitrary
class access in HSQLDB.
So the intention is to finally fix the root cause, instead of
furthermore allowing this to cause trouble in unexpected places :)
If there isn't a security manager then there aren't any checks and so
code can do any manner of nasty thing. We can fix sun.misc.MessageUtils
and that solves that specific issue but it doesn't stop code calling
System.exit to terminate the VM or using public APIs to delete your
files. I'm not familiar with how OO uses the runtime but preventing it
from running arbitrary code sounds right.
Lillian - are you taking this one with a view to getting it into
jdk7/tl/jdk? (I wasn't sure if you were looking for someone to take it).
-Alan.
