| Summary: | JBPM events can execute arbitrary code | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 4 | Reporter: | Marc Schoenefeld <mschoene> | ||||
| Component: | Documentation, JBPM - within SOA, Security | Assignee: | Mike Brock <cbrock> | ||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | urgent | ||||||
| Version: | 4.2 Beta 1 | CC: | mschoene, rruss | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 4.2 CR2 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| URL: | http://jira.jboss.org/jira/browse/SOA-265 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: |
[mschoene@mschoene bin]$ java -jar run.jar
16:06:30,423 INFO [Server] Starting JBoss (MX MicroKernel)...
16:06:30,424 INFO [Server] Release ID: JBoss [EAP] 4.3.0.GA (build: SVNTag=JBPAPP_4_3_0_GA date=200712141443)
16:06:30,426 INFO [Server] Home Dir: /NotBackedUp/software/soabeta1/jboss-soa-p.4.2.0/jboss-as
16:06:30,426 INFO [Server] Home URL: file:/NotBackedUp/software/soabeta1/jboss-soa-p.4.2.0/jboss-as/
16:06:30,427 INFO [Server] Patch URL: null
16:06:30,427 INFO [Server] Server Name: production
16:06:30,428 INFO [Server] Server Home Dir: /NotBackedUp/software/soabeta1/jboss-soa-p.4.2.0/jboss-as/server/production
16:06:30,428 INFO [Server] Server Home URL: file:/NotBackedUp/software/soabeta1/jboss-soa-p.4.2.0/jboss-as/server/production/
16:06:30,452 INFO [Server] Server Log Dir: /NotBackedUp/software/soabeta1/jboss-soa-p.4.2.0/jboss-as/server/production/log
16:06:30,452 INFO [Server] Server Temp Dir: /NotBackedUp/software/soabeta1/jboss-soa-p.4.2.0/jboss-as/server/production/tmp
16:06:30,452 INFO [Server] Root Deployment Filename: jboss-service.xml
16:06:30,791 INFO [ServerInfo] Java version: 1.5.0_13,Sun Microsystems Inc.
16:06:30,791 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_13-b05,Sun Microsystems Inc.
16:06:30,791 INFO [ServerInfo] OS-System: Linux 2.6.18-8.1.8.el5,i386
16:06:31,258 INFO [Server] Core system initialized
16:06:34,471 INFO [WebService] Using RMI server codebase: http://127.0.0.1:8083/
16:06:34,473 INFO [Log4jService$URLWatchTimerTask] Configuring from URL: resource:jboss-log4j.xml
[...]
Shutdown complete
Halting VM
|
|||||
| Last Closed: | 2008-02-04 16:29:26 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 777801, 777988 | ||||||
| Attachments: |
|
||||||
|
Description
Marc Schoenefeld
2008-01-03 15:25:33 UTC
Attachment: Added: atimerbox.zip Link: Added: This issue is related to SOA-262 in the web.xml, the availability of the servlet and the security authrorizations can be configured. i don't think a security domain is the right solution. restricting access so that unauthorized people can't deploy processes is the right solution. "Restricting access is good first step, but we still leave an open functionality and security risk" jBPM is not designed to run in a hostile environment. If you would like to make it secure you would have to start with a full audit. I'm pretty sure it will be practically impossible to find and fix all security holes. Any solution to fix the security wholes will also have an impact on all the users that don't want to run jbpm in a hostile environment. Also, we have put great care into building suite package that gives an easy out-of-the-box experience by integrating the runtime, designer and console. It's done in such a way that most of our users get going with it asap. If people have to find how to unlock things before they can start working with it, that would introduce another barrier that holds back adoption of our product. A bit of documentation to explain that the jbpm servlet is a potential security risk and how to disable it might be appropriate. Marc is correct. Plus "If you would like to make it secure you would have to start with a full audit. I'm pretty sure it will be practically impossible to find and fix all security holes." is not a strong argument against fixing this issue particular. Change the words "secure" to "reliable" and "security holes" to "bugs" and you have a statement whereby we should never look for and fix bugs either. Of course there may be other security issues that this won't catch, but it's a start. It would appear that there are two mutually compatible ways to address this issue: sandbox jBPM via an appropriate classloader and documentation. The latter is straightforward and relatively simply to do. I need to know how long it will take you (Tom) to do the former, assuming we go down that route? Link: Added: This issue related SOA-262 Link: Removed: This issue related SOA-262 Link: Added: This issue is related to SOA-270 i don't know what is meant with sandboxing. that approach is not getting included in the project itself. you'll have to do it as part of the platform integration code if you want it. it's not going to be easy. count on 2 - 4 weeks of work without the jbpm learning curve. if this gets committed in the platform branch, it is too far from the project branch and I will not be able to support a solution like that. i know what it is and i know how to do it. my response was that i don't want that kind of things in the project itself. so they can be done in the platform integration code of jbpm. but that would have big implications as i mentioned. ps. just a suggestion: i think it would be more polite to our community if you commented in public by default. We will create two jBPM wars: one for production where the web.xml is modified to prevent such security issues and closing down the access, and one for development use, which would allow the jBPM development tool to continue to operate. We will need to document this as well. Link: Added: This issue is a dependency of SOA-327 Affects: Added: [Documentation (Ref Guide, User Guide, etc.)] Link: Added: This issue related SOA-313 Fixed. Awaiting documentation update to close issue. Information from Mike Brock: Two war files are shipped with the platform: In the standalone version, we ship with the unsecured uploader console by default. ie. the jBPM JPDL will be able to deploy processes, unless it's secured by copying the file in: /tools/resources/jbpm-console-production.war to /server/default/deploy/jbpm.esb/jbpm-console.war. They can change it back by copying: /tools/resources/jbpm-console-development.war to /server/default/deploy/jbpm.esb/jbpm-console.war. The file must be overwritten. You can not have two versions of the war in the deployment directory. In the EAP version, by default, the all profile has the development version of the WAR, and the production profile has the production version. My favorite choice for the standalone version would be "securing it by default, and opening it (make it vulnerable) by intent". With the current setup, which is the opposite, admins are likely to forget/oversee that they have to close the jpbm hole after deploying the processes, especially if they don't use jbpm at all, which means that the upload stays open unnoticed because admins are not aware of this feature. Link: Added: This issue is a dependency of SOA-515 |