nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

BIRT Scripting - restricting certain Java functionality to fix security vunerability

Edd

About a year ago I integrated BIRT 2.6.0 into a web app project. The project has a reports section, whereby the idea is that users with certain privileges can upload their own report design files to the project. Other users can then view these generated reports. 
 
A user of this project has just pointed out that it is possible for those report 'authors' to upload reports with scripts that are potentially harmful to the server hosting the project web application. 
 
How can I lock down what report scripts can actually do? 
 
I've just tried running a report in Eclipse that had a single line of script: 
 
<pre class='_prettyXprint _lang-auto _linenums:0'>java.lang.Runtime.getRuntime().exec("C:/Program Files/Notepad++/notepad++.exe");</pre>
 
Switching to the preview tab in Eclipse and sure enough, my installation of Notepadd++ is opened. I uploaded this report to my webapp and the same thing happened. I guess I'm surprised that this kind of script isn't locked down already, but regardless, how do I do that? 
 
My initial thoughts are the Report Engine's config.ini file and it's eclipse.security property would be handy...point it to a security manager that has a strict policy on permissions. Is there an easier way? 
 
Would there be any extra setup in the APIs? My project uses the ReportEngine instance to create a IRunAndRenderTask, I can't find any 'set security ...' methods. 
 
Thanks

Find more posts tagged with

Comments

Edd

I'm getting somewhere but any advice would be greatly welcomed... 
 
Solution one: 
 
Enabling Java's security manager (possibly using Tomcat's catalina.policy file - see more <a class='bbc_url' href='http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html'>here</a>) and setting up a sandbox environment along the lines as this blog posts suggests: <a class='bbc_url' href='http://codeutopia.net/blog/2009/01/02/sandboxing-rhino-in-java/'>Simple JVM sandboxing</a>. One concern here is how I might go about calling AccessController.doPrivileged() without modifying BIRT code. 
 
Solution two: 
 
Using Rhino's <a class='bbc_url' href='http://www-archive.mozilla.org/rhino/apidocs/org/mozilla/javascript/ClassShutter.html'>ClassShutter</a> interface, where Rhino is the library BIRT calls upon to execute the scripts within a report. This seems like a promising route, but for it to work, we'd need to allow access to org.eclipse.birt classes, otherwise it fails to startup. 
 
A blog post that has been really helpful is this one: <a class='bbc_url' href='http://codeutopia.net/blog/2009/01/02/sandboxing-rhino-in-java/'>Sandboxing Rhino in Java</a> 
 
If anyone has any more suggestions or help they can offer, please let me know. 
 
Thanks

Edd

Hmmm...so BIRT has it's own implementation of the <a class='bbc_url' href='http://www-archive.mozilla.org/rhino/apidocs/org/mozilla/javascript/ContextFactory.html'>ContextFactory</a> class, that it sets statically. Is this not quite wrong? Doesn't this then mean that any other code outside of BIRT in the same application using Rhino's scripting is going to potentially have conflicting expectations as to what script sandboxing (and script context listeners) is doing? 
 
The class org.eclipse.birt.report.engine.javascript.JavascriptEngineFactory seems a little suspect. Firstly it has the line: 
 
<pre class='_prettyXprint _lang-auto _linenums:0'>ContextFactory.initGlobal( new MyFactory( ) )</pre>
 
This seems wrong that a library designed for integration into existing applications would statically modify the context factory, and hence potentially undoing any security applied to scripting elsewhere in the application (given that listeners could be attached to the original global instance). In addition, the following bit of code seems a little worrying...using reflection to change a field in a class that would normally not be accessible... 
 
JavascriptEngineFactory#destroyMyFactory 
<pre class='_prettyXprint _lang-auto _linenums:0'>
ContextFactory factory = ContextFactory.getGlobal( );
if ( factory != null && factory instanceof MyFactory )
{
try
{
Class factoryClass = Class
.forName( "org.mozilla.javascript.ContextFactory" );
Field field = factoryClass.getDeclaredField( "hasCustomGlobal" );
field.setAccessible( true );
field.setBoolean( factoryClass, false );
field = factoryClass.getDeclaredField( "global" );
field.setAccessible( true );
field.set( factoryClass, new ContextFactory( ) );
}
catch ( Exception ex )
{
logger.log( Level.WARNING, ex.getMessage( ), ex );
}

}
</pre>

JasonW

Edd,

Any chance you could open a bugzilla entry with these findings? BTW for JAAS with the viewer you can reference:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=182161

Jason