Re: [SL] SQL-Ledger vulnerability CVE-2006-4244

[Dr E. L. <el...@li...>]

Where the f***k is the evidence about censoring, not that looking at the
headers it is even remotely possible, and not that sourceforge would
stand for it. Other than you forging the headers, perhaps, again.

There has never anyone been banned, in particularily not for content,
your truly is an example of what they have put up with, and subscription
to this list is an automated process.

The very notion of a "software maintainer" is laughable, this is not a
collaborative piece that is "maintained" by Mr Simader, it is *HIS*
software. And all this nonsense you are writing is not giving you or any
one else ("the SQL-Ledger Community", my behind) any claim to it.

So, now that you have forked it, why don't you take the fork, yourself
and those other whiners and go where the sun don't shine.

As this list is populated by such terrible people, make your own and
don't forget to unsubscribe from this one.

And while you are at it, learn some English, its Security Professionals,
not Professions.

greetings from /dev/null

el

on 9/7/06 4:46 AM Chris Travers said the following:

> I have sent this to Bugtraq already.  I tried to send to this list but was
> censored.  
>
> I think that this information is impotant for people here to
> have.  I appologize for bundling this with the release announcement for my
> fork.  But I am afraid that otherwise it will not be reasonable to expect
> that all this information will reach the list.  I figure that if I am going
> to get banned for trying to get necessary information out, I might as well
> try to get as much out as possible.
> 
> 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
> <http://%5bhostname/>]/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
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sql-ledger-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sql-ledger-users

-- 
Dr. Eberhard W. Lisse  \        / Obstetrician & Gynaecologist (Saar)
el...@li... el108-ARIN /   *   |   Telephone: +264 81 124 6733 (cell)
PO Box 8421             \     / Please send DNS/NA-NiC related e-mail
Bachbrecht, Namibia     ;____/             to dns...@na...