This report is currently under investigation by Lotus and is being tracked as SPR# KSPR52NVP5. Customers who do not have existing support contracts with Lotus and who wish to report a potential security vulnerability with one of our products can contact us by sending email to security-alertat_private I regret that this information was not provided to you when you contacted Lotus with your report. Reporting Security-Related Issues to Lotus Lotus takes security very seriously and responds quickly to address any security-related problems involving our products. We have set up an e-mail address that makes it easy for customers to report a potential security vulnerability to us. What security-alertat_private is for Reporting a security vulnerability associated with a Lotus product What security-alertat_private is not for Although we wish we could answer all questions that are sent to us, we simply cannot. This is not the right place to send e-mail about how to use Lotus products or security features, or how to troubleshoot problems with Lotus products. Lotus offers several options for technical support, including You can search our Knowledge Base or learn about self-service and paid support options at http://www.lotus.com/support You can participate in user-to-user forums on Notes.net at http://www.notes.net/cafe.nsf How security-alertat_private works The security-alertat_private mailbox is monitored by Lotus personnel who will promptly respond to any report of a newly identified problem. To help us investigate your issue completely, please provide as much information as possible, including: A complete description of the problem. A description of how the problem can be reproduced. Your operating system version information (including any service packs or patches installed). Version information for the product involved (e.g. Domino R5.0.8). Version information of any other software involved, such as a browser. Contact information (an e-mail address and phone number) in case we need to contact you for additional information. Regards, Katherine Spanbauer Lotus Security Product Manager IBM Software Group Phone: 617-693-6329 Email: kspanat_private jjoreat_private m To: bugtraqat_private cc: 09/17/2001 11:52 Subject: Lotus Notes: File attachments may be extracted regardless of document AM security Hello, This is my first post to the list. I'll try to get this right. The short version is that file attachments and other objects may be extracted from Notes databases regardless of any author or reader fields on the documents the objects are attached to. This goes back to the structure of Notes files. Most of the things people deal with in Notes are documents. Those documents have Note IDs. There's another class of stuff called objects. They are referenced by their Object ID. It turns out that both Note and Object IDs are really RRVs or Record Relocation Vectors. This puts each "thing" as a peer in the Notes world. Under most circumstances you don't ever have to be aware of Objects. If you use the published C API you can create, delete, read, and alter the objects in a database. Since an object is a peer to a note, any information a note has about an object will not be taken into consideration if the object is accessed directly. Consider this, when you detach a document you access it via the document. Any access to the attachment is mediated through the note since that's how you find the attachment. With this in mind, if you know the Object ID of a file attachment you can use the NSFDbReadObject call to load the file into memory. Since reader/author fields are a function of the note the object is attached to they aren't taken into consideration. I talked to Lotus this morning and they said it was not a problem unless I wanted to purchase a "Developer Support" contract. I already have a standard support contract but that isn't good enough. If I had a contract and could open a case with them *then* this might be a bug but not before then. Since this is supposed to be a "normal" thing to do, I figured I'd tell you all about it so you can keep it in mind when looking for problems. I tested this on a NT4SP6a and W2K workstation with a 5.0.6 server (NT 4 SP6a) using Notes 5.0.7. There is no particular reason this shouldn't affect any other 4.x or 5.x server since this uses the generic API. Can someone with access to Rnext verify if this works there also? To duplicate the problem: Create a new notes database Create a form with two fields. One should be rich text and the other a Readers field. Set the default value for the readers field to a role like '[Admin]'. Add the '[Admin]' role to the database and ensure you have that role. Create a document, attach a file in the rich text field. You should uncheck the 'Compress' box so you can still read the file after extraction. The extraction process will return the compressed file in the 'HUFFMAN 1' encoding. I don't know how to read that right now so this is best checked with uncompressed data. The problem works the same either way. I suppose if the field is encrypted you will get an encrypted file back - not much good without the key. Alter your access so you have reader privileges without the [Admin] role. You should not be able to locate the document in the database. If you can you haven't followed the directions correctly. Run the 'DumpObjects' code against the database and look for a larger object. That is your file attachment. You have successfully extracted a file attachment without having access to the document it is attached to. You'll also notice that your object access isn't tracked in the usage log. Try this under a different name to drive the point home. You will see a connect with zero documents read or written. See http://www.greentechnologist.org/domino/NSFDbReadObject.txt for information on the API call. See http://www.greentechnologist.org/domino/DumpObjects.lss for the object extraction code. The only workarounds or solutions I can think of involve either not using file, OLE, and ActiveX objects, encrypting documents by default or banning developer clients from untrusted users. If you ban developer clients also make sure to block lotus.com and notes.com from web access. Either that or just ignore the problem as unlikely to be exploited. Cheers, Joshua b. Jore Domino Developer (ex-candidate for mayor of Minneapolis) 651-704-7043
This archive was generated by hypermail 2b30 : Mon Sep 17 2001 - 20:14:02 PDT