David C. Epler

So there has been yet another 0-day found that can exploit ColdFusion by not having directories within CFIDE properly secured as noted in APSA13-03 from Adobe. If you haven't properly secured CFIDE that is public facing, it is only a matter of time until it gets hacked. The previous two that were found in January and April of this year should have been motivation enough.

For those that are still running ColdFusion 8, my best advice to secure your ColdFusion install is to use the ColdFusion 9 Lockdown Guide. I have used it to secure ColdFusion 8 for several different clients. The only section in the lockdown guide that doesn't apply to ColdFusion 8 is "Removing WSRP servlet mapping" since it was introduced in ColdFusion 9.

If you are attending cf.Objective() this year, there are several more security related talks. I am talking on Web Hacking Tools on Thursday (1st day) at 2:35pm. Among the demonstrations will be how ridiculously easy it is to get access to ColdFusion Administrator if you have it accessible and not recently patched. I also highly recommend seeing both of Pete Freitag's sessions, Writing Secure CFML and Locking Down CF Servers.

Lastly, Adobe has announced a security patch to resolve APSA13-03 will be released on May 14th. Unofficial Updater 2 should be updated on May 15th while I'm heading to cf.Objective(). 

 

Unofficial Updater 2 has been updated (April 11th) to now apply the latest ColdFusion security hotfix APSB13-10 that was released on April 9th.

Stay on top of the patching since on April 10th a Metasploit exploit was released that exploits the previous security hotfix APSB13-03. It is only a matter of time until there is an exploit that goes after the latest security hotfix or the next unknown one.

The best defense is to stay current on patches and properly secure ColdFusion using the published lockdown guides for ColdFusion 9 or ColdFusion 10, otherwise.

 

So last week the ColdFusion product team announced a survey to get selected into the pre-release program for the next version of ColdFusion (refuse to call it by the code name since all I think of is Splenda). A lot of this has been rolling around in my head since they published the roadmap last August and really need to get this out before there is a possibility of being included in the pre-release and the requisite NDA. 

Security

ColdFusion 10 did focus on security and by far was the most significant release to address the issue. It is listed on the roadmap, but can still be improved.

Installation

One of the areas that would improve the security of ColdFusion would be to make several changes to the installer.

First, Secure Profile should be an opt-out with a checkbox "Disable Secure Profile". In the ColdFusion 10 installer it is an opt-in with "Enable Secure Profile". There are too many administrators that just click through the installer. By explictly making them opt-out of Secure Profile, it would make them think about the implications of not selecting it and most would probably leave it as is. No one wants a less secure install.

Second, the installer on Windows should allow one to change the default user that ColdFusion runs as just like the installer for Linux has done for ages. Those that attack ColdFusion specifically look for Windows installs since the majority of installs are left running as SYSTEM.

Lastly, while the lockdown guide is well done and extremely useful, it should be published as soon as the version is released (May 14, 2012), not 6 months afterwards (November 28, 2012). The lockdown guide should also be prominently displayed on the ColdFusion download page and within the ColdFusion Administrator.

Sandboxing

Sandboxing within ColdFusion is probably one of the more under utilized security features the product has had for the longest time. Part of that is due to the fact it requires an Enterprise license to create multiple sandboxes. This is one area where the distinction between Standard and Enterprise should be dropped. Security should never be a for pay feature.

There are several enhancements to sandboxing that should be done as well. The CFIDE sandbox does not apply to scheduled tasks or system probes and it should. If they aren't part of CFIDE sandbox, they should have their own sandbox defined for themselves. All sandboxes should be pre-defined to only allow for access to 127.0.0.1 port 80 so the administrator has to explicity open access to external systems, as opposed to allowing all connections which is the current default. Another minor issue is that it only allows for IP addresses and should allow for fully qualified domain names. Finally, sandboxing should be enabled by default when Secure Profile is enabled.

PDFs

The ability to create PDFs was one of the best additions to ColdFusion back in version 7. Unfortunately though the functionality has seemed to stagnate. This is the one area that ColdFusion can really set itself apart and excel at; better rendering of HTML to PDF for Section 508 support as noted in bug id 3041212, more integration with PDF forms like noted in bug id 3117809, and handling signatures. The dependence ColdFusion has on iText, jPedal, and OpenOffice should be removed. It was understandable back in ColdFusion 7 and 8 when it was developed by Macromedia. PDF is an Adobe technology, as is ColdFusion; this should be do-able. Hopefully this will happen since the roadmap says, "Revamped and new PDF functionalities".

