There has been a lot of noise over the past week about the ColdFusion Directory Traversal Vulnerability. 
If you haven't heard, the basic issue is that ColdFusion allows the inclusion of just about any file on the server (usually Windows servers) to be included by using either a URL parameter or form parameter.  Without special encoding the vulnerability will let you grab any file ending in .xml, but by adding a %00 to the parameter, just about any file gets included in the normal display of the ColdFusion Administrator login page.  This means that no authentication is required to pull this off.  The flaw is in the internationalization tags being used by the Administrator pages which include XML files to render the text for different languages in the CFAdmin section.  In turn the XML files aren't really XML files, but instead are files containing large switch/case statements which, according to the arguments, spit out the value for the piece of text the XML file is called with.  The flaw is that the code calling the file uses user input to decide which file to grab, but doesn't properly sanitize the request, allowing the inclusion of other files from the same disk the CFAdmin section is living on.  As Adrian Pastor points out, CF runs under the SYSTEM account by default, which means access to any file on the drive.  Including the CF configuration files which may include things like database connection settings (with passwords saved which can be decrypted easily).  Adrian also points out that once an attacker gains access to the CF Admin, it’s game over.

The patches provided by Adobe for the problem are quite simple, and in most cases shouldn't even require a restart of the ColdFusion services.  The impact of the vulnerability is huge.  As Rafal Los, who rightfully calls this a "Disaster", points out, there are a lot of ColdFusion servers with the Administrator pages available to the world.

Even worse, the vulnerability can be exploited on versions 6-9 (CFMX6, CFMX7, CF8, CF9), but Adobe is only releasing patches for versions 8 and 9.

As we have been working with  and hosting ColdFusion since version 5,  we understand how most CF developers work, and how poorly the servers are administered in most installations.  In his post, Rafal Los offers some Google dorks for finding CF servers, and states that "There is really no legitimate reason to have a ColdFusion Admin interface on the public internet" really, I can't think of one, yet there are many results!.  So why are there so many results?

It is a combination of factors, laziness I'm sure being close to the top of the  list, but there are others.  The primary reason that comes to my mind is the location of the ColdFusion Administrator directory, inside of the '/CFIDE/' directory.  This directory has other directories inside of it which are used by CF for things like form validation, Ajax, rendering of graphs, etc. and as such some applications stop working if the CFIDE directory does not exist, so it must be mapped as a virtual directory in most cf websites. 
Often it is the webmaster or developer  who is setting up and managing the ColdFusion server and who usually has very little knowledge of server security and limited knowledge of the ColdFusion Administrator and its associated security issues or the CFIDE requirements in an application, even if a real server admin is involved his knowledge of ColdFusion will be little to none.

Thankfully Adobe has finally released a Lockdown Guide written by Pete Freitag which is well done, and I hope is somewhat due to all the advice and feedback I have given Adobe over the years in this dept.  I just hope people read and follow it.

Another problem is those older versions for which no patch is forthcoming.  CF developers are very wary of changing the version of CF their application currently works on.  Much of this comes from a botched move by Macromedia a long time ago, when their first version of ColdFusion MX 6 (6.0.0) became notorious for breaking apps and eating resources.  This means that there are now a lot of old applications which are on old versions of CF.

If you run a CF server then you should install the patches and lock down access to your ColdFusion Administrator.
If you have a CFIDE vDir mapped to your sites, DO NOT use the original folder, take a copy of the CFIDE, put it somewhere else and delete the ADMINISTRATOR and ADMINAPI folders, now use this copy for your virtual directories. I have various old CF security and lockdown articles on this blog which you may want to take a look at.

I just did a Railo/Tomcat install on an IIS7 server and thought the whole thing was hosed as I could only get a 500 internal server error. As I was using the viviotech installer I even bugged Jordan Michaels ( great name dude :-) ) for some help.

I didn't imagine for a second it could be my test.cfm file as it only said "hello world", man do I feel silly now.

It turns out that everything was working just fine, but IIS7 was actually hiding the errors. Here is what happened.

What I had done on the default website was create a new text file, then rename it to test.cfm. Now by default windows hides known file extensions, so what I really did was rename it to test.cfm.txt but as I couldn't see the .txt I didn't realise.

As a result Railo was throwing file not found errors, IIS was hiding it and giving me a "500 internal server error".

On my 2nd site I had a working test.cfm file, but there was also an application.cfm which was trying to access a non existent DSN, which was also causing an error, which was also hidden.

The setting in IIIS that causes this can be changed as follows. Click images for bigger versions.

Open your IIS management console, select the ROOT to change this for all sites, or the site you want to change, and double click "Error Pages".

Now click on "Edit Feature Settings"

In the following dialog box change it to "detailed errors". The default setting only shows the errors locally on the server.

Thanks to Jordan Michaels for trying to help me resolve a non existent problem with his installer.

Although I did discover a problem with the FusionReactor instll at the same time :-)

Note that this issue effects ColdFusion and Railo or indeed any application server, all errors will be hidden by the IIS 7 default setitng above.

As of today, Railo 3.1 is now available at CFMLdeveloper.com.

If you already have an account then simply login to HELM and go to Packages -> add new and choose one of the new Railo Plans. Please note that the SETUP fee still applies for all new packages, but is still a one-time fee for fraud validation purposes and your hosting is then FREE forever. For more info please refer to the HELP pages.

If you do not yet have an account then simply SIGNUP from the hosting page.

Please don't forget to check the Hosting support pages if you get stuck, most common questions can be found there.

l have recently decided to try out MangBlog for the new cfmldeveloper.com site and I have to say I really like it much better than BlogCFC (sorry Ray).

Because MangoBlog allows you to add custom pages you can pretty much use it to create your entire web site with a basic CMS as long you don't need to do anything complex on your pages, at which point you may find the tinyMCE editor too restrictive.

When you add a custom page to MangoBlog the "title" is used not only on the page but also on the navigation menu, which I didn't find too useful as I did not want the menu text and page title to be the same. So I was instantly thrown in at the deep end with a requirement to customise MangoBlog, which thankfully turned out to be very easy as it is very well written and easy to understand.

MangoBlog is written in classic CFML style using imported tag libraries and <mango: mytag attributes> syntax as apposed to using the OO style frameworks that are popular these days.

Adding a custom page title is a snip.

When adding a new page, simply add a new custom field like this

label:    page title
key:      pagetitle
Value:   My Page Title

 

Now edit the page.cfm file in your skin folder and edit the code that displays the <mango:Blog title />, it will look something like this depending on your skin.

<h1 id="banner-header"><a href="<mango:Blog url />" accesskey="1"><mango:Blog title /></a></h1>

and change it to this

   <mango:PageProperty ifHasCustomField="pageTitle" customField="pageTitle" />
     <mango:PageProperty ifNOTHasCustomField="pageTitle"><mango:PageProperty title />
   </mango:PageProperty>

This checks for the existance of the "pageTitle" custom field on each page, it is exists then it will display that value, otherwise it will display the title.

You can use the same method to insert any custom field values on any page.