Hide Forgot
Date of First Response: 2008-12-08 05:57:43 project_key: SOA By embedding script tags in processdefinition.xml used for process definition upload, any thinkable java code can be executed during the event hooks provided by jbpm. This issue was supposed to be fixed by SOA-265, but we think the fix to SOA-265 did not properly close the potential security pole. The ideal solution is to use a "sandbox". All relevant comments and discussions can be found from http://jira.jboss.com/jira/browse/SOA-265 and https://jira.jboss.org/jira/browse/SOA-313
Deployments of a jbpm processes should indeed not be handled different than any other deployment to the JBoss AS i.e. everything goes through the main deployer This is subject of [JBPM-1883] and [JBPM-1884] which I will hopefully have resolved in 3.3.1 (1-Jan-2009). When the deployers are in place the upload servlet should be disabled by default.
Link: Added: This issue is a dependency of SOA-313
Hi Thomas, I just went through the long discussions and comments we had from SOA-265 and SOA-313 again, I am not seeing how a AS4 deployer (as JBPM-1883 and JBPM-1884 suggested) is going to solve this security hole problem. The issue which I believe, is the JBPM event can execute arbitrary code (for example, the processdefinition.xml may contain a call of System.exit(0)). The solution provided by SOA-265 did not close this security hole properly i.e., by using a production version of jbpm-console.war. See the comment from Anil Saldhana (the latest comments from SOA-313): "Introduction of a privileged block to run the script is in fact a security hole that will be introduced by SOA. This is because typically all JBoss code will run with lenient permissions as JBoss code is trusted. If the JBoss code introduces a privileged block to run a user configured script, then the user will be able to do dangerous things such as vm exit, load classloader etc etc. There should no privileged block to run the user script. A security manager will outright deny a user trying to do dangerous things."
Link: Added: This issue depends GPD-278
How is System.exit(0) in a script node different from System.exit(0) in a arbitrary Action~, Event~, Exception~, DecisionHandler or any other java code that can be executed as part of jbpm? For the sake of argument, how is this different to System.exit(0) called from a Servlet that can be deployed to JBoss? My point is, that access to the JBoss deployment system must be restricted to prevent malicious deployments, because any deployment (not just jbpm scripts) can in fact be malicious. A deployment that makes it into JBoss must inherently be trusted because JBoss does not have the notion of code being executed in a sandbox as it is the case with java applets in a browser. The biggest security hole in jBPM is indeed that it circumvents the JBoss deployer arcitecture. On top of this general issue, we can think of additional security measures that work on the level of specific jbpm functionality.
> any other java code that can be executed as part of jbpm? For the sake of argument, how is this different to System.exit(0) called from a Servlet that can be deployed to JBoss? Security.policy files can be in place to prevent classes other than the ones in e.g. the org.jboss domain to execute a System.exit(0), so indeed it is a more generic issue. Afaik, Oracale/Bea WLS uses this to prevent exactely this > A deployment that makes it into JBoss must inherently be trusted because JBoss does not have the notion of code being executed in a sandbox as it is the case with java applets in a browser. I could have, very easily: make a good security.policy file. The sandbox for applets is nothing more than starting a jvm with a strict policty file. > The biggest security hole in jBPM is indeed that it circumvents the JBoss deployer arcitecture. Here I disagree. The deployer does not do anything to prevent deploying malicious code. Does it contain a 'virus scanner' or whatever ;-) I know the way of deployment is one of your 'pet topics' and I agree it would be nice to have a 'real' deployer as an addition to what is already there. Keep in mind though that there are more environments where jBPM is used than JBoss AS. So we cannot just introduce the MBean deployer and ditch the rest. > On top of this general issue, we can think of additional security measures that work on the level of specific jbpm functionality. Even better, on top of any functionality
>> any other java code that can be executed as part of jbpm? For the sake of argument, how is this different to System.exit(0) called from a Servlet that can be >>deployed to JBoss? >Security.policy files can be in place to prevent classes other than the ones in e.g. the org.jboss domain to execute a System.exit(0), so indeed it is a more >generic issue. Afaik, Oracale/Bea WLS uses this to prevent exactely this >> A deployment that makes it into JBoss must inherently be trusted because JBoss does not have the notion of code being executed in a sandbox as it is the >>case with java applets in a browser. >I could have, very easily: make a good security.policy file. The sandbox for applets is nothing more than starting a jvm with a strict policty file. A quick fix can be sth like what has been done in ESB, i.e., having a property called "supportMessageBasedScripting" in jBPM process configuration file. Turning this flag on means the owner of this piece of code is fully aware of what his/her process will be doing and security related implications. By default this flag is turned off. Please refer to https://jira.jboss.org/jira/browse/JBESB-1561 But I agree that a long term proper fix would have to have SecurityManager involved.
A SecurityManager would not fix the issue, because it cannot distinguish between processes that should be allowed certain API calls and processes that should not be allowed to call certain API. Not only System.exit(0) is a problem here, but also malicious file access on the server box for example. It should be obvious, that once a malicious deployment makes it into the server it cannot be prevented to do it's dirty work. Therefore, deployment of the process must be secured in the first place. Deployment security is a property of the jboss deployer architecture and not the jBPM system. That jBPM shortcuts the JBoss MainDeployer by using a naive servlet based deployment approach is probably the real issue. This has been known since 15-Jun-2007 [GPD-155]
Link: Added: This issue is related to JBPM-1958
Tom, could you please reassign appropriately.
To fix the security issue, the servlet should be disabled. I believe this was already done. no ?
Disabled the upload servlet in the webapp descriptor of the console SOA overlay.
ESB use the upload servlet, org.jbpm.web.ProcessUploadServlet, to deploy process definitions. Disabling this breaks our examples.
This issue and its counterpart SOA-1065 are about sandboxing the jBPM scripts and action handlers. Securing process deployment was already done by moving the upload servlet into the webapp secure area. I have reenabled the ProcessUploadServlet in the console SOA overlay and moved it back to the secure area.
iirc from the meeting and email thread, 1) this issue is different from what we originally understood. it's not so much the open http servlet upload. but instead the ability to have a security manager control all code that is executed, including the scripts that are in the jpdl sources processes. 2) this is a global jboss / soa platform issue that should be dealt with in many projects and needs a central solution to be rolled out. we're waiting to learn what solution that is, what we should provide and how we can test it.