Security: Denial of Service Vulnerability in 1.3.20 and below
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 absence of poor internal process controls. Users in
some jurisdictions however may need to take this more seriously (see
full details below).
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 in some
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 firstname.lastname@example.org and is scheduled for inclusion in
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 gapless 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 gapless numbering of financial
documents need to treat this problem as more severe.
Chris Travers found the problem during work on forthcoming versions.