Java-based expression languages provide significant flexibility when using middleware products such as Business Rules Management System (BRMS). This flexibility comes at a price as there are significant security concerns in their use. In this article MVEL is used in JBoss BRMS to demonstrate some of the problems. Other products might be exposed to the same risk.

MVEL is an expression language, mostly used for making basic logic available in application-specific languages and configuration files, such as XML. It’s not intended for some serious object-oriented programming, just simple expressions as in “data.value == 1″. On a surface it doesn’t look like something inherently dangerous.

JBoss BRMS is a middleware product designed to implement Business Rules. The open source counterpart of JBoss BRMS is called drools. The product is intended to allow businesses (especially financial) to implement the decision logic used in their organization’s operations. The product contains a rules repository, an execution engine, and some authoring tools. The business rules themselves are written in a drools rules language. An interesting approach has been chosen for the implementation of drools rules language. The language is complied into MVEL for execution, and it allows the use of MVEL expressions directly, where expressions are applicable.

There is however an implementation detail that makes MVEL usage in middleware products a security concern. MVEL is compiled into plain Java and, as such, allows access to any Java objects and methods that are available to the hosting application. It was initially intended as an expression language that allowed simple programmatic expressions in otherwise non-programmatic configuration files, so this was never a concern: configuration files are usually editable only by the site admins anyway, so from a security perspective adding an expression in a config file is not much different from adding a call in a Java class of an application and deploying it. The same was true for BRMS up to version 5: any drools rule would be deployed as a separate file in repository, so any code in drools rules would be only available for deployment by authorized personnel, usually as part of the company workflow following the code review and other such procedures.

This changed in BRMS (and BPMS) 6. A new WYSIWYG tool was introduced that allowed constructing the rules graphically in a browser session, and testing them right away. So any person with rule authoring permissions (role known as “analyst” rather than “admin”) would be able to do this. The drools rules would allow writing arbitrary MVEL expressions, that in turn allow any calls to any Java classes deployed on the application server without restrictions, including the system ones. This means an analyst would be able to write Sys.exit() in a rule and testing this rule would shut down the server! Basically, the graphical rule editor allowed authenticated arbitrary code execution for non-admin users.

A similar problem existed in JBoss Fuse Service Works 6. While the drools engine that ships with it does not come with any graphical tool to author rules, so the rules must be deployed on the server as before, it comes with RTGov component that has some MVEL interfaces exposed. Sending an RTGov request with an MVEL expression in it would again allow authenticated arbitrary code execution for any user that has RTGov permissions.

This behaviour was caught early on in the development cycle for BxMS/FSW version 6, and a fix was implemented. The fix involves running the application server with Java Security Manager (JSM) turned on, and adding extra configuration files for MVEL-only security policies. After the fix was applied, only the limited number of Java classes were allowed to be used inside MVEL expressions, which were safe for use in legitimate Drools rules and RTGov interfaces, the specific RCE vulnerability was considered solved.

Further problems arose when products went into testing with the fix applied and some regressions were run. It was discovered that it wasn’t a good idea to make the fix with JSM enabled the default setup for productions servers as this caused the servers would run slow. Very slow. Resource consumption was excessive and performance suffered dramatically. It became obvious that making MVEL/JSM fix the default for high-performance production environment was a not an -option.

A solution was found after considerable consultation between Development, QE and Project Management. The following proposals where made for any company running BRMS:

• When deploying BRMS/BPMS on a high-performance production server, it is suggested to disable JSM, but at the same time not to allow any “analyst”-role users to use these systems for rule development. It is recommended to use these servers for running the rules and applications developed separately and achieving maximum performance, while eliminating the vulnerability by disabling the whole attack vector by disallowing the rule development altogether.
• When BRMS is deployed on development servers used by rule developers and analysts, it is suggested to run these servers with JSM enabled. Since these are not production servers, they do not require mission critical performance in processing real-time customer data, they are only used for application and rule development. As such, a little sacrifice in performance on a non mission-critical server is a fair trade-off for a tighter security model.
• The toughest situation arises when a server is deployed in a “BRMS-as-a-service” configuration. In other words when rule development is exposed to customers over the Web (even through VPN-protected Extranet). In this case no other choice is available but to enable complete JSM protection, and accept all the consequences of the performance hit. Without it, any customer with minimal “rule writing and testing” privileges can completely take over the server (and any other co-hosted customers’ data as well), A very undesirable result to avoid.

Similar solutions are recommended for FSW. Since only RTGov exposes the weakness, it is recommended to run RTGov as a separate server with JSM enabled. For high performance production servers, it is recommended not to install or enable the RTGov component, which eliminates the risk of exposure of MVEL-based attack vectors, making it possible to run them without JSM at full speed.

Other approaches are being considered by the development team for new implementation of MVEL fix in the future BRMS versions. Once such idea was to run a dedicated MVEL-only app server under JSM separate from the main app server that runs all other parts of the applications, but other proposals were talked about as well. Stay tuned for more information once the decisions are made.