[22668] in bugtraq
Lotus Notes: File attachments may be extracted regardless of document
daemon@ATHENA.MIT.EDU (jjore@imation.com)
Mon Sep 17 16:07:43 2001
To: bugtraq@securityfocus.com
MIME-Version: 1.0
Message-ID: <OF6925D26A.D6722944-ON86256ACA.00655C15@imation.com>
From: jjore@imation.com
Date: Mon, 17 Sep 2001 13:52:52 -0500
Content-Type: text/plain; charset="us-ascii"
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
