Security: Denial of Service Vulnerability in 1.3.20 and below

Submitted by Chris Travers on Mon, 07/30/2012 - 00:08

A security oversight has been discovered in LedgerSMB 1.3 which could allow a malicious user to cause a denial of service against LedgerSMB or otherwise affect the way in which certain forms of data would get entered.  In most cases we do not believe this to be particularly severe in the presence of internal process controls.  Users in some jurisdictions however may need to take this more seriously (see full details below).

Basic vulnerability characteristics

Login required: Yes
Complexity of Attack: Low
Impact: Can alter software settings in excess of authorization
Most likely impacts: Malicious employee could cause denial of service for some features and regulatory compliance problems
Impact Level: Low for most users, moderate for others
Who is not affected: Single user environments


Recommended Mitigating Measures

Proper internal process controls greatly mitigate the impact of this issue.

Patch Availability

A patch is available from the LedgerSMB team but it has not been fully regression tested.  It can be obtained by emailing and is scheduled for inclusion in 1.3.21.

Scope of Patch

This patch fixes the issue on the middleware level.  It has no impact on third party applications writing to the database directly.  It does not fix the problem on 1.2.x, and existing workarounds are insufficient to address the issue in 1.2.x.  If you are using 1.2.x your best option is to upgrade to 1.3.x.

Full Details

LedgerSMB stores many system settings in the database and many of these must be incremented by ordinary users, so permissions are widely granted to these setting tables.  A malicious user could craft a carefully formed URL and cause LedgerSMB to overwrite existing settings.   A few settings, however, are security-critical.   Because some invoice numbers, etc. are guaranteed to be unique, this could interfere with posting of transactions in an automated environment, and it could be used to ensure that password resets would lock users out of the system.  There were insufficient permissions checks on the routines which update system settings and so consequently, could overwrite existing values.  These settings range in function from email addresses where invoices are sent from, to the next invoice number, to password duration.  A malicious individual can thus change security-related aspects of configuration, and change the value for the next invoice to be generated.  This cannot be used to grant additional permissions to the user however.

Additionally in some locations invoices are required to be numbered in a gap-less way.  Some countries require this in order to help cut down on tax evasion. Because next invoice number settings can be overwritten, this problem can run users into regulatory compliance problems.  Users in areas which require gap-less numbering of financial documents need to treat this problem as more severe.


Chris Travers found the problem during work on forthcoming versions.