Operating System:

[WIN]

Published:

22 February 2008

Protect yourself against future threats.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===========================================================================
             AUSCERT External Security Bulletin Redistribution

                          ESB-2008.0183 -- [Win]
       Potential security issue with the Execution Control List and
              Notes signatures on Java applets in Lotus Notes
                             22 February 2008

===========================================================================

        AusCERT Security Bulletin Summary
        ---------------------------------

Product:              Lotus Notes 8.0
                      Lotus Notes 7.0
                      Lotus Notes 6.5
                      Lotus Notes 6.0
Publisher:            IBM
Operating System:     Windows
Impact:               Provide Misleading Information
Access:               Remote/Unauthenticated
CVE Names:            CVE-2008-0862

Revision History:     February 22 2008: Added CVE Number.
                      February 21 2008: Initial Release

- --------------------------BEGIN INCLUDED TEXT--------------------

Java applet signatures and the Execution Control List

Technote (FAQ)
 
Question

David Gloede contacted IBM Lotus to report a potential security issue 
with the Execution Control List (ECL) and Notes signatures on Java applets.
 
Cause

The Execution Control List (ECL) enables administrators and users to 
protect their data against the threats of e-mail bombs, viruses, Trojan 
horses, and unwanted application intrusions. The ECL provides the mechanism 
for managing whether such programs or code should be allowed to execute 
based upon a Notes signature. In this specific situation, it has been 
determined that an unsigned applet would be signed when acted upon.

In order for an attacker to successfully exploit this vulnerability, the 
following must be accomplished:

For the purposes of this example the following are defined:
- - Attacker (original sender)
- - User 1 (original recipient - Notes User)
- - User 2 (recipient of forwarded message - Notes User)

(1) Attacker must create a Java applet and send it to User1 over the 
    Internet. At this point, the Java applet does not have a Notes 
    signature. If ECLs are properly configured (that is, Default and No 
    Signature set to "No Access") an Execution Security Alert (ESA) will 
    be generated when the document is opened by User1.

(2) User1 must forward the mail using Lotus Notes to User2. The previously 
    unsigned applet will now be signed by User1 using Notes signatures.

(3) At this point, User2 must have the "Enable Java Applets" option enabled 
    within User Preferences

(4) Additionally, the ECL of User2 must allow User1 proper rights to 
    execute Java

(5) If User1 is trusted to sign Java applets, then this Java applet would 
    execute according to the rights assigned within User2's ECL.
 
Answer

This issue was reported to Quality Engineering as SPR# TMDS6W826S and 
SPR# TMDS6W82A5.


Suggested Workarounds

There are two options that can be taken to prevent this potential issue.

Option #1: Disable the setting for "Enable Java Applets"
a. From the Lotus Notes client File menu, select 
   File-->Preferences-->User Preferences
b. On the Basics tab, under Additional Options
c. Deselect "Enable Java Applets"
d. The result is that no Java Applets will be allowed to execute within 
   Lotus Notes.

Note: If your organization does not develop Java applets for use within 
Notes database applications (NOT Java agents, which run under the rights 
assigned to Workstation security), then there is no need to enable Java 
applets within Notes.

Option #2: Use a trusted signature for all Java Applets
First, you must create a Notes ID file that will be used to sign Java 
applets. It is recommended that this ID file not be assigned to an 
actual user . It should be registered as an application signing ID 
(for example: "Java Applet Signature" or "xxx Application Signing )

Next, the users ECLs must be updated. This can be done using a policy or 
on an individual basis.

To manage the ECL for a all users
The ECL can be managed centrally by using the Administration ECL found in 
the Security Policy.

1. Open the Domino Directory and go to the Policy section.

2. Choose the Security Policy and navigate to the "Execution Control List" 
   tab

3. Edit the Admin ECL to make any necessary changes to the "Java Applet" 
   section.

4. Add your new trusted signature name to the "When applet is signed by:" 
   list by clicking Add, enter the name trusted signature, and then click OK.

5. Select the signature name you just added and enable the types of access 
   you want

To learn more about the Administration ECL and how to manage it, refer 
to "Deploying and updating workstation ECLs" and "the Administration ECL" 
topics discussed in the Domino Administrator Help.



To change the ECL for a single user.

1. Select File -> Security -> User Security.
(Macintosh OS X users: Select Notes -> Security -> User Security.)

2. Select "What Others Do" and then select "Using Applets".

3. The "When applet is signed by:" list should contain only signature 
   names that are fully trusted.

4. Add your new trusted signature name to the "When applet is signed by:" 
   list by clicking Add, enter the name trusted signature, and then click OK.

5. Select the signature name you just added and enable the desired access 
   types.

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

        http://www.auscert.org.au/render.html?cid=1980

If you believe that your computer system has been compromised or attacked in 
any way, we encourage you to let us know by completing the secure National IT 
Incident Reporting Form at:

        http://www.auscert.org.au/render.html?it=3192

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
===========================================================================

-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQCVAwUBR746uCh9+71yA2DNAQIZhgQAiGM4DugbHbQuVZT8dkAG6otJ/6MtriK2
/UDV6bSNPjqFkJSP6DTzvhicAGqbwXDAuv0BZLD6cBRZz5phWBbaZnitqEGtKkNv
ReSw/n5nbmlgs9+isa/vaPztDHFy2Ha+RNbYgQ/y3mWUfh0isXHWz9MkD1+IUOWY
sV3BmWS9BvE=
=Lf64
-----END PGP SIGNATURE-----