Normally when I read a post by James McGovern, I understand that he is trying to get under people’s skins in order to provoke a response. Some people respond to this by attempting to give the type of information that James is looking for in a post of their own. Others view it as a form of harassment and try their best to ignore it, though James just looks on that as a form of encouragement. Both reactions are perfectly fine.

I, and pretty much every blogger, are not compensated for writing our blogs, much less for responding to James. It is optional. When I blog, I do so as me, myself, and I. Not as an employee of any company or organization.

I mix the two above approaches. When I think a response may help the community as a whole, I do so. Sometimes I take what I read under advisement. Then there are the times when I just block it out. Last night, when I read his link to and description of a Documentum security hole, I decided that a correction was in order.

The Facts

First, let’s talk about the hole. You can read the description on the report itself as reported by CYBSEC. It applies to WDK-based applications in 5.3. The history of the Public Disclosure is relevant and worth mentioning.

• 2007-12-17: CYBSEC contacted Vendor.
• 2007-12-17: Vendor first response.
• 2008-01-04: Vendor confirmed vuln[erability] is fixed in latest SP.
• 2008-01-30: CYBSEC informed the vendor the disclosure plan.
• 2008-02-05: Advisory Public Disclosure.

I look at this and see that the vendor was fairly responsive. Remember, there were a few holidays in that time period.

The next piece is critical. It say that the vulnerability was fixed in 5.3 sp4. For those not in the know, that was released on December 20, 2006. So the fix for this was released one year before this report was brought to EMC’s attention. It wasn’t sitting out there waiting to be fixed. This issue was not reported in D6.

I think I remember seeing an alert from EMC on this issue in the fall of 2006, but as I can’t find the proof, I can’t confirm and could be mistaken. I will keep looking and if I find it, I’ll update this post.

None of this takes away from the fact of the vulnerability having been there in the first place. This was a critical issue, but as all companies release software with the occasional vulnerability, you have to take measure of the frequency of these issues appearing and of the company response.

All I have done here is comment upon the response which appears to have been pretty good.

The Crowded Theater

Now back to James. Remember James? This is an article about James (my apologies to Arlo Guthrie). James said (with hyperlinks removed):

If Documentum used tools such as Ounce Labs, Coverity or others, these types of problems would be minimized. I wonder how many additional holes were introduced by Fugly DFS?

There is the implication that Documentum doesn’t use any tools to analyze against security vulnerabilities. I personally don’t know. I would like to think they do. However, James seems to be making a statement based upon explicit knowledge, which I am not sure that he possesses. If he knows for a fact, I’d like for him to state as such and share with us how he knows. He also acknowledges that these tools only minimize the vulnerabilities. That is good, but not a guarantee! If some can slip through, is it not fair to say that it is possible that this error could as well?

Keep in mind, EMC may not have these tools. Knowing for sure would be nice. They may also have acquired the tools after the initial release of 5.3.

He also implies that DFS added additional holes to the Documentum platform. This one is more heavy on implication. The use of the word additional implies that the security hole in the report exists in D6, which it doesn’t from what I have researched. D6 was released a full six months after 5.3 SP4, so it was a known quantity upon release. The D6 WDK product is managed by the same people as the 5.3 product, so the knowledge would have been there.

James’ question is a fair question, just unfairly put. A fair way would be, Where any security holes introduced by Fugly DFS? (I leave the Fugly because that is his opinion of DFS and it wouldn’t be James without it.)

Freedom of Speech is great. Remember though that the courts have limited it when the speech leads to a panic that can endanger people’s lives. While this clearly doesn’t reach that level, there is a difference between alerting the community and the statements James made. I almost wonder if he read the alert in detail.

I’m still going to read James’ stuff, but he just slide a little further down the scale.