Lotus Notes: File attachments may be extracted regardless of document security

[jjore () imation com]

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