Security risks with higher level languages in middleware products

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

Java-based high-level application-specific languages provide significant flexibility when using middleware products such as BRMS. This flexibility comes at a price as there are significant security concerns in their use. In this article the usage of Drools language and MVEL in JBoss BRMS is looked at to demonstrate some of these concerns. Other middleware products might be exposed to similar risks.

Java is an extremely feature-rich portable language that is used to build a great range of software products, from desktop GUI applications to smartphone apps to dedicated UIs for hardware such as printers to a breadth of server-side products, mostly middleware. As such, Java is a general-purpose language with a rather steep learning curve and strict syntax, well suited for complex software projects but not very friendly for writing simple scripts and one-liner pieces of code.

Several efforts emerged over time to introduce Java-based or Java-like scripting functionality, with probably the most famous one being Javascript: a language that is not based on Java but appearing similar to Java in several aspects; and it is well-suited for scripting.

Another example of a simplified language based on Java is MVEL. 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, but mainly simple expressions as in "user.getManager().getName() != null". However simple, MVEL is still very powerful and allows the use of any Java APIs available to the developer; its strength is its simplified syntax which doesn’t restrict the ability to call any code the developer may need access to.

Yet another example of a Java-based application-specific language is the Drools rules language. It is used in JBoss BRMS, a middleware product that implements Business Rules, and its open source counterpart Drools. There is a similar idea behind the Drools language: to hide all the clutter of Java from the rules developer and provide a framework that makes it easy to concentrate on the task at hand (namely: writing business rules) without compromising the ability to call any custom Java code that might be needed to properly implement the organisation's business logic.

Developers of Java middleware products, starting with application servers and continuing to more complex application frameworks, traditionally invest a great deal of effort into making their products secure. This includes: separating the product’s functionality into several areas with different levels of risk; applying user roles to each of these areas; authorization and authentication of users; audit of the available functionality to evaluate the risk of using this functionality for unintended tasks that could potentially lead to compromises, etc. In this context it is important to understand that the same rich feature set and versatility that makes Java so attractive as a developer platform also becomes its Achilles heel when it comes to security: every so often one of these features finds its way into some method of unintended use or another.

In this article I will look at one such case where a very flexible feature was added to one of the middleware products that was later discovered to include unsafe consequences, and the methods used to patch it.

JBoss BRMS, mentioned above, had a role-based security model from the very beginning. Certain roles would allow deployment of new rules and certain development processes would normally be established to allow proper code review prior to deployment. These combined together would ensure that only safe code is ever deployed on the server.

This changed in BRMS (and BPMS) 6. A new WYSIWYG tool was introduced that allowed for 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. As an example, an analyst would be able to write System.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 the 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 enabling specific security policies for user-provided code. After the fix was applied, only a limited number of Java instructions were allowed to be used inside user-provided expressions, which were safe for use in legitimate Drools rules and RTGov interfaces, and the specific RCE (Remote Code Execution) vulnerability was considered solved. Essentially a similar security approach was taken as for running Java applets in a sandbox within a browser, where an applet can only use a safe subset of the Java library.

Some side-effects were detected when products went into testing with the fix applied and performance regression was executed. It was discovered that certain tests ran significantly slower with JSM enabled than on an unsecured machine. This slowdown was significant only in those tests that took into account only the raw performance of rules, not “real-world” scenarios, since any kind of database access would slow down the overall performance anyway, much more significantly than enabling the JSM. However, certain guidelines were developed in order to help customers achieve the best possible balance of speed and security.

When deploying BRMS/BPMS on a high-performance production server, it is possible 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, as they are only used for application and rule development. As such, the overhead of the JSM is not noticeable on a non mission-critical server and it is a fair trade-off for a tighter security model.

When a server is deployed in a "BRMS-as-a-service" configuration, or in other words when rule development is exposed to customers over the Web (even through a VPN-protected Extranet), enabling the complete JSM protection is the recommended approach, accepting the JSM overhead. 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 situation 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 user-provided code-based attack vectors, making it possible to run them without JSM at full speed.

This kind of concern is not specific to JBoss products but is a generic problem potentially affecting any middleware system. Any time rich functionality is made available to users, some of it may be used for malicious purpose. Red Hat takes security of the customers very seriously and every effort is made not only to provide the customers with the richest functionality, but also making sure this functionality is safe to use and proper safe usage guidelines are available.