Hi all;
It has been brought to our attention that a number of security
vulnerabilities have been noted in SQL-Ledger. Several of these
affect earlier versions of LedgerSMB, and three hotfixes have been
released for problems that continue to affect the LedgerSMB codebase.
As always, we highly recommend testing all hotfixes before applying
them to a production environment.
Hi all;
The LedgerSMB development team has found an SQL injection issue in
LedgerSMB 1.2.24. Because this issue stems from our common SQL-Ledger
heritage, it affects all versions of LedgerSMB and has been confirmed
in SQL-Ledger 2.8.33. We contacted Dieter when we initially
discovered this and now three weeks later it is doubtful when this
will be fixed on his side (his last communication said it was likely
to be at least a few more weeks from present with no committed
timeline). It is expected that when SQL-Ledger 2.8.34 is released it
Affects versions:
SQL-Ledger 2.8.33 and lower
LedgerSMB 1.2.24 and lower.
Both programs have vendor fixes available in the form of new, patched
versions. These have been out for over a week with appropriate
advisories, with users having time to upgrade.
Files affected: LedgerSMB/RP.pm for LedgerSMB and SL/RP.pm for SQL-Ledger.
CVE-2009-3583 refers to a security vulnerability in SQL-Ledger (and
presumably some offshoots, including early versions of LedgerSMB)
whereby one can include arbitrary Perl code.
All versions of SQL-Ledger 2.x are presumed vulnerable. At least my
experience with SQL-Ledger suggests that the relevant code has not
changed significantly since at least 2.2.0.
All versions of LedgerSMB lower than 1.2.0 are vulnerable. 1.2.0 is
the first version that is not vulnerable.
One thing not noted in the security advisory or the full disclosure
email is that there are mitigating features which can be used in
vulnerable programs (SQL-Ledger, unpatched LedgerSMB) to mitigate,
though not eliminate, the risk of XSRF.
Current versions of SQL-Ledger and LedgerSMB have a session time out
option which can be set either by the administrator or by the user.
The session timeout value provides a window during which XSRF attacks
can happen. In environments where this is a risk (for example, not
including closed networks of POS terminals), this session timeout can
Multiple vulnerabilities: LedgerSMB
Synopsis: Two vulnerabilities announced in LedgerSMB for versions
prior to 1.2.15
Status: Corrected in version 1.2.15 and later (vendor fix available).
Impact: Resource exhaustion on server, arbitrary SQL command execution.
Other software affected: SQL-Ledger, all versions, and likely related software
Two vulnerabilities have been recently discovered in LedgerSMB which
have been patched in version 1.2.15 and later.
Severity: Critical
Effect: Compromise of FInancial Data, deletion of audit trails,
alteration of system settings, disclosure of confidential information
possible in some setups.
Affected products: LedgerSMB 1.0.0-1.2.7 , SQL-Ledger 2.x (all versions).
1: SQL injection issue in invoice quantity field
2: SQL injection issue in sort field.
Solution to issue on LedgerSMB: Upgrade to 1.2.8.
Hi all;
We have been informed that SQL-Ledger 2.8.34 has in fact been released
patching the security hole previously reported in LedgerSMB 1.2.24 and
Lower. This is an SQL injection issue.
I haven't been been able to find a CVE listing for this yet. Secunia
has assigned this the id of SA45649 for LedgerSMB. I expect to send a
full disclosure email discussing the vulnerability in a week.
Similarly to the XSS finding, the main cause of this vulnerability is the inadequate
filtering of user input. As this is present throughout the complete codebase, it is likely
that there are similar vulnerabilities in other places.
The README file of LedgerSMB, a fork of SQL-Ledger says the following about SQL injections
in SQL-Ledger:
| LedgerSMB 1.2 has been through a detailed SQL injection audit of the codebase
| inherited from SQL-Ledger. As a result several vulnerabilities which were known
| to be exploitable were corrected along with hundreds of places where
Hi all;
Just backing up Tim here a bit.
In LedgerSMB 1.3, we decided to go to HTTP auth because of some
changes in the security architecture of the software. After looking
at alternatives, we concluded that http auth was likely to be the way
to go long-run. There are some constraints which preclude the use of
Digest authentication (negotiated and basic work OK, but the latter
really requires SSL).
