The Ejbd Transport allows to remotely access EJBs that have a remote interface. Nevertheless it is not based on IIOP.
Ejbd Transport is different using TomEE or OpenEJB.
In OpenEJB it uses openejb http layer and ejbd is configured through ejbd service (same for ejbds). So to activate/deactivate them use conf/ejbd(s).properties files. You can set property disabled to true if you don't want them to be started.
In TomEE the transport is the Tomcat one. It uses a servlet brought by TomEE webapp. Here is the servlet as defined in TomEE webapp:
<servlet> <servlet-name>ServerServlet</servlet-name> <servlet-class>org.apache.openejb.server.httpd.ServerServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>ServerServlet</servlet-name> <url-pattern>/ejb/*</url-pattern> </servlet-mapping>
You can easily remove it if you don't use remote EJBs. Another way is to deactivate the servlet using the "activated" init parameter of the servlet.
Finally you can move this servlet in your own webapp if you want to use a provider url containing your webapp context. Simply copy paste the servlet definition in your web.xml and set the url mapping to what you want (let say /foo/*). Then use the provider url http://<host>:<port>/<webapp context name>/foo
Remotely calling EJBs, independent of using Ejbd or other RMI/IIOP based protocols, involves serialization and deserialization of objects.
Deserializing unknown content coming from an untrusted source imposes a security risk as the stream could be manipulated.
A much publicized vulnerability was found in the commons-collections library which allowed to remotely execute arbitrary code simply by deserializing instances of the class
To prevent this risk TomEE and the OpenEJB client since 1.7.4 before deserializing every object checks its class against a configurable blacklist and a whitelist.
The default black list is defined as
*, meaning that requests cannot be deserialized at all and the Ejbd transport in fact cannot be used.
The blacklist and whitelist is configured via the system properties:
You will also find these properties in System Properties Listing
These rules apply for the whitelist:
These rules apply for the blacklist:
-. This will open your system to the serialization vulnerability if you don't configure a whitelist!
org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan,java.lang.Processso that for example the class
org.apache.commons.collections.functors.InvokerTransformercannot be deserialized.
*, therefore preventing any Ejbd communication.
The default for
tomee.serialization.class.whitelist is empty, the default for
* since TomEE 1.7.4.
If an EJB request fails because a class is not whitelisted you will find this log entry:
WARN - "null OEJP/4.7" FAIL "Security error - foo.Bar is not whitelisted as deserializable, prevented before loading it." - Debug for StackTrace
If you trust this class and want to support serialization in remote communication you have to configure these properties appropriately both on server side as well as on client side.
If you only want to support serialization of the classes
foo.Baz you can configure the properties like this:
tomee.serialization.class.whitelist = foo.Bar,foo.Baz tomee.serialization.class.blacklist = -
If you trust all classes in the package
foo define the properties like this:
tomee.serialization.class.whitelist = foo. tomee.serialization.class.blacklist = -
(Don't forget the trailing
. after foo, as it will also whitelist all classes in the package
If you trust all classes in the package
foo except the class
foo.Bar you have to configure the properties like this:
tomee.serialization.class.whitelist = foo. tomee.serialization.class.blacklist = foo.Bar
TomEE 1.7.3 already contained a fixed blacklist that was not configurable and contained the packages org.codehaus.groovy.runtime, org.apache.commons.collections.functors and org.apache.xalan including subpackages and the class java.lang.Process. If you know that your applications runs on TomEE 1.7.3 but does not on TomEE 1.7.4 showing the aforementioned log message, you can define the configuration so that the serialization will work in the same way as it did with TomEE 1.7.3:
tomee.serialization.class.whitelist = tomee.serialization.class.blacklist = org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan,java.lang.Process
Please note that with this configuration your server may be vulnerable to Java serialization attacks not yet identified by the Zero Day initiative. Also note that the following versions of the affected libraries have been patched and approved by the Zero Day initiative and may be safe to deserialize.
As Ejbd transport is tunneled over HTTP please make sure that the
ServerServlet is not publicly accessible.
When the applications running on TomEE do not package the
ServerServlet themselves ensure that the URL http://<host>:<port>/tomee/ejb is not accessible from untrusted sources.
If your applications package declare it in their own web.xml make sure that the respective URL is not accessible from untrusted sources.
TomEE 1.7.2 did not have any kind of blacklist when deserializing objects over Ejbd. If you want to revert to this behavior you can simply deactivate the blacklist with this configuration:
tomee.serialization.class.whitelist = tomee.serialization.class.blacklist = -
Note that this configuration makes your system highly vulnerable to serialization attacks! Consider your system as unsafe!
The mechanism described above principally also works when running Arquillian tests. As the Ejbd transport is already used for deploying applications all Arquillian tests would fail with the default settings.
Therefore the TomEE Arquillian adapter automatically starts the container so that all classes except for a set of well-know dangerous classes are whitelisted.
As Ejbd is by default disabled since TomEE 7.0.0, the TomEE Arquillian adapter automatically activates it when starting a remote container.
The same mentioned above on Arquillian and TomEE is also valid when using the TomEE Maven Plugin.
All edits are reviewed before going live, so feel free to do much more than fix typos or links. If you see a page that could benefit from an entire rewrite, we'd be thrilled to review it. Don't be surprised if we like it so much we ask you for help with other pages :)NOTICE: unless indicated otherwise on the pages in question, all editable content available from apache.org is presumed to be licensed under the Apache License (AL) version 2.0 and hence all submissions to apache.org treated as formal Contributions under the license terms.