Full Disclosure: Arbitrary execution vulnerability in SQL-Ledger and LedgerSMB

Hi;

Affected versions:
LedgerSMB < 1.1.10 (but see below), current is 1.1.11
SQL-Ledger < 2.6.27 (but see below). Current is 2.6.27

Effects: Arbitrary code execution (both products) and authentication
bypass (SQL-Ledger only).

We have discovered yet another major security issue in both SQL-Ledger
(for affected versions, see below) and LedgerSMB (<1.1.10, but see
below). The problem exists because the login input variable is not
properly checked, and the software runs a perl script derived from the
login name. If the script completes and a password is set, the password
is checked. In LedgerSMB, an additional check is made against a session
table, which will cause the script to go no further, but in SQL-Ledger,
this can also result in authentication bypass.

Affected Versions:
Unfortunately, both projects suffered problems with their security
fixes. The LedgerSMB team failed to update their version strings
properly so 1.1.10 will still display 1.1.9 as its running version.

To differentiate, you can use md5sum on the LedgerSMB/Form.pl
c9621e0ed0fd633663e1be3c6d5b08c4 ledger-smb-1.1.10/LedgerSMB/Form.pm
c311f02eaeee9e0638cbe08a650ab86d ledger-smb-1.1.9/LedgerSMB/Form.pm

The SQL-Ledger case is probably worse. The initial release of 2.6.27
included an inadequate and broken fix. A new security fix was issued
later that day, but it is unclear when all mirrors were updated, and
users who downloaded that version cannot be sure that they got one that
was not vulnerable. The initial security fix offers little safety:
authentication bypass and arbitrary code execution are still largely
possible though perhaps not at the same time (as they were before).

The following md5sum's reflect whether 2.6.17 was patched or not:
e97dc79c171a45bb794e253f94caef49 is unpatched
2a2dc05d5ac7085bd9e6aaa7098e1bf1 is patched.

How the exploit works:

SQL-Ledger and their derivatives (including LedgerSMB < forthcoming
1.2.0), store login state information in a machine-writable perl script
in a configurable location (by default users/). This file is read on
each page load and is named [username].conf. This file contains a hash
definition which is then used to validate the user's authentication
token. No provisions are taken to prevent directory transversal prior
to these fixes, however.

One can form a URL like:
http://localhost/sql-ledger/am.pl?login=../../../home/user/foo.pl&#37;00&amp;action=add_department

This causes the web server to execute …/…/home/user/foo.pl (the %00
gets translated into a terminating NULL) and will then either allow
access (in SQL-Ledger < 2.6.27) or provide an error. In the faulty
versions of 2.6.27 and vulnerable versions of LedgerSMB, it will still
execute the script however.

The faulty version of SQL-Ledger have a major oversight, however, that
lends well to testing. Because the only check is on the NUL and not on
the signs of directory transversal, you can test the authentication
bypass and get access to sensitive configuration (including obfuscated
but unencrypted database passwords and application password hashes). A
sample URL for this is:
http://localhost/sql-ledger/am.pl?login=../sql-ledger&amp;path=bin/mozilla&amp;action=edit_template&amp;file=users/members

This works because there is usually a Perl script named sql-ledger.conf
in the directory above where these scripts are normally stored. So the
username forces the execution of that script, doesn't find a password,
and so allows the user in. Lovely…

Best Wishes,
Chris Travers