Hi all; I have received many requests from security professions responsible for the security of Linux distros to move the full disclosure ahead. Now that I am reasonably sure that the full scope of the problem is known and fixed in the fix that Chris Murtagh and myself put together, it has been released. Also, the maintainer of the software has reacted in an extremely hostile manner even to the notion that this is a problem. He has not fixed the matter when we brought it up privately, nor has he fixed it when we alerted the public to the existence of a problem. Nor has he even expressed a substantive willingness to work with us to fix the problem. All versions of SQL-Ledger from 2.4.4 to the present (2.6.17 as of this writing) are vulnerable. Versions prior to 2.4.4 are vulnerable to browser history exploits as the password is stored in the query string but these are not as serious as the current problem. The Problem: SQL-Ledger uses a fundamentally flawed approach to session authentication. When a user logs in, the password is checked, and if it matches what was in the users/members file, a session id is generated and handed to the web browser. The requirements for authenticating are simply that a cookie in the name of "sql-ledger-[username]" and the value of [timestamp], and that this value matches the "sessionid" value passed via the Get or POST operation. [username] is the username of the logged in user, and [timestamp] is the unix epoch timestamp. Additionally, a timeout value is set per user, and this is used to timeout sessions. The session id is not stored on the server, nor is it further checked for validity. However, at least in theory, it is required that the user be logged in (though some versions do not remove the user configuration files properly to make this a requirement). The Exploit: Therefore, for the main program, the following steps are required to gain access as any logged in user: 1) Create a cookie referencing the host running SQL-Ledger, the / path, the name of sql-ledger-[username], and the value of the unix epoch timestamp. 2) Go to a URL in a web browser such as: http://[hostname]/sql-ledger/menu.pl?path=bin/mozilla&action=display&lev el=N ew%20Window&login=[username]&timeout=10800&sessionid=[timestamp]&js=1&du plic ate=1&main=company_logo In this example, [hostname] is the machine running SQL-Ledger, [timestamp] is the value from your cookie, and [username] is the desired username. 3) That's it. If that were the only flaw, the situation would be bad enough. However, the administrative interface contains a similar flaw (most easily exploited by typing the http request directly into telnet) which can be used to list usernames. For this reason, anybody can list login names and attempt to log in as other users. One can also create new users with the ability to access the confidential accounting data in the database, and other administrative tasks. One could even delete the accounting databases. Impact: Malicious users could pin transactions on other users, so that embezzlement could be pinned on others, accounting data could be tampered with, and more. This problem essentially means that audit trails logins, and security controls cannot be trusted with this application. The Fix: Metatron Technology Consulting, along with Chris Murtagh have released a fix for this problem available at http://www.metatrontech.com/downloads/sql-ledger-fix-CVE-2006-4244.tar.g z. However, there does not appear to be a strong commitment from the software maintainer to ensure that this is upgrade safe and should be considered temporary. For this reason, we have also decided to offer a fork of this popular open source software from http://sourceforge.net/projects/ledger-smb/ which does come with that commitment. The fix involves the following things: 1) A new table is created in the database which tracks session ids. Session ids are tracked by login name, time issued, and value. The value is an md5 sum of a random number. A new cookie handles this session value transparently to the user. 2) Every page load checks the session cookie against the value stored in the database. 3) The administrative interface uses a similar process with a file-based server-side tracking system. Installing this fix requires modifying the database schema. Please see the documentation contained in it for further instructions. Also note that although the fix ought to affect all versions from 2.4.4 to the present, this was only tested on 2.6.15 and 2.6.17. Best Wishes, Chris Travers Metatron Technology Consulting begin:vcard fn:Chris Travers n:Travers;Chris email;internet:chris (at) metatrontech (dot) com [email concealed] tel;work:509-888-0220 tel;cell:509-630-7794 x-mozilla-html:FALSE version:2.1 end:vcard