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%00&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&path=bin/mozilla&action=edit_template&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