Type packetstorm
Reporter Chris Travers
Modified 2007-03-20T00:00:00


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:  
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:  
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