Blog

Adobe released some new security updates for ColdFusion 10 and 11 yesterday.  This brought with it the usual flurry of twitter activity from security-minded accounts who pounce on the opportunity to retweet every vuln report on the internet.  It's too bad no one takes this much effort to focus on positive news from other languages.  Among the landslide of tweets were also a few people poking at ColdFusion such as this person who went as far as to say businesses should scrap all use of Adobe products in general due to the number of vulnerabilities.

The world is abuzz with the OpenSSL "heartbleed" bug and the ColdFusion community has also been going 'round about it too.  Firstly, a server (like Apache, Nginx, Tomcat, etc) can be exploited by a client on a hackers machine requesting an SSL connection.  In addition, a client (CURL, wget, CFHTTP, etc) can be exploited if connecting to a malicious SSL endpoint.  So basically, the bug has the ability to flow both ways. 

For most CF sites, they are using IIS, Apache, or Nginx to serve content so ColdFusion has no bearing on the vulnerability from that end.  Any CFML application, however, can connect to a malicious SSL endpoint.  Of course, it only matters if the OpenSSL library is specifically being used.  Any other SSL implementation is safe.

To date, neither Adobe or Railo have yet to make public announcements via security bulletins or their official blog.

UPDATE April 17: Railo responds here.

UPDATE April 18: Adobe responds here:

There have been a handful of less "official" conversations in mailing lists and Twitter.  As best I can tell, neither Adobe ColdFusion or Railo use OpenSSL and therefore are safe.  Of course, any other parts of your web stack (even bundled libraries) might use OpenSSL.  Gert from Railo has promised a blog entry "soon" to address the issue regarding Railo.  There has been some complaining about the lack of official word from Adobe, and my understanding is that the ColdFusion team's hands are tied by the Adobe PSIRT who are the only ones allowed to comment publicly on security matters.

 The general consensus is they could certainly say something, even if it was simply, "Hey, we're looking into it and will get back to you soon".  That as it is, I E-mailed Adobe's PSIRT myself and got a reply that seems as close to an official reply as they are willing to provide at this point though I'm unclear why they're talking about it one-on-one but refraining from public statements.  For the sake of those who haven't E-mailed PSIRT, I will post their reply here for the benifit of the community until something official comes out.  Also, for funsies, I'll post my original E-mail plus my followup.  If I hear back again, I'll update this post.

---

From: Brad Wood
To: [email protected]
Date: Wed, Apr 16, 2014 at 5:45 AM
Subject: Adobe ColdFusion and Heartbleed

Dear Adobe PSIRT team, 

 

I would like to encourage you to please make a public announcement regarding Adobe ColdFusion and if it is vulnerable to the latest OpenSSL "heartbleed" bug. This is a very significant bug that has people around the world scrambling to patch their software.  Even if Adobe ColdFusion is not susceptible to the recent "heartbleed" bug I would strongly suggest making an announcement on your blog to state that or authorize the ColdFusion team to do so on their blog. 

 

Many people in the CF community have noticed the silence on this issue and an official announcement really needs to be made in order for your customers to feel safe and to verify with their employers that they have all the patches they need.  Communication is very important and I hate to see the Adobe ColdFusion team getting beat up for not addressing this issue publicly on their blog.  Please authorize them to make some kind of statement on this.

 

Thanks!

 

~Brad

---

From: [email protected]
To: Brad Wood
Date: Wed, Apr 16, 2014 at 1:39 PM
Subject: RE: Adobe ColdFusion and Heartbleed

Hello Brad,

 

Thank you for contacting us.  We appreciate your feedback.  Please note that ColdFusion does not use OpenSSL. However, customers who are using an external web server with their ColdFusion deployment (ex. Apache) should test for CVE-2014-0160. If affected, customers should follow the recommendations provided in the OpenSSL security advisory, available at https://www.openssl.org/news/secadv_20140407.txt. Adobe

also recommends consulting the ColdFusion lockdown guides for security best practices:

https://www.adobe.com/content/dam/Adobe/en/products/coldfusion-enterprise/pdf/cf10-lockdown-guide.pdf

http://www.adobe.com/content/dam/Adobe/en/products/coldfusion/pdfs/91025512-cf9-lockdownguide-wp-ue.pdf

 

We hope this information is helpful.  Please let us know if you have additional questions.

 

Thank you,

Adobe Product Security Incident Response Team

---

From: Brad Wood
To: [email protected]
Date: Wed, Apr 16, 2014 at 3:13 PM
Subject: Adobe ColdFusion and Heartbleed

Dear PSIRT Team, 

 

Thanks for the reply.  I appreciate the links and concern.  Let me be very clear though-- I am not asking about this for the sake of my servers, I am letting you know that Adobe needs to make a public official statement on the matter for the entire community to see.  Even if your blog entry said nothing more than what you put in your E-mail reply that would be great-- but the community has noticed the lack of public response by Adobe to this matter and it's reflecting quite poorly on your PR.

 

If the PSIRT team doesn't have time to make a quick announcement, please authorize the ColdFusion team to put out a blog post.  This would do a lot for the community as silence breeds distrust and most every other major technology stack have already addressed their platform publicly-- even if just to say they are not vulnerable.

 

Thanks!

 

~Brad

 

UPDATE April 18:

---

From: Brad Wood
To: [email protected]
Date: Thu, Apr 17, 2014 at 9:50 PM
Subject: Adobe ColdFusion and Heartbleed

Dear PSIRT team,

 

