Home / os / blackberry
overtheledger.txt
Posted on 20 March 2007
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
