A number of questions have emerged from the ColdFusion community about the recent FCKEditor security vulnerability in ColdFusion. Hopefully this fills in more information for you.
Before I get into it though, let me just say that this isn’t an attempt to excuse the problems you’ve had. We know that you had a crappy week last week (or this week), and regret it. We do need to review what happened, and determine if we could have done this better. Personally, in hindsight, there’s one decision we should have gone another way on: we should have released the workaround sooner.
Is it true that Adobe had a fix for months and sat on it?
No, the issue was reported to us 7 weeks before exploits hit last week.
The workaround was pretty easy, why did it take you six weeks to come up with?
In this case, the issue was reported by a customer. The customer was not satisfied with just a workaround for several reasons including concern that we were not actually fixing the correct problem. (This concern ended up being true.) Additionally, our security people were also not entirely convinced that the workaround was entirely the right solution. (Although, I need to state here that the workaround that is now circulating does close the security hole.)
For those reasons, a hotfix was the preferred solution. A hotfix takes more time to create. We had to create the hotfix, then test it to make sure it didn’t break anything, and then provide it to the customer for their approval. We also had to communicate with the FCKEditor folks, to insure that we were correct in understanding their code. In short in addition to testing there was a lot of communication between many groups, and that burned up the time.
Now let me be clear here, I’m not casting blame on to the customer or any third party. Communication takes time, and in this case it took a fair amount of time. If you want to know more about this process it’s publicly documented on the PSIRT blog.
Why didn’t Adobe say anything at that time – the workaround was found pretty quickly?
If we acknowledged the security vulnerability and released the workaround we’d be leaving the reporting client in a lurch. There would be public knowledge of a vulnerability, but no acceptable solution for our customer (as they required the hotfix solution.) We made the call to make the fixes privately and announce when we had a solution we were confident in.
In this case it ended up biting us and you. We now know we should have released the workaround as soon as we knew about it.
But honestly I’m personally torn. On one hand, we should have told you guys sooner, as evidenced by the public exploits. On the other hand, we weren’t arbitrarily holding it back, or idly sitting around – the security group was trying to get a proper fix out before an attack occurred. I think we just got some bad luck.
I’m sure you have opinions on this. Feel free to let me have it in the comments.
Did the Adobe shutdown exacerbate this issue?
The security response process was already in progress. Our teams that work on patches were not off that week, so the actual fix was not delayed. The Adobe Security team responded within a day of the reported problem. So I’m not sure the shutdown had a large effect on our official responses.
If you have other questions, please feel free to ask them in the comments.
tpryan.blog 
Terry, in your post you talk about a hotfix being devloped for this but I don’t see that it’s available. Do you know when it will be available?
LikeLike
It should be "soon." I think we’ve said something along the lines of later in the week.
LikeLike
Chris, to be clear here. Don’t wait for the patch to get released – you need to check for this as soon as possible and do the recommended setting change.
LikeLike
Well I was holding back on this to see if anyone wanted to question this first, but I’ll go ahead.
"Personally, in hindsight, there’s one decision we should have gone another way on: we should have released the workaround sooner." Naturally I agree and hope this happens in the future.
The damage is done. The key at this point is to fix the problem and prevent this from happening again. That is the light I’m taking in my following questions.
"Is it true that Adobe had a fix for months and sat on it?" Your time line says essentially 8 weeks ago from this week (so about 2 months). Bare in mind the hotfix still isn’t out yet so the clock is still running. So 8 weeks ago, was that the official post/request for the hotfix or the initial contact?
"The customer was not satisfied with just a workaround for several reasons including concern that we were not actually fixing the correct problem. (This concern ended up being true.)" Sounds like confusion on the Adobe end of this. That naturally makes me even more concerned about the internal process at Adobe. Yes, there should be a procedure, but once a security vulnerability of this level has been detected, the black hats typically already know. Perhaps I’m missing something, but I simply can’t think of any reason why it should have taken this long given the nature of the vulnerability.
"Additionally, our security people were also not entirely convinced that the workaround was entirely the right solution." Why? It really is a simple solution. What other options did they really have?
On the flip side of this, did management not understand the nature of the problem? What was their reaction to this initially? It’s on them to understand the gravity of this and to act. I suspect from this post that some of this is being dump on the security team when management really has to take full responsibility.
The other part of this is why the vulnerability was allowed to live on in the CF 8.0.1 trials / downloads from Adobe. Some people had fairly new instances being created in the meantime that didn’t need to have this bug open. Basically, you could have limited the fire by doing that.
LikeLike
The current PSIRT posts still says ‘potential’ security issue (http://blogs.adobe.com/psirt/2009/07/potential_coldfusion_security.html). Avoiding confusion at this point is very important. Some may read that title and think it’s not a big deal. It’s not a ‘potential’ issue but a very high security risk that has been confirmed by a number of people. I would advise modifying the title to make that completely clear.
LikeLike
I hope for one thing this doesn’t hurt Adobe’s attitude towards Open Source projects. I for one am very hopeful that Adobe continues to integrate high-quality OSS like FCK (in ColdFusion) and Subversion (in Dreamweaver) into their products. I’ve been using both with ColdFusion for almost six years now, and I’m very happy to see this sort of action on Adobe’s part. Too often OSS project teams are difficult for corporate product teams to deal with, either through personality conflicts or the slow communications that come from dealing with largely volunteer efforts.
I’m not very familar with the FCK developers, but I hope Adobe’s interaction was a positive one over this matter.
LikeLike
Brian: We use OSS in CF pretty extensively. I don’t think this will be affecting our use of it.
LikeLike
As Ben Forta has posted on his blog at http://forta.com/blog/index.cfm/2009/7/8/ColdFusion-8-Security-Bulletin-Posted, we (Adobe) have now posted the Hotfix for this issue and you can read more about it in the accompanying security bulletin available at http://www.adobe.com/support/security/bulletins/apsb09-09.html
LikeLike
I actually submitted a security report to PSIRT on Feb 3 for this issue and was told February 20 (after requesting a status report) "the development team is closing in on a fix, and we should have a tentative patch schedule to pass along to you soon".
LikeLike
In the end I think Adobe did a great job and what most companies do and would do. Its a tough to know how much information disclosure will help or could fuel more exploits. I actually hope Adobe bundles more open source and RIA Forge projects with releases. It seems like their are great solutions out there for many things that could be bundled. Not that we need true CF tags to interface with these but some better integration. Standard extensions type folders and even a standard mechanism by which someone could check for updates to the bundle code. It could just be some xml with an extension ID, name, code repository url, author, license, version, etc.
LikeLike