SQL-Ledger and LedgerSMB: a study in security reporting [LWN.net]

March 21, 2007

This article was contributed by Jake Edge.

Accounting information is the kind of data that most organizations would want to keep private; it is also information that attackers might be most interested in. Because of that, security vulnerabilities in accounting packages require high visibility and prominent announcements so that users can take the appropriate steps to safeguard their data. Two related accounting systems, SQL-Ledger and LedgerSMB provide an interesting contrast in approaches to security reporting.

SQL-Ledger is a GPL-licensed accounting system first released in 1999; it has a large feature set and a sizable number of happy and loyal users. It is a web-based program, written in Perl that uses an SQL database to store the information. The original intent seems to be a system that lived behind a firewall and was not exposed to the Internet; most of the vulnerabilities reported recently have a much reduced impact behind the firewall. In fact, buried at the end of the FAQ, SQL-Ledger recommends using the web server authentication mechanisms (presumably HTTP Basic Auth for Apache) on top of those provided by SQL-Ledger.

SQL-Ledger is tightly controlled by its creator, Dieter Simader, and he has not encouraged a developer community to spring up around the system. This has caused some users to become frustrated with the pace of development; it doesn't help that the suggested way to get features added more quickly is to pay Simader's company to develop them. In addition, the documentation, user forums and wiki are only available to those who pay for them. There is nothing inherently wrong with doing things this way, but it is quite different than the way most GPL projects operate.

The project continued in this manner for quite some time until a reported session hijacking issue was not handled quickly by Simader. Another user mentioned that the issue had been known for a lot longer as they had reported it nearly a year earlier and, though there had been several releases in the interim, no fix had been made. This incident led directly to the September 2006 fork of the SQL-Ledger code as the LedgerSMB (SMB for 'small-medium business') project.

The LedgerSMB developers have created a project that operates the way open source developers expect, with open documentation, a public source code repository and a willingness to accept patches from anyone interested. They have also been doing an informal security audit of the shared codebase and coordinating security releases with SQL-Ledger. They have released a number of detailed vulnerability reports on the Bugtraq mailing list that cover security updates for both projects.

Visiting each project's homepage is very instructive with regards to the security updates. The SQL-Ledger page makes no mention of updates; one must follow the "What's New" link to see the updates and the descriptions make no mention of the security implications of the release. A user could easily be lulled into thinking that "added %00 check for login to trigger an error" is just a run-of-the-mill bug fix rather than a fix for an arbitrary code execution and authentication bypass bug as described in the report.

The LedgerSMB site, on the other hand, has its news listed on the front page and calls the most recent security release (1.1.10) a fix for "a serious security hole." The users and announce mailing lists both have detailed reports about the problem whereas the SQL-Ledger public user mailing list makes no mention of the new release. One presumes and hopes that the users who have purchased support get some kind of notification from DWS Systems (Simader's company), but the non-paying users need to pay close attention to Bugtraq (or the LedgerSMB site).

In many ways, the contrast between the two mirrors the contrast between how open source and proprietary software projects handle security issues. One disseminates the information far and wide while the other treats it as a public relations black eye and obscures it. DWS Systems is presumably trying to protect its income stream but, by doing it in the way it has, it appears to have alienated a segment of its user base which is now directly competing with the company. Had Simader been more responsive to those issues, there very well might not be a competing project. It will be interesting to see which approach works better in the long term or if both thrive equally.

(Log in to post comments)

From a user...

Posted Mar 22, 2007 1:33 UTC (Thu) by dskoll (subscriber, #1630) [Link]

We purchased the SQL-Ledger manual about a year ago. It wasn't bad and I wanted to help a developer of software we use extensively.

That being said: SQL-Ledger's code is absolutely horrible. It's truly putrid. Nevertheless, from an end-user point of view, it works quite well, and it would be a waste of our time to try to fix it up.

We recently switched to Ledger-SMB, and I'm hopeful the code quality will improve. I gather that the Ledger-SMB developers' immediate goal is simply to clean up the worst of SQL-Ledger, but I really hope they give it a thorough rewrite. It should be written using a proper framework like Catalyst; all existing code should be chucked out and only the database schema retained.

This would never happen with only one project, but now that there's a competing project... maybe my dream will come true.

From a user...

Posted Mar 24, 2007 18:04 UTC (Sat) by ccyoung (guest, #16340) [Link]

not only the code - the UI is imho unusable.

those who use my sites, highly interactive and esthetically pleasing, were horrified when I showed them SQL-Ledger as an alternative.

$900 for a programming manual. $200 for users manual. I wish someone would give me $200K so I could get a good F/OSS accounting system out there.

From a LedgerSMB Developer

Posted Mar 31, 2007 18:01 UTC (Sat) by einhverfr (guest, #44407) [Link]

I would suggest joining the LedgerSMB community if you are looking for an alternative. At the moment the code and UI are fairly similar but this is starting to change. LedgerSMB 1.2.0 will be released on Monday and will be the last of our releases where we merge security changes and work done elsewhere into the LSMB codebase. From here on out, we will be re-engineering the entire application in place.

I would suggest that one part of the problem with the UI is that the code is horrible, as others have suggested. Hence modernizing the UI is not really possible with the current codebase. While our user interface may not change drastically until 2.0, we are putting in place now the framework to make this sort of change feasible. In fact, after 2.0, it will be quite possible to re-theme the application however one would like using a combination of CSS and templates.

Our new architecture is more object oriented, more modular, MVC-like, etc. and hence will allow for better separation of interface from mechanism. It will also allow for full user-level security to be enforced (which the SQL-Ledger codebase does not).

One final comment. SQL-Ledger 2.8.0 was released yesterday. One of the surprises was an apparent license change (no longer GPL).

LedgerSMB rewrite

Posted Apr 8, 2007 20:59 UTC (Sun) by einhverfr (guest, #44407) [Link]

We actually have begun the process of a complete rewrite of LedgerSMB. Although we have opted not to use Catalyst or other ready-made frameworks, we have spent a great deal of time evaluating them. We are, however, making increasing use of CPAN modules.

By 2.0, LedgerSMB will be entirely MVC-oriented, but we will be doing a few things differently than other MVC frameworks:

1) The entire data model (or nearly all of it) will be fully encapsulated in the database system. We have opted to do ORM-stuff by mapping object methods to stored procedures, and not doing direct table mapping. This allows us to ensure that we have an ideal database structure. Our current approach allows for dynamically associating such methods, which makes custom reporting something that is really easy.

2) Security can be managed easily via database access controls

3) We make use of existing standards wherever possible (so the templates make use of PI tags extensively).

another SQL Ledger fork: LX Office ERP

Posted Mar 31, 2007 19:35 UTC (Sat) by einhverfr (guest, #44407) [Link]

In the LedgerSMB project, we looked at joining LX Office, OpenLedger, and one other fork I forget the name of. Unfortunately, of those, LX Office was the only one with any development activity and the fork was from a much older version (meaning getting existing users to be able to make it work for them was going to be far harder).

In the end, we chose to go our own separate way.

I suspect though that we may be the first credible threat to SQL-Ledger in a long time. We try to remain cordial, sharing security and bug reports where appropriate with Mr Simader, but we have found increasing hostilities towards our project (the apparent intent to move from the GPL being the most recent).

After about six months with the SQL-Ledger codebase, the work before us is to re-engineer the entire application, moving it to a new architecture, and preparing for a full UI redesign. We are also adding features in the mean time. 1.2.0 will be released on Monday and after that point, work will be largely aimed at removing the code from the current codebase.