On Wed, Dec 19, 2012 at 3:56 AM, Ullmann d.o.o.
<..hidden..> wrote:
Hello mailing list.
In the Debian Wheezy rep. is still the version 1.3.18-2.
When reading this: http://ledgersmb.org/topic/security-reports
I get a bit worried.
Shoud I stay or should I go now ..... :D
Is someone taking care of that?
I don't know if that security fix has been backported to the .deb. I hope so. However, to explain what was actually going on here.
Jame, did this get backported there? Or should I send a fix to this user?
In LedgerSMB 1.2 and below, there was no hard enforcement of permissions (this was documented in our manual as a shortcoming, and a behavior we inherited from SQL-Ledger). Instead permissions were largely a matter of hiding options in the user interface. An enterprising individual with login access could thus obtain essentially all access to the application with the possible exception of user management.
in 1.3 we tackled this problem by pushing most permissions enforcement to the database. In 1.3 thus permissions are enforced strictly, usually by the database engine. This has some advantages including consistent enforcement across applications and the fact that this allowed us to relatively quickly retrofit a codebase which was not designed for security with some real security controls.
The problem occurred with the defaults table, which stores settings for the current company. The problem is that users routinely require read permission to the entire table and write permission to significant portions of the table. Because this is not well controlled, some enforcement needs to be done on the middleware end for now (this will probably change in 1.4). However, this component was omitted.
What this means is that if the security issue still affects your version, another co-worker with login access but not administrative access could tamper with some settings. In most cases, the worst that can happen is a bit of embarrassment (tampering with the company name sent out on invoices, for example), but there are two other slightly more severe consequences.
The first is that in some configurations, someone could turn off reversal enforcement and then start deleting invoices. This might be done to cover embezzlement or the like. Out of the box this isn't a danger because the db permissions are inadequate to delete any transactions, but if you go through the action of making this work and then revert to enforcing transaction reversal, there is additional risk. Note that audit trails can no longer be disabled in LedgerSMB 1.3 nor can they be deleted by users with our standard permissions.
The second is that some people live in places that require that all invoices are issued in series, with no gaps. Because someone can tamper with the next invoice number to be issued, this can cause regulatory headaches if you live in such a place.
I can send you a fix if you need it. It is a relatively simple and non-intrusive change to the code. However it is relatively minor in the sense that a disgruntled employee can probably find more effective ways of hurting your business, and unless you put some effort into it, it can't be used to hide embezzlement from the owners.
Best wishes,
Chris Travers