sqlledger.txt

`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&level=N  
ew%20Window&login=[username]&timeout=10800&sessionid=[timestamp]&js=1&duplic  
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.gz. 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  
  
  
`