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
|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.
A patch is available from the LedgerSMB team but it has not been fully regression tested. It can be obtained by emailing firstname.lastname@example.org 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.
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.