Today, Adobe are announcing a new beta version of Adobe ColdFusion 9 software, the premiere server-side framework, runtime, and language for building HTML-based or rich Internet applications (RIAs). By extrapolating complex tasks into fewer lines of code, Adobe ColdFusion 9 enables you to build Internet applications faster and easier than with any other technology.

In tandem, they are introducing a new ColdFusion development tool: Adobe ColdFusion Builder(TM), available in beta today. Adobe ColdFusion Builder is an Eclipse(R)-based IDE for ColdFusion development that is deeply integrated with ColdFusion 9. Now you can manage your entire ColdFusion development cycle, from concept to production, with one easy-to-use tool.

By providing a highly customizable environment, Adobe ColdFusion Builder helps you to develop ColdFusion applications faster than ever before.

These beta versions of ColdFusion 9 and ColdFusion Builder will enable you to:

• Develop and manage applications faster and easier than ever before
• Create RIAs quickly and easily with ColdFusion and the Adobe Flash(R) Platform
• Integrate applications across a multitude of technologies in enterprise environments

To download the beta of ColdFusion Builder and get started today,

visit >

http://www.adobe.com/go/coldfusion_builder_beta_download?sdid=EUSXS

To download the ColdFusion 9 beta, visit >

http://www.adobe.com/go/coldfusion_beta_download?sdid=EUSXT

If you're interested in learning more about ColdFusion 9 or ColdFusion Builder, register to attend an eSeminar at no charge >

http://www.adobe.com/cfusion/event/index.cfm?event=detail&id=1345643&loc=en_us&sdid=EUSXR

Plus, visit Adobe MAX 2009 in Los Angeles for highly technical

sessions that can help you learn these tools >

http://max.adobe.com?sdid=EUSXU

Recent postings on SANS and The Register identify a vulnerability in some ColdFusion 8 installations. It involves the richtext feature found in the cftexarea tag. This TAG actually implements an open source rich text editor called FCKEditor. FCKEditor has functionality built in to handle file uploads and file management but this feature should be disabled in the version embedded in CF server. The problem lies in that in some cases the connector that runs this feature is actually turn on.

Is your connector enabled, to find out navigate to the following folder on your server.

CFIDE\scripts\ajax\FCKeditor\editor\filemanager\connectors\cfm

and Look at the config.cfm file. and see if the connector is on (config.enabled).

If enabled, this means a hacker might be able to directly call the filemanager system to upload files and take control of the server. FCKEditor has had some history on being exploited by this type of attack.

    // What the user can do with this connector
    Config.ConfigAllowedCommands             = "QuickUpload,FileUpload,GetFolders,GetFoldersAndFiles,CreateFolder" ;

Solutions:

1) Turn off the connector so that the filemanagement and file upload features can't work. Do this by commenting it out.

2) Just restrict what the filemanager can do, see code above, remove the fucntions you do not want to allow.

3) To be completely safe, delete the entire filemanager directory found under "CFIDE\scripts\ajax\FCKeditor\editor". The embedded version of FCKeditor for CF doesn't and really shouldn't use this feature. So removing those files completely is the safest thing to do. Be mindful that updates to CF might re-introduce those files and naturally re-open the problem. You can avoid this by making the file/folder read only so that it cannot be updated.

Please note that if your host is secure and runs sites so that they cannot read/write files outside of their own root, then any attack should only be localised to the attacked site and not the whole server.

At BlueThunder/CFMX Hosting we employ Security sandboxes for every site restricting access and PHP/ASP etc are also restricted in the same way using server security, so it should not be possible for any uploaded code to access paths outside of that website.

If your host allows CFFILE by default without a sandbox or only runs CF Standard edition, then beware as their entire server is vulnerable to this and just about any other file upload attack as well.

The Adobe Product Security Incident Response Team (PSIRT) has posted an official response to this issue here, a patch is expected soon, but in the mean time make sure you are not at risk.

UPDATE: hotfix now available HERE

As you will see elsewhere on my blog, I have recently setup windows 2008 server 64bit as my new desktop. For the most part everything has worked ok, but there have been a few interesting quirks.

One of these quirks was that any new site I setup in IIS7 resulted in a "500 internal server error" identifying the AboMapperCustom wildcard application mapping for ColdFusion as the cause.

Now my Default Web Site from where I run the CFADMIN was working fine, so I was rather perplexed as to why other sites did not work when they seemed to be setup exactly the same.

Now I am actually using DotNotPanel on my local machine to setup and manage sites, so this may be a contributing factor, but still the cause of the problems may affect others, so hopefully the solutions may help.

Using the Web Server Configuration Tool I tried to disable then enable CFML on the server several times to no avail, then when checking the Handler Mappings" for the site, I noticed that the wildcard application map for CF was actually there twice, which I am sure may well have been a contributing factor, so I removed one of them. I also then noticed this alert on the handler mappings page.

This site is in an application pool that is running in classic mode, 
so you can manage ISAPI extension and native modules that are mapped to 
paths. You must manage managed handlers (system.web/httphandlers) directly 
in the configuration files.

Now if I recall "classic mode" means 32bit, so this seemed likely to be causing a problem, although I am not sure how I ended up using this application pool by default.

Anyway to change this, open the IIS manager, find your site, right click and select

Manage Web –> Advanced Settings

And change the application pool at the top to "Default Application Pool". In my case this fixed the problem and the alert went away, hopefully this may help someone else having issues with IIS7 and CF.

