GraniteDS 2.2.1 GA is a bug and security fixes release with one major new feature: Gravity is now natively supported with WebLogic 9.1+ servers.
The security fix relies on a new configuration option and prevents arbitrary Java class instantiations through malicious AMF3 requests.
Preventing Abitrary Java Class Instantiation
AMF3 deserialization, on Java-side, triggers the instantiation of classes that are referenced in the binary-coded request coming from the client. Thus, a malicious AMF3 request can be created in order to instantiate an abitrary Java class (and the execution of its constructor instructions) that has nothing to do with the expected data exchanged between a Flex application and a GraniteDS server.
This potential exploit has been reported to Adobe and us by , and can affect any Flex/Java server (LCDS, BlazeDS and GraniteDS). It may affect as well other servers relying on a comparable serialization protocol.
GraniteDS’ fix for this security issue relies on a new configurable option that you can put in your granite-config.xml file. If you don’t configure anything with the new 2.2.1.GA release, each GraniteDS application will issue a warning such as the following one:
WARN [GraniteConfig] You should configure a deserializer securizer in your granite-config.xml file in order to prevent potential security exploits!
In order to secure your application (and you are strongly encouraged to do so) you must configure a securizer as follow (taking the graniteds_ejb3 sample application that comes with the distribution as an example):
<!DOCTYPE granite-config PUBLIC "-//Granite Data Services//DTD granite-config internal//EN" "http://www.graniteds.org/public/dtd/2.2.1/granite-config.dtd"> <granite-config scan="true"> <amf3-deserializer-securizer param=" org.granite..* | flex.messaging..* | test.granite.ejb3.entity..* "/> <security type="org.granite.messaging.service.security.TomcatSecurityService"/> </granite-config>
By default, the securizer uses the org.granite.messaging.amf.io.RegexAMF3DeserializerSecurizer class that, as its name stands, uses a regular expression parameter. The highlighted lines above show an example of such expression. They mean: allow only instantiation of classes whose package name starts with “org.granite.�?, “flex.messsaging.�? or “test.granite.ejb3.entity.�?. Of course, all standard Java types are allowed by default and you don’t have to explicitely add their package names.
If this default regex-based implementation doesn’t fit your needs, you may write your own securizer. It only has to implement the org.granite.messaging.amf.io.AMF3DeserializerSecurizer interface and you can plugged in with this kind of declaration:
The new DTD is on-line here:
Configuring Gravity for WebLogic 9.1+ Servers
Configuring Gravity for WebLogic servers is just a matter of using the right servlet in your web.xml file:
<servlet> <servlet-name>GravityServlet</servlet-name> <servlet-class>org.granite.gravity.weblogic.GravityWebLogicServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>GravityServlet</servlet-name> <url-pattern>/gravity/*</url-pattern> </servlet-mapping>
That’s it, you should then be able to use Gravity consumers / producers in your Flex application with an asynchronous and thus scalable servlet implementation running into your WebLogic server.
Change Log and Download Links
The full changelog is available .
Downloads are available .