For those of you who may not follow these things, users of the open-source CFML context creation software known as "mod_cfml" should know that the latest release is actually pretty important with regards to security. The mod_cfml software is a group of programs that work together in order to automate the process of creating contexts within Tomcat. Usually the process of creating contexts is a manual job, which is accomplished by editing various configuration files in order to tell Tomcat where to find the files for specific sites and directories (or contexts) when Tomcat receives requests for them. The idea behind mod_cfml is to simplify server management, and make creating contexts in Tomcat happen automatically by passing off configuration information from Apache or IIS to Tomcat so a new context can be made if it doesn't exist yet. Pretty basic stuff.
The problem is that, before this latest release, this process of automating the context creation using mod_cfml could be exploited to create a Denial of Service attack on the system that is running mod_cfml. Using a specially crafted attack that is targeted at mod_cfml, an attacker could potentially issue multiple requests in rapid succession to a vulnerable system. This process would cause many contexts to be created simultaniously, and could potentially overload and/or crash the server.
The newest version of the mod_cfml Tomcat Valve corrects this problem by adding limitors to how quickly new contexts could be created, and how many contexts can be created within a single day time frame. These limitors protect users from the danger that previously existed and the possibility of a DoS attack that specifically targets this issue.
You can install the latest mod_cfml Tomcat valve by shutting down Tomcat, removing the mod_cfml Tomcat valve from the [tomcat]/lib/ directory, and dropping the latest mod_cfml Tomcat valve back into the [tomcat]/lib/ directory. Now, restart Tomcat and you're good to go. Documentation on adjusting the new limitors in the Tomcat valve can be found here:
http://www.modcfml.org/index.cfm/documentation/modcfml-tomcat-valve/config-options/
Railo users who have installed Railo 4.0.3 or newer will already have the latest version of mod_cfml, and OpenBD installers version 3.0 and up will have the latest release. If you are running with an earlier release and haven't updated your mod_cfml Tomcat Valve, you should consider doing so.
Just recently I experienced a problem with both installing or uninstalling Java (the JRE) on a Windows 2003 system. I had to research this quite a bit and there were no clear answers anywhere, so I though I'd post here on how I was able to fix it. In my case, I was using Windows Server 2003 64-bit, but this should apply to other Windows versions as well.
The error I was getting was as follows:
"Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor."
This error is caused when you delete the JRE directory without running the uninstallation program. The reason this causes a problem is due to the registry entries that the installer creates when the JRE is installed. There is a DLL that the installer uses to make (and remove during an uninstall) the registry entries. Without this DLL, both the install and the uninstall will fail. This error may also prevent you from installing updated versions of the JRE to your system - which is a security risk.
You can find the path to the DLL that the installer (or uninstaller) is looking for in your Application log. You can get to your Application log (at least on a Windows Server 2003 system) by going to Start - Administrative Tools - Event Viewer, and then selecting Application from the list on the left.
Once you're looking at the Application log, find the error message generated from the "MSI Installer" (It's probably the most recent error there if you just encountered the error.) and bring it up. In the "Description" text area, you should be able to see where the installer or uninstaller was looking for the DLL file it needs. This is important because it will tell you how to fix it.
The FIX:
The Fix for this is to give the uninstaller what it wants, and replace the deleted DLL files with ones that can be used by the install/uninstall process to edit the registry, etc. For convenience, I've uploaded a bin zip file that can be used for this purpose.
DOWNLOAD: => bin.zip (md5: b2594fa66d12a9e8fafb0a1ba3ca555f)
In my case above, you can see where I installed the JRE to the desktop (and then probably deleted it to remove the clutter). Only later, when I tried to install a new version, did it become a problem. So, I downloaded the above zip file, extracted it to my desktop, created a "jdk" directory and moved the "bin" folder inside it, then ran the uninstaller again. I got a few more errors about other files that couldn't be found, but the uninstaller worked and I was able to install an updated version like I wanted to afterwards.
So... the next time you install the JRE or JDK, remember that you can't delete it by hand without problems!
Hope this helps!
-Jordan
