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,
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
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
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.
to post comments)