GoogleIt Mail IT Print IT PermaLinkThe Truth About Notes Client Security Fixes
12:04:12 AM

Some people... I don't know who first... recently made the claim that Lotus and IBM have never had to issue a patch for a critical Notes client security problem. Depending on how you define "patch", this may indeed be technically true. Even the fixes to problems that were announced last week went out in regular scheduled maintenance releases 6.55 and 7.01, not in critical fix packs. Nevertheless, the fact that a bunch of security alerts about Notes client issues went out so soon after that statement puts a little bit of egg on our collective faces. Other people don't necessarily draw such a fine distinction between "patches" and "maintenance releases" as we would want them to.


And the truth is, this is not the first time there has been a security problem in the Notes client. It may indeed be the case that IBM and Lotus have always managed to put the fixes into scheduled maintenance releases rather than unscheduled fix packs, but there have been bugs. As I just mentioned in a reply thread over on Ed Brill's blog, I did the QA work on one such fix, and it was a big one. It was about ten years ago, and I've told very, very few people about it until now.


There was a front-page article in one of the major trade magazines, based on a press release from a company called Sybari (now owned by Microsoft) promoting the benefits of their Antigen product for Notes. The article contained mention of several well-known issues that were not really significant problems, but it also mentioned something that Sybari called "stealth forms". Over the next few days, discussions about the article in various places where Notes people hung out arrived at the conclusion that "the rest of the article is all stuff we know about, and we've never heard of these stealth forms, so they must not exist"... but they did.


Ray Ozzie himself verified that the "stealth forms" bug was real. It was a way to put a stored form containing malicious code into a document without leaving behind any of the normal tell-tale signs that the document contained a stored form. This was no buffer overflow or other type of coding error. It was a design flaw that opened a security hole. The bug was a consequence of the recursive nature of various routines used to process both the rich text of a form and the rich text stored in rich text fields. Even now, despite the fact that the bug was fixed a long, long time ago, I'm not going to give the details of how stealth forms were created, but I will say that it was incredibly simple to do it, requiring only a simple agent to manipulate fields in a document containing a stored form in order to hide the fact that the stored form was there while still keeping all the stored form's code active. When the fix was done, Ray's email about the problem was forwarded to me, and I was asked to validate that the fix really stopped the exploit. I believe I still have that email stowed away in an archive somewhere.


This bug pre-dated some of the security features that we take for granted in the Notes client. AFAIK, it was this particular bug, as a matter of fact, along with some demonstrations of various less dangerous exploits using stored forms and LotusScript, that spurred Iris to first implement a way to reject stored forms in all databases, then to implement a way to enable or disable stored forms on a database-by-database basis (in 4.1, I think), and then to implement code signing and the ECL (in 4.5, I believe) so that stored forms and other types of active content could be controlled on a very granular level.


This was a particular interesting security bug in Notes, and it took everyone by complete surprise, but my main point is that it is just one example. There have definitely been other client-side security fixes in various maintenance releases. It's absolutely fair to say that the number of exploits in the field of Notes client security bugs is essentially nil, and it's also fair to say that the intrinsic security of the Notes client today is vastly superior to any other communications and collaboration client with a comparable installed base, but let's try not push our luck with the claims. Let's not walk the fine line between "maintenance releases" and "patches". We don't have to. We have a strong enough security story without doing that.

This page has been accessed 244 times. .
Comments :v

1. Nathan T. Freeman02/17/2006 09:01:58 AM


Rich, are you saying there's a way to turn off stored forms for an entire enterprise or server? Please share that, because I thought there was only the database switch

In case you didn't guess, I despise stored forms. :)




2. Sean Burgess02/17/2006 09:17:25 AM
Homepage: http://www.phigsaidwhat.com/


I think what Rich is saying is that, by default, stored forms are not enabled for databases when they are created. Developers have to manually enable Stored Forms for each database. Right?

Sean---




3. Ben Langhinrichs02/17/2006 09:31:00 AM
Homepage: http://www.GeniiSoft.com/showcase.nsf/GeniiBlog


The whole claim seems very odd. The only way that it would be a good thing that you had never issued a critical security patch would be if there had never been a critical security problem. Besides what you report here, I have reported two nasty security issues that allowed a user to fairly easily circumvent the ECL. Both were fixed in whatever the next QMR was. But why would anyone be proud that there wasn't a faster fix to a critical security issue?

I'm afraid such a claim is really just FUD on IBM's part, raising fear, uncertainty and doubt about Microsoft products unfairly. This is no less true even though Microsoft has a deplorable record with security. Does IBM really have a better record with regard to security issues, or are there just fewer of them?




4. Richard Schwartz02/17/2006 09:42:55 AM
Homepage: http://www.rhs.com/poweroftheschwartz


I believe there was an INI setting, in a release after 4.0 - probably 4.01 or 4.02. In 4.10, they put in the database property, and it's possible that they obsoleted the INI variable at the time. I don't think it was a server setting, though. I think it was a client setting.

I've searched my old partner forum archives, though, and I can't find any documents that reference the INI variable, though, so I could be mis-remembering the whole thing. Andre Guirard would be a good person to ask, as he was right in the middle of all the issues with stored forms at the time.




5. Andre Guirard02/17/2006 12:52:31 PM


Sorry, I don't recall anything about an INI variable. That's not to say there wasn't one, though! I wasn't really involved in the solution -- just a prominent complainer.




Enter Comments^


Email addresses provided are not made available on this site.





You can use UUB Code in your posts.

[b]bold[/b]  [i]italic[/i]  [u]underline[/u]  [s]strikethrough[/s]

URL's will be automatically converted to Links


:-x :cry: :laugh: :-( :cool: :huh: :-) :angry: :-D ;-) :-p :grin: :rolleyes: :-\ :emb: :lips: :-o
bold italic underline Strikethrough





Remember me    

Monthly Archive
Responses Elsewhere



About The Schwartz

rss.jpg


All opinions expressed here are my own, and do not represent positions of my employer.