FYI: Just in case it effects you...


-----Original Message-----
From: John Eisenschmidt []
Subject: Advisory: Lawson Financials RDBMS Insecurity

|             Advisory: lawson001                                       |
|            Author(s): John Eisenschmidt <>     |
|                       George Lewis <>                |
|         Release Date: December 02, 2002                               |
|               Vendor: Lawson                                          |
|          Application: Financials (possibly others)                    |
|    Affected Versions: 8.x Environment                                 |
|   Affected Platforms: Solaris (possibly others)                       |
|   Affected Databases: Oracle (possibly others)                        |

Lawson Financials does not adequately secure data held in third-party
relational databases.

Lawson Software was founded in 1975 by Richard Lawson to develop
turn-key accounting and business systems. Depending on the platform,
Financials was originally written in either RPG or COBOL. All data was
stored in a proprietary flat file database called LADB.

The Lawson Applications (including Financials) run in an abstraction
layer called "the environment". The purpose of the environment is to
present information in a uniform manner regardless of the host operating
system.  The current 8.0 environment supports the following operating
        -Digital Unix/Tru64
        -Sun Solaris
        -Windows NT/2000

Several years ago, the environment was retrofitted to integrate with
popular third-party relational database. These include:
        -IBM DB2/UDB
        -Microsoft SQL Server

As of the release of the 8.0 environment, Lawson only supports the use
of a third-party relational database for production systems.

For the sake of brevity, this paper will only make specific reference to
a Lawson 8.0 environment installation on Sun Solaris with Oracle as the
repository. It is likely, however, that the issues raised here will more
than likely pose the same risks to other Unix variants and Windows.

Detailed Description
There are three standard ways to configure Lawson to work with a
third-party RDBMS:

        1) Oracle database authentication
        2) Operating system authentication with a single Lawson user name
        3) Operating system authentication with multiple Lawson user names

Setup #1 employs a single username and password for all transactions
within the database.  This username and password are stored in a
world-readable text file called the "capital <database> file":

        bash-2.03$ ls -l [A-Z]*
        -rw-rw-rw-   1 lawson   lawson       106 Jun 11 12:10 IBM
        -rw-rw-rw-   1 lawson   lawson       123 Jun 11 12:10 INFORMIX
        -rw-rw-rw-   1 lawson   lawson       272 Jun 13 08:40 ORACLE
        -rw-rw-rw-   1 lawson   lawson       124 Jun 11 12:10 SYBASE

As you can see, the default permission is 666 (world readable), and
ownership defaults to group lawson. All users of Financials must be a
primary member of group lawson, which means any user with shell access
can see the contents of this file. Shell access is required for using
the Lawson.Insight Desktop (LID) interface. Please note: the default
permissions on this file can be changed to 400, and ownership of the
file given to root, however this is not suggested anywhere in the
install documents, nor is it mentioned by the Lawson certified installer
required to certify your installation.

Once an unprivileged user obtains this password, they can easily
establish a connection to the database through a connector like ODBC or
JDBC. Since the lawson user is the database owner, these credentials
make it possible to read, alter, or destroy the database.

Setup #1 tends to be the preferred configuration method by Lawson
installers, despite the fact that the Lawson "Oracle Setup and Tools
Guide" (version 8.0.2, published May 2002) reflects that this is not a
good method to use (page 41). NOTE: The text is not reproduced here due
to Lawson's copyright.

Setup #2 requires that Oracle is setup to use the operating systems'
authentication mechanism. This method utilizes a single account, which
still reflects the lack of database auditing and logging as mentioned
above. This method is more secure than the previous #1 because the
password to the single account is not available in the world-readable
text file. If this single password is compromised, the system remains

Setup #3 has an advantage because user level auditing and logging
is actually viable since users would have unique accounts.  It has
a disadvantage because the user, by knowing their own username and
password, can connect to the database via a connector with these

Financials requires that each user account has full DML rights
(SELECT, INSERT, UPDATE, DELETE) to all objects in the Lawson schema.
In effect, the database is left wide open to any of these users.
The upside is that the audit trails in the database should have
record of any malicious user activities, which Financials' internal
auditing does not provide.

Several important facts should be noted about setup #3:
        -More time is required to setup this configuration, since
        accounts must be created both in the OS and the database.
        -Lawson's Global Support Center freely admits their lack of
        experience with this configuration.
        -This configuration requires that the Lawson Transaction Manager
        (LATM) is disabled--mitigating the connection pooling feature.
        -Database licensing fees are the same as setup #1 and setup #2.

Any system acting as Lawson Financials database server must be
properly protected due to flaws in Financials' security architecture.
The system should be configured to only allow appropriate hosts like
IOS Remote (Lawson's web front-end), or database administrators to connect.
Accomplishing this may vary by platform, but could include a firewall,
virtual private network, or ACLs in the database itself.

Since the username and password are stored as plain text in setup #1, it
is not recommended that this configuration be used under any
circumstances, even after changing the permissions to 400.

While setup #2 will allow you to use LATM and perform connection
pooling, from a security standpoint it is still highly recommended that
setup #3 is implemented for production installations of Lawson
Financials. The ability to perform granular auditing at the database
level is critical to any financial system.

Finally, the authors do not feel that setup #3 goes far enough to
protect critical financial data, but is simply a first step. Attempts to
further secure the data at the database level are met with application
errors from Financials. Only through additional development resources
can many of these defects be corrected, and while Lawson has owned-up to
many of these problems and promised they will be fixed in future
releases, their remediation has not been forthcoming.

Vendor Response
This advisory was sent to Lawson on 25 November 2002, with an
invitation for them to respond in writing by midnight of the release
date. Any response made by them would be included in the published
version of this paper.

The Lawson Global Support Center did acknowledge receipt of our
invitation the same day it was sent, but did not choose to respond.

Since most of the issues contained in this paper can be found in Lawson
documentation, or have been reported to the Lawson Global Support Center
and not remediated in a timely manner, the authors felt that giving the
vendor one week to respond was sufficient.

Several Lawson experts were asked to review a draft of this paper and
comment on it. The authors would like to thank them for volunteering
their time, and for providing such useful feedback:

        Mike Corbet
        Rory Flood
        John Henley
        Jason Largen
        Chris Martin
        Kwane McNeal
        Yatrik Shah
        A special thanks to Eddi Staffini, who works too much.

Legal Notice
Copyright 2002 John Eisenschmidt and George Lewis.

The information in this advisory is believed to be true. The opinions
expressed here are those of the authors, and not their respective
employers. The authors are not liable for any damages caused by direct
or indirect use of the information contained herein.  The authors bear
no responsibility for the content or misuse of this advisory or any

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.