This was a very odd problem I had on a clients site this week. Whenever he used the <CFAjaxProxy> tag on a page, the page simply stopped rendering at the point where the tag appeared. No error appeared on the page or in the ColdFusion logs.

The reason no error occurred turned out to be caused by the application.cfc, he has an OnError function that was doing a cfabort.

<cffunction name="onError" returnType="void" output="false">
        <cfargument name="exception" required="true" />
        <cfargument name="eventname" type="string" required="true" />
        <!--- <cfdump var="#ARGUMENTS#" /> --->
        <cfabort />
</cffunction>

Once I got rid of this problem, the following error appeared.

Security: The requested template has been denied access to C:\ColdFusion8\wwwroot\WEB-INF\cfclasses\cfcheckUsername2ecfc1070071758.class.
The following is the internal exception message: access denied (java.io.FilePermission C:\ColdFusion8\wwwroot\WEB-INF\cfclasses\cfcheckUsername2ecfc1070071758.class write)

So yet another path that needs to be added to the sandbox for every site in order for Ajax to work. Really there is no reason why this should be so as the classes should be created by CF internally and no special permissions should be required by the application.

The number of paths now required in each sandbox for CF8 in order for all tags and functions to work correctly is ridiculous. I have enlightened Adobe how things should work in shared hosting environments and all the paths that do not get inherited by sandboxes when applied at a root level, so here's hoping that CF9 will finally be shared hosting friendly.

For the last few weeks on one of our ColdFusion 8 servers I have been noticing an increase in performance issues. Requests would regularly start taking longer and timing out and it would often be happening to all the running requests and not just some. Strangely this also seemed to happen whenever I modified a security sandbox, which would usually take a long time to process the request and would also cause all other requests to slowdown and timeout as above.

One common factor I noticed while stack tracing these requests with FusionReactor and the server monitor was that they all seemed to be using Fusebox and there was a lot of class loading going on.

Now I know that frameworks like Fusebox and ModelGlue can be slow to initialise the first time as they have a lot of classes to load, but this shouldn't happen again unless an application is re-initialised or CF is restarted.

I had Charlie Arehart helping me look at this issue and he reminded me of the problem with Java 6, which I had totally forgotten about. For all the other performance improvements and increased functionality in Java 6, it introduced a bug in the class loader that causes substantially slower class loading. You can see a discussion of the problem on Sun's forums.

This bug will affect any application using a lot of CFC's, especially those using frameworks such as fusebox, ModelGlue, Transfer etc, due to the large number of classes that must be loaded as a result. So for those of you not caching your CFC's, perhaps it time to start doing so.

This lead us to the conclusion that whenever you make any changes to a security sandbox this causes all existing classes to be reloaded, which seemed to be confirmed by the stack traces which did show a lot of class loading happening in the slow running processes.

As the aforementioned bug is supposed to have been fixed in the current release of Java 6, I decided to go with Charlie's suggestion and give this a try and see if it resolved the problem. So I downloaded and installed the JDK 6 Update 12, set ColdFusion to use this version and so far I have not been able to repeat the previous issues when modifying security sandboxes, so it seems as though this solution has worked. It is however early days as I only made the change last night, so time will tell if this gives an overall performance boost to ColdFusion in general.

Updating ColdFusion to use a newer version of Java is very straight forward, so here are the steps for anyone interested in doing so.

Download the latest version of the JDK (or whatever version you need) from http://java.sun.com/javase/downloads/index.jsp

Now install this on your server in your desired location, but don't forget that you may need to setup additional permissions if you are not running ColdFusion in the standard configuration and have it running under anything other than SYSTEM.

now you need to edit your jvm.config file and modify the java.home path to point to the newly installed JDK.

On a standard installation this file can be found in c:\coldfusion8\runtime\bin\jvm.config, if you are using a J2EE or multi-server installation then your path will be different.

Comment out the existing java.home by adding a # to the start of the line and then enter your new path like so:-

#java.home=C:/ColdFusion8/runtime/jre

java.home=C:/Program Files/Java/jdk1.6.0_12/jre

Please note the path is using back slashes and not the default forward slashes that you will get if you copy and paste the path from windows explorer. This is required or ColdFusion will not start. If you are running multiple instances of ColdFusion with each using their own JVM.config then you will need to make this change in each jvm.config file.

Now simply restart ColdFusion, then login to your cfadministrator and go to the system information page, where it shows which version of Java is being used, which should now reflect your changes.

ColdFusion 8 Server Monitor

I also wanted to mention that while trying to diagnose these issues I tried using the built in server monitor, which unfortunately caused more of a hindrance than a help. It seems that enabling the Profiling and Memory Tracking on a live production server may not a good idea and could well bring it to its knees within minutes. While these options were enabled the JRUN memory usage started to climb and continued to climb until the max 1024mb had been consumed, at which point CF will stop responding. I also noted the memory tracking will also incorrectly report the memory usage of complex FuseBox variables, stating that they are several TerraBytes in size, so this seems to imply that again the problems were related to frameworks and class loading.

I have however enabled the server monitor briefly since updating Java and the memory consumption problem does seem to have gone but the incorrect reporting  of memory usage in application and request scopes is still there.

Sadly I have never been able to get the "Sessions by memory usage" or "CF Threads by memory usage" to work, they have always been blank, so whether these have the same issues I do not know.