Can you please respond to the comments on my blog made by a community member named "Aaron".  He has listed several binaries that ship with ColdFusion that supposedly use OpenSSL.  His comments can be found here:

 

http://www.codersrevolution.com/blog/adobe-product-security-incident-response-team-on-coldfusion-and-heartbleed#comment_798

 

Also, if you haven't seen it-- here is the official response from the Railo team (a competitor of Adobe CF) which categorically addresses the uses of SSL inside Railo server.

 

http://blog.getrailo.com/post.cfm/railo-server-and-the-heartbleed-vulnerability

 

Thanks!

 

~Brad

---

From: [email protected]
To: Brad Wood
Date:  Fri, Apr 18, 2014 at 2:58 PM
Subject: Adobe ColdFusion and Heartbleed

Hi Brad,

Thanks to you and Aaron for bringing this to our attention.  With your input, we started a deeper investigation of ColdFusion components.  We have also clarified our blog post regarding OpenSSL in ColdFusion (http://blogs.adobe.com/psirt/?p=1085).  Should additional information arise from our investigation we'll provide an update to our blog.

 

Thank you again for your help,

Adobe Product Security Incident Response Team

Update: There's an updated blog post with more current results here: 

http://www.codersrevolution.com/blog/whos-had-more-vulns-redux-php-java-coldfusion-ror-or-net

---

I get tired of people on complaining about ColdFusion as a technology choice because it's "so insecure".   I regularly am told that it has more holes, more vulnerabilities, and a worse track record than other platforms. That's why I compiled this quick chart showing the number of Common Vulnerabilities and Exposures (CVE) by year for CF as well as PHP and Java (as reported by cvedetails.com) which are two of the most-used languages on the web.  I also threw in Apache Tomcat for comparison since it completes in the web space and CF10 actually runs on a version of it.

 

Click to enlarge

So to break this down, the red line riding out on top with a huge spike in 2007, that's PHP.  The purple line coming out of the backfield for a solid lead (?) at the end is Java.  The yellow line is Tomcat who still manages 10-15 vulns a year (and the only one to go LOWER than CF.  And that green line on the bottom with the lowest number of vulns every year, and nothing even reported until 2006- that would be CF.

So, sure-- there's a lot more info than just the counts on the chart.  My point also isn't that PHP or Java are bad-- I'm just trying to make the point that oft-used technologies are targeted by crackers and nobody is perfect.  And according to this data, CF is doing way better than several of the main techs out there.  It should also be noted that CF, Java, and PHP were all created the same year-- 1995, so don't give me any of this "old" crap either.  (Tomcat was created in 1999)

References:

• http://en.wikipedia.org/wiki/Timeline_of_programming_languages
• http://en.wikipedia.org/wiki/Apache_Tomcat
• http://www.cvedetails.com/vendor/74/PHP.html
• http://www.cvedetails.com/product/8739/Adobe-Coldfusion.html?vendor_id=53
• http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_id=5
• http://www.cvedetails.com/product/887/Apache-Tomcat.html?vendor_id=45

 

The next stop on our PCI DSS Compliance tour is disabling weak SSL versions and encryption ciphers. If your site is handling credit card payments, it is undoubtedly using HTTPS for at least the pages that collect payment information. I thought I had already taken care of this item, but I was apparently mistaken. Fortunately, this is pretty easy to fix and if you're on Windows I've even cooked up a quick and easy registry file for you to use.

As a web developer you have your share of demons you have to face. If your company processes credit cards, chances are your yearly PCI DSS compliance scan is one of those demons. I thought I would do a short series on a few security items I tightened down as a result of our last PCI scan. This is by no means a comprehensive list of everything needed to pass a PCI scan. If you want to know that and have time to read a 74 page PDF you can get a copy of the Spec at www.pcisecuritystandards.org.

A lot of you have web servers that double as mail servers to relay out mail from your ColdFusion applications. Even if you have a separate server that handles your mail relay, this post should still be helpful. The more and more that spam proliferates on the Internet, the more antsy ISPs get about blocking mail. There are a litany of reasons an ISP might reject mail from your server. GoDaddy has been one of the most annoying companies to deal with. There are two things I had to fix on my mail server before they would accept mail from my server. Reverse DNS and Helo host name.

I found an interesting little bug in the BlogCFC implementation of ColdFISH today. ColdFISH is a ColdFusion code formatting component that is instantiated once and cached as a singleton in the application scope in BlogCFC. The problem is, ColdFISH looks like it wasn't intended to be used as a singleton. It makes use of the variables scope to store the Java StringBuffer class it uses to gather up your formatted code as well as a number of other variables used to parse the code it is formatting. This means when two or more people hit a BlogCFC entry with larger code samples, race conditions exists.

Some time ago GoDaddy manged to get the IP address of my VPS in their little black book and began refusing to receive any mail which originated from it. Unfortunately for me, I use GoDaddy for my E-mail hosting and that meant I stopped getting all E-mails that were sent from my server. A couple weeks ago I got around to calling them to see just what was going on. I would rather mud-wrestle a large sea-sick crocodile before repeating this tedious conversation with their bumbling excuse for tech support. Here are the details of my correspondence with them.

Matt Woodward pointed out this Slash Dot article today about the accidental release of code from the Sequoia Voting Systems and a web site dedicated to studying that code. Apparently the Election Defense Alliance obtained a copy of the election data for Riverside County, California. It came in the form of a Microsoft SQL Server backup that was SUPPOSED to have all the code such as stored procs and triggers redacted. I wandered over to the "Sequoia Voting System Study Project" and scored me a copy of the data.