Technote # 184674 Q&A: BugTraq "Lotus Notes Stored Form Vulnerability"
http://support.lotus.com/sims2.nsf/eb5fbc0ab175cf0885256560005206cf/89e023ae7ee59e5d852569f90059fd5e?OpenDocument
* Title: Q&A: BugTraq "Lotus Notes Stored Form
Vulnerability"
* Product Area: Notes
* Product Release: Notes Client 5.x, Notes Client 4.6x
* Topic: Workstation/Desktop \\ Notes Client Functionality
\\ Security \\ ECL
Document #: 184674
Last Update: 02/23/2001
BODY:
What methods are available to protect against potential attacks using a
Stored Form in a mail message?
1. Disable the Stored Form setting for all mail files.
OR
2. Use Execution Control Lists (ECLs) to define trusted signers of
executable content and assign appropriate levels of access.
When were these features introduced?
The Database Property for "Allow use of stored forms in this database"
was introduced in Notes R4.1. The Execution Control List (ECL) feature
was introduced in Notes R4.5.
What is a "Stored Form" and how is it used?
When designing a form, a form property can be enabled that will store
the form design with the document. The most common usage of this
feature is when a document will be mailed and the form does not exist in
the users mail files. By storing the form with the document, additional
functionality can be added. For more information on Forms and
Documents, please see the Help document included below.
How can the use of a Stored Form be detected for a particular mail message?
The existence of a $Title field on the document indicates that the form
is stored with the document. The $Title field will contain the name of
the form.
How can Stored Forms be disabled?
This setting is configured in Database Properties. To disable it,
uncheck the box on the Basics tab for "Allow use of stored forms in this
database".
Who has access to change this setting for a database?
Manager access in the ACL is required to change database properties.
How can administrators disable this setting for all user's mail files?
Disable the setting on the mail template(s) used in your environment and
run the Design task (load design from the server console, or as a
scheduled task).
When new mail files are created from the template, this setting will be
disabled. In addition, when the design task runs (by default, this
occurs nightly at 2 am), all databases that inherit from the updated
templates will now have this setting disabled. This technique assumes
that mail files inherit their design from a specified template(s), which
is the default behavior.
If Stored Forms are not enabled for a database, what will happen when the
user opens a mail message containing a stored form?
The user will be prompted with a dialog box with the following message;
"This document cannot be displayed in its original format because it
contains a stored form. This database does not allow use of stored
forms. Notes will attempt to open the document using a different
format."
The default form for the database will be used to display the document
instead. Any code associated with the form will not be executed, and
some field values may not be able to be read using the default form
(i.e. the "Memo" form in mail databases).
Where is the Execution Control List (ECL) stored and configured?
The ECL is stored for each user in their desktop.dsk/desktop5.dsk file.
Users can access their ECL from File\Preferences\User
Preferences\Security Options. Administrators can configure domain wide
settings in the Public Address Book/Domino Directory by selecting
Actions\Edit Administration ECL. Workstation ECLs are inherited from
the Administration ECL during workstation setup. In R5.0.5 or higher,
these settings can be refreshed from the Administration ECL by clicking
the "Refresh" button on the Workstation Security Options dialog. The
use of the @RefreshECL command can also be used in formulas to update a
user's settings.
How do ECLs protect workstations?
ECLs rely on the use of digital signatures. When a design element is
created and saved, it is signed with the user's private key from their
ID file.
When executable code is activated, Notes checks the signature and
verifies what level of access the signer is allowed for that user's
workstation. Notes relies on the use of certificates to verify these
digital signatures. If a signer can be verified and is listed in the
ECL, the rights assigned for that entry apply. If the signature is
verified, but an entry for the signer does not exist, the rights
assigned to the "Default" entry apply. If a signature cannot be
verified, the access rights assigned to the entry for "No Signature"
apply.
What is the "Lotus Notes Template Development/Lotus Notes" entry in the
ECL?
All Lotus Notes templates shipped with the product are signed with this
ID file. This entry is listed in the ECL with all access rights enabled
which means that code signed with this ID is trusted to execute on the
workstation.
Is it possible for someone to create an ID with the name "Lotus Notes
Template Development/Lotus Notes" and evade the ECL?
No. While it is possible for an ID to be created with the same name,
the public/private key pair will not match the original. When code
signed with the false ID is executed, Notes will be unable to verify the
signer and therefore the rights assigned to the entry for "No Signature"
will apply. If "No Signature" is not permitted to execute that
particular action, Notes will generate an Execution Security Alert
dialog box with the warning that "The version of Notes you are running
does not recognize the Template Development key that signed this
document".
What are the Lotus recommended ECL settings for the "Default" and "No
Signature" entries?
Both "Default" and "No Signature" should have all access rights
disabled. Beginning with R5.0.2 (available in Dec 1999), this is the
default configuration.
Related Documents:
How ECLs Respond to Changes in the Notes/Domino Environment
Document #: 183254
Recommendations for Deploying Tighter ECLs in Notes R5
Document #: 183256
Default ECL Entries Beginning with Notes 5.0.3
Document #: 183257
"Staying Alert with Execution Control Lists"
by Amy Smith, published on Iris Today on Dec 1, 1999 at
http://www.notes.net/today.nsf/9148b29c86ffdcd385256658007aaa0f/3a9da544637a69b2852568310078b649?OpenDocument
>From R5 Designer Help:
Forms and Documents
When a user creates and fills out the information in a form and saves it,
the information is saved as a document. When a user opens the document, the
document uses the form as a template to provide the structure for
displaying the data. When designing forms, you should consider where and
how the resulting documents will be displayed.
A form is stored in the database it was created in and used to display all
associated documents. However, there may be times when you are mailing a
document to a database that does not have the form that was used to create
the document. In those cases you can designate the form to be stored with
each document created from it. Storing the form with each document does
consume more memory.
When a user opens a document, Domino uses these rules to determine which
form to use to display it:
Condition Form used to display document
If the form used to create The form that was used to create the
the document is available and document. The original form name is
there is no form stored in stored in a hidden field called "Form"
the document and no form in the document. To find the value of
formula the field you can check the Document
Properties box under the Fields tab.
If a form is stored with the The form stored with the document.
document (When a form is stored in a document,
the form name is stored in an internal
field called $Title.)
If the view has a form The form is determined by the view's
formula form formula.
If the form used to create The default form for the database. Each
the document is not available database can have only one default
in the database form, which is marked with an arrow in
the Forms list.
Storing a form with each document
Storing the form with each document allows the document to display
correctly even in a database where the form is missing, renamed, or
deleted. This feature uses more system memory and may require as much as 20
times more disk space. It can also cause additional work if you change the
form design because there is no easy way to update all of the stored copies
of the form. In general, store a form in a document only under these
conditions:
The database to which documents are mailed or pasted does not contain a
copy of the original form.
The database to which documents are mailed or pasted doesn't share an
alias with the original form.
The form contains an embedded OLE object or a subscription, and you
want documents to reflect any changes to the object.
You selected "Include in Search Builder" in the Form Properties box and
want the form's static text to be searchable.
The documents created with this form are stored as encapsulated
databases and mailed to cc:Mail users.
To store a form with each document
1. Open the form.
2. Choose Design - Form Properties.
3. Click the Form Info tab (Embedded image moved to file: pic15651.pcx).
4. Select "Store form in document."
5. Switch to Database Properties in the drop-down list on the Properties
box and select "Allow use of stored forms in this database."
Overriding the stored form
When a form is stored in a document, the form name is stored in a hidden
field called $Title. Additional information is stored in the $Info,
$WindowTitle, and $Body fields. To use a different form to display the
document, create an agent that deletes this stored form information and
designates another form to display the document.
Shared fields and documents with stored forms
If the form contains a shared field, that field is converted to a
singleuse field in the copy of the form that is actually stored in the
document. This ensures that if a copy of the document is stored in a
database that does not contain the shared field definition, the field can
still be used. In the original form, the field is still defined as shared.
Form formulas
To override the default form selection, write a form formula for a
particular view. For example, you can write a form formula that uses one
form to display all fields when a user edits a document and a different
form that resequences or omits fields when a user reads a document. Since
form formulas apply only to a specific view, documents created in other
views do not use the form formula.
Designating a default form for a database
1. Open the Form Properties box.
2. Click the Form Info tab (Embedded image moved to file: pic22312.pcx).
3. Select "Default database form."
Alternatives to storing forms
As an alternative to storing the form in a document, you can use the
LotusScript Send method to design a form you can mail along with a
document. This ensures that the database will have the correct form to
display the document but won't need to store the form with each document.
For more information on using LotusScript to mail forms with documents, see
the Programming Guide.
pic15651.pcx
pic22312.pcx
