Pete Freitag Pete Freitag

Disable Flash Remoting on ColdFusion Servers

Published on September 03, 2015
By Pete Freitag
coldfusion

Due to the recent security vulnerability ABSP15-20 / APSB15-21 in BlazeDS there has been increased interest in disabling flash remoting when not needed -- if you followed the lockdown guide for CF9, CF10, or CF11 you should already have it disabled.

This only applies to ColdFusion 10 and ColdFusion 11 right? Nope!

Your ColdFusion 7-9 servers may also be vulnerable to this issue but since they are considered EOL or End Of Life, they are no longer supported or patched by Adobe so there is no hotfix to apply.

If you do need flash remoting on these servers you can manually update the flex-messaging-core.jar file in your lib directory. I tested this on a CF 9.0.2 server tested that it worked by using the ColdFusion Server Monitor.

David Epler has posted some instructions for manually patching a CF9 server on his blog.

How can I disable Flash Remoting on ColdFusion Servers

There are a few ways this can be accomplished, I recommending doing each way to provide layers of assurance or defense in depth.

Uncheck: Enable Flash Remoting in ColdFusion Administrator - this is the easiest way to go, but I don't trust this method to fully disable anything that might be vulnerable to a security issue.

Block URIs on your web server web server blocks are always my favorite approach because they are blocked before hitting the CF server at all, they are the most efficient way to protect resources in most cases.

If you are using IIS 7+ you can block (if you are using IIS6 or lower you are running an EOL operating system with many other security issues to consider, time to upgrade!) using Request Filtering. It can run on a per site basis or on a global basis - for security rules like this it makes sense to run them on a global basis. Click on the URL tab and then Deny Url Sequence to add the following URIs to block, test them out in your browser to make sure you get a 404:

/flex2gateway
/flashservices
/flex-internal
/CFFormGateway
/cfform-internal

To block them on Apache you could do something like this globally in httpd.conf:

RedirectMatch 404 (?i).*/flex2gateway.*
RedirectMatch 404 (?i).*/flashservices.*
RedirectMatch 404 (?i).*/flex-internal.*
RedirectMatch 404 (?i).*/cfformgateway.*
RedirectMatch 404 (?i).*/cfform-internal.*

Using nginx you can do something like this (thanks Joseph Lamoree) :

location ~* ^/(flex2gateway|flashservices|flex-internal|CFFormGateway|cfform-internal|messagebroker) {
    return 403;
}

Keep in mind that when blocking only on the web server Flash Remoting is still enabled so you could still use the server monitor over the Internal Web Server, or if you have it running on its own port.

Disable by Removing Servlet Mappings

Removing Servlet Mappings removes the URL pattern to Servlet (the java code that executes requests) definition at the JEE servlet container level. It is done by editing the web.xml file found in the WEB-INF folder. You can either delete the <servlet-mapping> ... </servlet-mapping> tag or comment it out with an <-- XML comment --> (only uses two dashes).

Here's an example of a servlet mapping on CF9:

<servlet-mapping id="coldfusion_mapping_0">
  <servlet-name>MessageBrokerServlet</servlet-name>
  <url-pattern>/flex2gateway/*</url-pattern>
</servlet-mapping>

You can also disable the servlet mappings that have the following URL patterns:

/flashservices/gateway/*
/flex-internal/*
/CFFormGateway/*
/cfform-internal/*

You can also remove the Servlets that correspond to these servlet-mapping but I have seen cases where CF would not start due to removing a servlet that is expected to be there. Removing unnecessary servlets can improve your CF server startup time and potentially reduce resource utilization, so it may be worth experimenting with for you.

What if I am running Railo / Lucee

There is a good chance your server could also be vulnerable to this issue, because many installers included BlaseDS and servlet mappings. To disable it you will want to edit your web.xml file and remove a servlet mapping like this:

<servlet-mapping>
  <servlet-name>MessageBrokerServlet</servlet-name>
  <url-pattern>/flex2gateway/*</url-pattern>
  <url-pattern>/flashservices/gateway/*</url-pattern>
  <url-pattern>/messagebroker/*</url-pattern>
</servlet-mapping>

I would also recommend adding the blocks on your web server config (as shown above) as an extra layer of protection incase you reinstall and put BlazeDS back in.

Possible issues with Flash Remoting after installing ColdFusion 11 Update 6 or ColdFusion 10 Update 17

I have seen one report of issues caused by this new update of BlazeDS, it was throwing a: java.lang.NoClassDefFoundError: javax/jms/InvalidSelectorException which may be due to missing ActiveMQ jar files.



coldfusion flex servlet blazeds railo lucee

Disable Flash Remoting on ColdFusion Servers was first published on September 03, 2015.

If you like reading about coldfusion, flex, servlet, blazeds, railo, or lucee then you might also like:

Fixinator

The Fixinator Code Security Scanner for ColdFusion & CFML is an easy to use security tool that every CF developer can use. It can also easily integrate into CI for automatic scanning on every commit.


Try Fixinator

CFBreak
The weekly newsletter for the CFML Community


Comments

Here's a chunk of NGINX configuration that would disallow these sorts of requests, preventing any attempt to upstream the request to a CFML engine:

location ~* ^/(flex2gateway|flashservices|flex-internal|CFFormGateway|cfform-internal|messagebroker) {
return 403;
}
by Joseph Lamoree on 09/03/2015 at 6:31:57 PM UTC
@joseph - thanks I added that to the blog entry.
by Pete Freitag on 09/03/2015 at 6:35:16 PM UTC
I've posted an IIS Rewrite rule to allow local access while blocking remote attempts. This would allow internal monitoring to still work.
https://gist.github.com/JamoCA/4bb554360de0b0847927
by James Moberg on 09/03/2015 at 11:13:07 PM UTC