Integration

The strength of ColdFusion has always been its ability to integrate with various back-end technologies like Java, .Net, Exchange, SharePoint, and Office documents. One of the main problems has always been things are never fully baked or key functionality is missing. A prime example is the lack of NTLM and Digest support on HTTP calls. It has been a long requested feature originally logged as bug id 72751 and migrated as bug id 3035879. It is currently marked as Deferred/Not Enough Time from ColdFusion 9.0 Alpha 1 (probably has been asked for longer, but can't find references). There is another bug id 3175165 which is strictly NTLM support and is set as To Fix from ColdFusion 9.0.1, but nothing on Digest. One could argue that this should have been addressed by now so ColdFusion can stay ahead of requirements coming from clients (seriously look at bug id 3175165, the developer is pleading for it so that ColdFusion can stay relevant at a large US Government agency).

Reporting

Reporting is one area where integration is lacking. It is time to face the fact that ColdFusion Reports and ColdFusion Report Builder are defunct; no real update has occurred since version 8. Just kill it off. Integrating with a modern version of Crystal Reports for all platforms (not just Windows) and allowing for easy integration with Jasper Reports or BIRT should be the focus to solve the lack of good reporting solutions in ColdFusion.

Social Media

The one area of the roadmap that is of concern is "Enabling Enterprise to easily integrate with Social Media Streams". It is extremely buzzword compliant. Hope this does not mean <cftwitter>, <cffacebook>, or <cfsocialmedia> tags or functions. While these sound good in concept, just look at the issues with <cfmap> and the changing of Google Maps API from v2 to v3. There are projects on riaforge.org like (monkeh)Tweet Twitter API that can provide the same integration and faster turnaround to API changes. 

Getting a feed from Twitter is easy; integrating NTLM and Digest authenication is hard. Get back to making hard things easy.

Deployment

This is an area where ColdFusion has been severely lacking. While there are ColdFusion Archives (CAR) and J2EE Archives (WAR/EAR) in Enterprise, neither for these solutions easily integrates with a build environment. Both require interaction with the ColdFusion Administrator. There needs to be an easy way to script deployments, probably with Ant since pretty much every build environment can interact with it. The other issue with the existing J2EE Archives is that the resulting output is ridiculously large to support even the most basic ColdFusion Application. There needs to be a way to select only needed functionality into the WAR/EAR. If the ColdFusion Application isn't using Flex or <cfform> stuff, should be able to pull it out of the deployment.

Vote Up Existing Bugs, Suggest Enhancements

So even if you don't get into the pre-release for ColdFusion 11, what can you do? The best thing would be to go through the existing bugs to see if any issues you have are currently reported and vote it up. While the Adobe Bugbase is a pain to search, try the simple interface that Adam Cameron created. If you have an enhancement, submit it to the Adobe Bugbase and then get people to vote it up. Follow @cfbugnotifer on Twitter. See something on the Twitter feed, vote it up, retweet, get involved in the future of ColdFusion.

So if you have been following things, Adobe released cumulative hotfixes to allow for Java 7 support and to update <cfmap> to use Google Maps API v3 instead of v2. Only problem is along the way they have had to update them a few times. It is exactly this situation which drove me to create Unofficial Updater 2 originally. 

Frankly, the entire past 2 weeks should not have occurred. This really shines a light on how poorly thought out the Adobe ColdFusion update product teams's release process is. And this is not the first time they have had to do multiple re-releases of hot fixes. APSB11-04 once, APSB11-14 twice, APSB12-06 once for CF801 only and pulled Update 3 for CF10. That track record does not inspire confidence.

As for some general notes regarding the CHFs. They provide Java 7 support for ColdFusion 9.0.x for all OSes EXCEPT for Mac OS X 10.7 and 10.8. Java 7 is supported on all OSes for ColdFusion 10.0.8+. The update to support Google Maps API v3 should never have happened; <cfmap> should be depricated in accorance to what I'll call the "Forta Rule" and can only hope this happens for ColdFusion 11.

Update Process for UU2

Given that I found multiple issues that prompted the re-releases and updates to the technotes, I wanted to share how I go about updating Unofficial Updater 2.

The process starts with complete reading of the technote(s) to see what has changed and what exactly the steps are. From that the hotfix matrices (9.0.0, 9.0.1, 9.0.2) are updated as part of the project to note items such as download files, CVEs fixed, and what needs to be installed or is superseded. This is how the missing 81860 for CF 9.0.0 CHF2 was found. Then uu2.properties is updated to add the download location and hashes for the files. It was the changing of the hashes which prompted me to inquire about the "silent" update of the CHFs that occurred between February 27th and March 1st. Finally build.xml is updated to reflect the steps in the technote to apply the files.

After the update to build.xml, UU2 is then tested against both Windows (2008 R2) and Linux (CentOS 5.8). So there are VMs for each OS that have installs of ColdFusion 9.0.0, 9.0.1, and 9.0.2 installed as both standalone and as JRun multi-server. In each instance there is a clean install maintained, an install with the previous hotfix applied, and an install with the new hotfix applied so comparisions can be done. UU2 is tested against a clean install and the previous hotfix install. This is how the missing jpedal.jar was found in CF 9.0.1 CHF4. UU2 isn't tested as rigorously against Mac OS X since I don't know of any one running it in production with OS X Server. No testing is done against Solaris since I don't have access to a Sun Server, but the Linux testing should cover it. 

Then all the associated documentation for UU2 is updated and packaged for release. Generally want to get UU2 out as soon as possible but if there are issues reported, it will be delayed until they are resolved. UU2 only goes out once everything for a given set of updates from Adobe have been resolved.

So with all of that, Unofficial Updater 2 was updated last night (March 11, 2013 at 8:00PM EDT) to support applying the various ColdFusion 9.0.x CHFs (issue 33). It also changed the behavior of the default directory for backing up (issue 31). On Windows it will default to the current running directory of UU2 and on Unix will default to /tmp. 

Again, thank you all that use and provide feedback to make Unofficial Updater 2 better. Also thank you to CFHour for the mentions (finally made Boyzoid a convert!)

 

So like quite a few others, I have been working with Groovy and Grails much more. I'm not going to go into how much better or more joyful it is to work with than CFML but to take ideas from it and lobby to get them implemented in Adobe ColdFusion and Railo.

The ESAPI encoders are now baked into the language for both Adobe ColdFusion 10 and Railo 4 and can help prevent XSS by using the proper encoder depending upon output context, EncodeForHTML(string) [ACF, Railo] or ESAPIEncode("HTML", string) [Railo] in most cases. It is possible to get the same functionality in older versions using ESAPI4CF or CFBackPort. But the problem is to fully protect against XSS you need to go through all the code in an application that renders output and modify it to use the proper encoder.

Now where Grails makes this easy is that they offer a way to set a default encoder on an application level through Config.groovy [kind of like Application.cfc]

grails.views.default.codec = "html" 

Instead of having to write ${params.firstName.EncodeAsHTML()} [for ACF this would be like #EncodeForHTML(form.firstName)#], Grails just does the EncodeAsHTML automatically on ${params.firstName}; no need to add .EncodeAsHTML(), so no code change.

In Grails there is also the ability to toggle the behavior on a per-page basis with <%@page defaultCodec="html" %> [for CFML probably <cfprocessingdirective>, maybe <cfsetting> never really got the difference other than the attributes]

As you can see writing better XSS defended applications in Grails is a bit easier (um, making hard things easy?). It is possible to get the same functionality into CFML but there needs to be several additions to the language:

1. EncodeFor attribute for <cfoutput>, <cfprocessingdirective>, and writeOutput()

• The default value for EncodeFor would be "none" to allow for backwards compatability unless set in Application.cfc (or possibly server/context level in the Administrator)
  • Personally think it should be "HTML" but would probably break way too much code, maybe for Secure Profile

• All the ESAPI encoders would be valid values for EncodeFor
  • HTML, HTMLAttribute, CSS, Javascript, URL, XML, XMLAttribute, XPath, LDAP, DN, VBScript, and None

2. New this.defaultEncodeFor variable in Application.cfc

• Following the outline for the addition to the tags/function for default and values listed above

3. If there is an EncodeFor* inside a block, the closest EncodeFor* takes precedence

<cfouput encodeFor="HTML">
#url.name#
<a href="whatever.cfm?id=#EncodeForURL(url.id)#">Link</a>
</cfoutput>

In the example above everything would be EncodeForHTML except for what was directly inside the EncodeForURL(). 

A little over a month ago I did submit it to Adobe as a Enhancement Request #3434473, but like others have found it seems to be a "blackhole". It is a bit surprising that there has been nothing noted on it by Adobe even though I clasified the request as Security for the product area and they claim to put a priority on security. If you think this would be a good enhancement, please go vote it up.