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-alert@lotus.com. 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-alert@lotus.com is for
Reporting a security vulnerability associated with a Lotus product
What security-alert@lotus.com 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-alert@lotus.com works
The security-alert@lotus.com 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: kspan@lotus.com
jjore@imation.co
m To: bugtraq@securityfocus.com
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
