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

Hi all;

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

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...

I'm astounded by the thundering silence. For the time being I've simply
shut down postgres - I'm sure this is not an option for most users of
SL.

Chris: You keep saying that you are being censored, but I keep getting
your emails from the list. I don't get that?

Dieter: Please tell us this is not as serious as Chris says it is, or
else verify that his fix works. (or incorporate it?).

thanks guys... either way, I'm grateful that users of this very useful
piece of open source software at least hear about security issues.

David.



On Wed, 2006-09-06 at 19:46 -0700, Chris Travers wrote:
> Hi all;
> 
> 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
> 

I have downloaded the fix from

http://www.metatrontech.com/downloads/sql-ledger-fix-CVE-2006-4244.tar.gz

and am in the process of applying it. I can say for sure that it is not 
as simple as copying the files over top of your existing files as is 
suggested in the INSTALL file.

I have gotten the administrative interface fix working, but needed to 
make some major changes to the distributed files first:

In the sql-ledger/admin.pl file:

44c44
< eval { require "ledger-smb.conf"; };
---
 > eval { require "sql-ledger.conf"; };

In the sql-ledger/bin/mozilla/admin.pl file:

19,20c19,20
< use LedgerSMB::Form;
< use LedgerSMB::User;
---
 > use SL::Form;
 > use SL::User;
27a28,29
 > $form->init();
 >
31c33
< $form->{stylesheet} = "ledger-smb.css";
---
 > $form->{stylesheet} = "sql-ledger.css";

I also replaced all of the references to "LedgerSMB" with "SQL-ledger" 
including the cookie names. This was not required to get things working, 
but I do think that prior to releasing this fix, this should have been done.

Hope this helps,

Andrew

david wrote:
> I'm astounded by the thundering silence. For the time being I've simply
> shut down postgres - I'm sure this is not an option for most users of
> SL.
>
> Chris: You keep saying that you are being censored, but I keep getting
> your emails from the list. I don't get that?
>
> Dieter: Please tell us this is not as serious as Chris says it is, or
> else verify that his fix works. (or incorporate it?).
>
> thanks guys... either way, I'm grateful that users of this very useful
> piece of open source software at least hear about security issues.
>
> David.
>
>
>
> On Wed, 2006-09-06 at 19:46 -0700, Chris Travers wrote:
>   
>> Hi all;
>>
>> 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
>>
>>     
>
>
> -------------------------------------------------------------------------
> 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
>
>   

david wrote:
> I'm astounded by the thundering silence. For the time being I've simply
> shut down postgres - I'm sure this is not an option for most users of
> SL.

Personally I've been astounded by the silence since this came to light on the list a couple of weeks ago. 
I mean very astounded. Either its a problem or it isnt.
Whatever, my accounts are on an internet facing server and silence is not the thing

> Chris: You keep saying that you are being censored, but I keep getting
> your emails from the list. I don't get that?

I think maybe more than one email address is the thing.

> Dieter: Please tell us this is not as serious as Chris says it is, or
> else verify that his fix works. (or incorporate it?).

2'nded - Dieter please comment on this situation

thnx

david wrote:
> I'm astounded by the thundering silence. For the time being I've simply
> shut down postgres - I'm sure this is not an option for most users of
> SL.
> 
> Chris: You keep saying that you are being censored, but I keep getting
> your emails from the list. I don't get that?
> 
> Dieter: Please tell us this is not as serious as Chris says it is, or
> else verify that his fix works. (or incorporate it?).
> 
> thanks guys... either way, I'm grateful that users of this very useful
> piece of open source software at least hear about security issues.


:)  Thundering silence.  Because the issue at hand is technical enough 
that most average users don't understand it.

The case here is only PARTIALLY an SQL-Ledger problem (IMO).  Yes, the 
authentication process can be made stronger.  But show me an application 
where that is not the case.

THe problem with the cookies is NOT an SQL-Ledger specific problem.  The 
way the info in the cookies can be used on the URL is.  EVERY browser 
out there will have the same flaw with the cookies.  So how is Dieter to 
fix that?  Does he contact Microsoft, Mozilla, KDE, etc. and submit a 
patch for their browsers?  Or does he focus on the SL specific problems.

The fact that authentication details are placed on the URL is a bigger 
issue though.  On the otherhand, let's not forget the way SL works.  You 
can interact with it from the command line.  Without a browser.  I 
suspect these "session" fixes being proposed would utterly break that 
functionality, seeing as Sessions are web based.

I do not see a disregard for this issue at all.  It has been discussed 
on the list.  Dieter has stated where he thinks the problem to be, and 
that the issue is browser and/or environment related.  Chris himself has 
pointed out a fix for the issue that does not involve code - put the SL 
sites behind SSL.  Or require .htaccess authentication.  Both of these 
are very simple solutions, and *could* be a recommeneded practice for 
running SL.  If an installer chooses not to use SSL or .htaccess, then 
it is their choice.  A simple non-coding solution that does not break SL 
functionality in the slightest, or introduce new potential bugs/security 
holes.

As for censoring, I don't see that happening at all.  What I DO see 
happening is a bit of MUCH needed list moderation.  You only have to 
read the messages from the past 2 weeks, and keep in mind the purpose of 
the list, to see why this is being done.

So a fork is taking place.  So be it.  This is the nature of open source 
- if you don't like the way it's being done, do it yourself.  But, most 
forks fail and/or are merged back into the original app.  This is not a 
case of the app being abandoned, so I don't see any forks succeeding for 
too long.  But I do wish the fork well as it's intent (at least 
initially) is respectable.  But until I see a distinct improvement (not 
to mention a release) I won't be changing my routines or software at all.

Shawn

On 9/7/06, Shawn <sg...@op...> wrote:
> The case here is only PARTIALLY an SQL-Ledger problem (IMO).  Yes, the
> authentication process can be made stronger.  But show me an application
> where that is not the case.

 Shawn,

 It's clear that you do not understand the severity of the design
flaw. There are very few apps that have this sort of problem. Web
based authentication can be made to be very secure (otherwise you
wouldn't have online banking), the current problem with SQL-Ledger is
that it is not secure at all.

> THe problem with the cookies is NOT an SQL-Ledger specific problem.

Wrong. The problem isn't that the system is using cookies for
authentication. The problem is that the cookie content is simply the
users name and a timestamp. The equivalent in the physical world would
be that to withdraw from the bank, all you need to do is provide them
with your name and the time of day without any verification that you
are who you say you are.

 For me to get access to any SQL-Ledger server all I have to do is
create a cookie (a trivial thing to do) called 'SQL-Ledger-shawn' and
give it a value which is the current unix epoch time. This completely
bypasses any credential verification done in the software. Clearly, a
big problem. To make matters worse, if I created a cookie called
'SQL-Ledger-root login' with the current timestamp, I could access the
admin script, which would give me all the user names and the ability
to change passwords, create accounts, delete datasets, etc.. So, in
this case, I don't even need to know the users login name.

> The  way the info in the cookies can be used on the URL is.  EVERY browser
> out there will have the same flaw with the cookies.  So how is Dieter to
> fix that?  Does he contact Microsoft, Mozilla, KDE, etc. and submit a
> patch for their browsers?  Or does he focus on the SL specific problems.

 Like I said, this is not a browser or a cookie problem, it is a
design flaw in the application, proof being that our patch solves the
cookie problem completely.

> I do not see a disregard for this issue at all.  It has been discussed
> on the list.  Dieter has stated where he thinks the problem to be, and
> that the issue is browser and/or environment related.

 And that is part of the problem. Dieter doesn't seem to understand
the flaw, while many others do.

> Chris himself has
> pointed out a fix for the issue that does not involve code - put the SL
> sites behind SSL.  Or require .htaccess authentication.  Both of these
> are very simple solutions, and *could* be a recommeneded practice for
> running SL.

 Using SSL does not proctect you from this design flaw in any way. A
.htaccess solution would be fine for some, provided that the
installation has only one account. If you have multiple accounts on
the same server, then you would need to change the code to get the
username from the authenticated user according to apache (and have
them sync with the members file).

Cheers,

Chris

Christopher Murtagh wrote:
> On 9/7/06, Shawn <sg...@op...> wrote:
>> The case here is only PARTIALLY an SQL-Ledger problem (IMO).  Yes, the
>> authentication process can be made stronger.  But show me an application
>> where that is not the case.
> 
>  Shawn,
> 
>  It's clear that you do not understand the severity of the design
> flaw. There are very few apps that have this sort of problem. Web
> based authentication can be made to be very secure (otherwise you
> wouldn't have online banking), the current problem with SQL-Ledger is
> that it is not secure at all.
> 
>> THe problem with the cookies is NOT an SQL-Ledger specific problem.
> 
> Wrong. The problem isn't that the system is using cookies for
> authentication. The problem is that the cookie content is simply the
> users name and a timestamp. The equivalent in the physical world would
> be that to withdraw from the bank, all you need to do is provide them
> with your name and the time of day without any verification that you
> are who you say you are.
> 
>  For me to get access to any SQL-Ledger server all I have to do is
> create a cookie (a trivial thing to do) called 'SQL-Ledger-shawn' and
> give it a value which is the current unix epoch time. This completely
> bypasses any credential verification done in the software. Clearly, a
> big problem. To make matters worse, if I created a cookie called
> 'SQL-Ledger-root login' with the current timestamp, I could access the
> admin script, which would give me all the user names and the ability
> to change passwords, create accounts, delete datasets, etc.. So, in
> this case, I don't even need to know the users login name.
> 
>> The  way the info in the cookies can be used on the URL is.  EVERY browser
>> out there will have the same flaw with the cookies.  So how is Dieter to
>> fix that?  Does he contact Microsoft, Mozilla, KDE, etc. and submit a
>> patch for their browsers?  Or does he focus on the SL specific problems.
> 
>  Like I said, this is not a browser or a cookie problem, it is a
> design flaw in the application, proof being that our patch solves the
> cookie problem completely.
> 
>> I do not see a disregard for this issue at all.  It has been discussed
>> on the list.  Dieter has stated where he thinks the problem to be, and
>> that the issue is browser and/or environment related.
> 
>  And that is part of the problem. Dieter doesn't seem to understand
> the flaw, while many others do.
> 
>> Chris himself has
>> pointed out a fix for the issue that does not involve code - put the SL
>> sites behind SSL.  Or require .htaccess authentication.  Both of these
>> are very simple solutions, and *could* be a recommeneded practice for
>> running SL.
> 
>  Using SSL does not proctect you from this design flaw in any way. A
> .htaccess solution would be fine for some, provided that the
> installation has only one account. If you have multiple accounts on
> the same server, then you would need to change the code to get the
> username from the authenticated user according to apache (and have
> them sync with the members file).
> 
> Cheers,
> 
> Chris
> 

Passing clear text passwords across the Internet is always wrong, so 
using a secure web server which requires the additional login to the 
https server first should be standard practice - it is for any system I 
configure. So using SSL WILL protect MOST of the users of SQL-Ledger - 
those that have the need to access their accounts across the Internet, 
that is.
If your SQL-Ledger server is not accessible from the Internet you have 
far less to worry about.

As you say it is when you have multiple accounts - ie a hosted 
SQL-Ledger application for a number of different companies that you have 
the main problem. That reduces the number of people affected.

Undoubtedly the problem should be fixed - but it does NOT affect all 
SQL-Ledger users, so I think some proper reporting of the vulnerability 
is required - currently it sounds like scare mongering - or does it just 
happen to coincide with this fork?

If any one need help setting up a secure web server let me know.

Regards

Trevor Hennion
http://www.infocentrality.co.uk

On Thu, 7 Sep 2006, Shawn wrote:

> :)  Thundering silence.  Because the issue at hand is technical enough
> that most average users don't understand it.

   Or, in the case of at least some of us, it's a non-issue. No one else can
get to SL on the internal network, and so far (7 years) no one's penetrated
the firewall.

   On multiuser installations, I believe that _all_ authentification checks
should be implemented for all applications that are shared among users or
the outside world.

Rich

-- 
Richard B. Shepard, Ph.D.               |    The Environmental Permitting
Applied Ecosystem Services, Inc.(TM)    |            Accelerator
<http://www.appl-ecosys.com>     Voice: 503-667-4517      Fax: 503-667-8863

On Thu, 7 Sep 2006, Shawn wrote:

> david wrote:
> > I'm astounded by the thundering silence. For the time being I've simply
> > shut down postgres - I'm sure this is not an option for most users of
> > SL.
> >
> > Chris: You keep saying that you are being censored, but I keep getting
> > your emails from the list. I don't get that?
> >
> > Dieter: Please tell us this is not as serious as Chris says it is, or
> > else verify that his fix works. (or incorporate it?).
> >
> > thanks guys... either way, I'm grateful that users of this very useful
> > piece of open source software at least hear about security issues.
>
>
> :)  Thundering silence.  Because the issue at hand is technical enough
> that most average users don't understand it.

It is technical and has to do with how a browser communicates with the
server.

If you can run a script to create a cookie, the very same way the login
process establishes a cookie, you basically establish a communication
between the browser and the server. All subsequent requests are therefore
trusted. I admit this authentication process is not very strong.

In any case a fix is on it's way to address this issue.


>
> The case here is only PARTIALLY an SQL-Ledger problem (IMO).  Yes, the
> authentication process can be made stronger.  But show me an application
> where that is not the case.
>
> THe problem with the cookies is NOT an SQL-Ledger specific problem.  The
> way the info in the cookies can be used on the URL is.  EVERY browser
> out there will have the same flaw with the cookies.  So how is Dieter to
> fix that?  Does he contact Microsoft, Mozilla, KDE, etc. and submit a
> patch for their browsers?  Or does he focus on the SL specific problems.
>
> The fact that authentication details are placed on the URL is a bigger
> issue though.  On the otherhand, let's not forget the way SL works.  You
> can interact with it from the command line.  Without a browser.  I
> suspect these "session" fixes being proposed would utterly break that
> functionality, seeing as Sessions are web based.
>
> I do not see a disregard for this issue at all.  It has been discussed
> on the list.  Dieter has stated where he thinks the problem to be, and
> that the issue is browser and/or environment related.  Chris himself has
> pointed out a fix for the issue that does not involve code - put the SL
> sites behind SSL.  Or require .htaccess authentication.  Both of these
> are very simple solutions, and *could* be a recommeneded practice for
> running SL.  If an installer chooses not to use SSL or .htaccess, then
> it is their choice.  A simple non-coding solution that does not break SL
> functionality in the slightest, or introduce new potential bugs/security
> holes.
>
> As for censoring, I don't see that happening at all.  What I DO see
> happening is a bit of MUCH needed list moderation.  You only have to
> read the messages from the past 2 weeks, and keep in mind the purpose of
> the list, to see why this is being done.
>
> So a fork is taking place.  So be it.  This is the nature of open source
> - if you don't like the way it's being done, do it yourself.  But, most
> forks fail and/or are merged back into the original app.  This is not a
> case of the app being abandoned, so I don't see any forks succeeding for
> too long.  But I do wish the fork well as it's intent (at least
> initially) is respectable.  But until I see a distinct improvement (not
> to mention a release) I won't be changing my routines or software at all.
>
> Shawn

I looked at the fix Murtagh and Travers submitted. It has the same
weaknesses it just makes it a bit harder.

He stores a session in the db and authenticates this with the cookie.
Basically what you have is this. If you get a hold of the session from the
db you can create a cookie and get in just the same way you can get in
now.

I would post a bit more about this but since they forked SQL-Ledger I let
them find out what else is wrong with it. It makes no sense to feed your
competition information they use against you. ;)

-- 
Dieter Simader    http://www.sql-ledger.com   (780) 472-8161
DWS Systems Inc.     Accounting Software       Fax: 478-5281
============ On a clear disk you can seek forever ==========

On Thu, 2006-09-07 at 13:59 -0400, Christopher Murtagh wrote:
> > The  way the info in the cookies can be used on the URL is.  EVERY
> browser
> > out there will have the same flaw with the cookies.  So how is
> Dieter to
> > fix that?  Does he contact Microsoft, Mozilla, KDE, etc. and submit
> a
> > patch for their browsers?  Or does he focus on the SL specific
> problems.
> 
>  Like I said, this is not a browser or a cookie problem, it is a
> design flaw in the application, proof being that our patch solves the
> cookie problem completely.
                  ^^^^^^^^^

This is simply not true... The patch simply moves the security
responsibility of existing sessions to rely on the strength of the
random number generator built into Postgres making it more difficult to
hijack a valid session. Saving the the session parameters into the
database does makes it impossible to forge sessions though. These two
things make this patch stronger than how SQL Ledger works now but it
doesn't "completely solve the problem". Oh, and the patch removes the
ability to log into SQL Ledger as more that one user from the same
browser.

There are other ways to solve the problem.

Also let me say that I have been in contact with Dieter off list and he
is working diligently on a more secure authentication system. I think
both of us agree that it won't be to simply adopt this patch though.

-- 
Tony Fraser
to...@sy...
Sybaspace Internet Solutions                        System Administrator
phone: (250) 246-5368                                fax: (250) 246-5398

On 9/7/06, Tony Fraser <to...@sy...> wrote:
> >  Like I said, this is not a browser or a cookie problem, it is a
> > design flaw in the application, proof being that our patch solves the
> > cookie problem completely.
>                   ^^^^^^^^^
>
> This is simply not true... The patch simply moves the security
> responsibility of existing sessions to rely on the strength of the
> random number generator built into Postgres making it more difficult to
> hijack a valid session. Saving the the session parameters into the
> database does makes it impossible to forge sessions though.

 Which is the problem I was referring to as being solved, and
actually, it doesn't make it 'impossible', but very unlikely,
especially if the communications are via encrypted channels (this is
where SSL would come in Shawn). The easiest vector of attack without
SSL is probalby to sniff packets from the client machine to the
server, but then again, if you can do that the session wouldn't be the
primary target, you could simply get the password. SLL drastically
lowers this risk, with the next attack being either key-capture or a
trojan of some sort.

> These two
> things make this patch stronger than how SQL Ledger works now but it
> doesn't "completely solve the problem". Oh, and the patch removes the
> ability to log into SQL Ledger as more that one user from the same
> browser.

 True, and this will be an inconvienece for the users who need to do
this for sure. However, we felt it was more important to secure the
vast majority of users who use a web based application under a single
role at a time.

 The sane way to fix this isn't through allowing multiple logins via
the same browser however.  The proper way would be to have a decent
role mechanism along with a more robust authentication scheme. Moving
SL to this would be a huge amount of work though, so I wouldn't expect
to see that anytime soon.

> There are other ways to solve the problem.

 That's the Perl motto 'TIMTOWTDI', and I agree 100%. Our fix was a
temporary one to stop the sever bleeding before we take the patient to
surgery since Dieter was doing nothing and had known about it for
months.

> Also let me say that I have been in contact with Dieter off list and he
> is working diligently on a more secure authentication system. I think
> both of us agree that it won't be to simply adopt this patch though.

 Good for him. You are a far more optimistic person than I if you feel
that Dieter is capable of delivering a secure solution. Good luck with
SL, if you ever decide to use LedgerSMB, we will be happy to have you
and to incorporate your feedback.

Cheers,

Chris

Tony,

> Also let me say that I have been in contact with Dieter off list and he
> is working diligently on a more secure authentication system. I think
> both of us agree that it won't be to simply adopt this patch though.

Agreed, but the patch is available immediately and does improve things 
considerably by not making it trivial to forge an identity cookie.

I'll actually be contributing further (on LedgerSMB, but you can pull down 
the code if you want) to this since I know that the PG random number 
generator isn't strong enough.  Generally, I do a combination of things:

1) Pick a random number and bitshift/modulo/log it by the User's ID and/or 
the unixtimestamp, which improves the randomness, as the session key;

2) Track the timestamp of last activity and last IP for each user, expiring 
the user if the timestamp ages over a preset value or the IP address 
changes subnets (or changes at all, if roaming_users is not permitted);

3) Require all four pieces of information (user_id, session key, timestamp 
and IP address) to be validated via secured stored procedure against the 
database (against tables the webuser has no access rights for) to load 
each page.

Short of requiring public key encryption or other sophisticated security on 
the client, the above is about as much as you can do to lock up a PHP 
application.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Dr Eberhard Lisse wrote:
> 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.
>   

I don't know if it's deliberate or not, but I have posted a fair number 
of questions to this list which have simply not shown up?

I don't have this problem with other Yahoo lists.  I had assumed that 
this list was somewhat moderated and perhaps my posts were being 
disregarded...  Not sure what moderator controls there are with Yahoo?  
Didn't think that anything I had previously posted was controversial, 
but perhaps...?

Ed W

on 9/7/06 9:59 PM Ed W said the following:
> Dr Eberhard Lisse wrote:
>> 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.
>>   
> 
> I don't know if it's deliberate or not, but I have posted a fair number 
> of questions to this list which have simply not shown up?

This is the most extraordinary rationale I have read in a long while.
And, if you don' know, don't tell.

> I don't have this problem with other Yahoo lists.  I had assumed that 
> this list was somewhat moderated and perhaps my posts were being 
> disregarded...  Not sure what moderator controls there are with Yahoo?  
> Didn't think that anything I had previously posted was controversial, 
> but perhaps...?

The list is on SourceForge. Maybe you sent your questions to Yahoo :-)-O?

As I said before, at the headers of your own email, the only delay is at
sourceforge when the message is passed to the outbound quque, which
given that they run gazillions of lists is instantaneous.

Received: from lists-outbound.sourceforge.net
(lists-outbound.sourceforge.net [66.35.250.225])
	by linux.lisse.NA (Postfix) with ESMTP id 10F94B82F5
	for <el...@ac...>; Thu,  7 Sep 2006 22:24:33 +0200 (WAST)

Received: from sc8-sf-list1-new.sourceforge.net (unknown [10.3.1.93])
	by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP
	id 0FEECFF13; Thu,  7 Sep 2006 13:24:29 -0700 (PDT)

Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91]
	helo=mail.sourceforge.net)
	by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43)
	id 1GLQ2I-0001ua-0u for sql...@li...;
	Thu, 07 Sep 2006 12:59:42 -0700

Received: from mail.wildgooses.com ([81.6.236.5])
	by mail.sourceforge.net with esmtp (Exim 4.44) id 	
	1GLQ2G-0001WE-Hy
	for sql...@li...;
	Thu, 07 Sep 2006 12:59:42 -0700

[...]

Received: from [127.0.0.1] (compaq.wildgooses.com [192.168.105.251])
	by mail.wildgooses.com (Postfix) with ESMTP id 240AA33EEB
	for <sql...@li...>;
	Thu,  7 Sep 2006 20:59:14 +0100 (BST)

Message-ID: <450...@wi...>
Date: Thu, 07 Sep 2006 20:59:06 +0100
From: Ed W <li...@wi...>
In-Reply-To: <44F...@li...>
X-Virus-Scanned: amavisd-new at wildgooses.com
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	Report problems to
	http://sf.net/tracker/?func=add&group_id=1&atid=200001
X-Mailman-Approved-At: Thu, 07 Sep 2006 13:22:32 -0700
Subject: Re: [SL] SQL-Ledger vulnerability CVE-2006-4244
X-BeenThere: sql...@li...
X-Mailman-Version: 2.1.8
[...]
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.13.7.2


To even *THINK* that it was technically possible, or sourceforge would
permit to censor a(n unmoderated) list defies comprehension.

No, actually, it doesn't. The Wannabe *KNOWS* he is not censored. He is,
after all, a Wannabe-Security-Expert now, since he can forge headers.
But why are they doing all of this. Ulterior motives come to mind.

el

-- 
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...

On 9/7/06, Trevor Hennion <tre...@th...> wrote:
> So using SSL WILL protect MOST of the users of SQL-Ledger -

  No, it will not. If the user can forge the credentials trivially (in
the case of the current SQL-Leger), adding encryption will not buy you
ANYTHING. Adding SSL will only be a benefit once some sort of proper
authentication mechanism is in place.

> Undoubtedly the problem should be fixed - but it does NOT affect all
> SQL-Ledger users, so I think some proper reporting of the vulnerability
> is required - currently it sounds like scare mongering - or does it just
> happen to coincide with this fork?

That is total BS. There are people who are using internet facing
installations of SL, this can be demonstrated by a google search for
'SQL-Ledger version'. They have a right to know that their application
is severely flawed. Numerous attempts to get Dieter to fix this
problem have been ignored, only by going public with this did he start
to make noises about fixing it. While we were talking to him off list
about it, he kept on insisting that it wasn't a security problem. If
this is so, why is he fixing it now that it is public? It's either a
problem or it's not.

Cheers,

Chris

On Thu, 7 Sep 2006, Christopher Murtagh wrote:

> On 9/7/06, Trevor Hennion <tre...@th...> wrote:
> > So using SSL WILL protect MOST of the users of SQL-Ledger -
>
>   No, it will not. If the user can forge the credentials trivially (in
> the case of the current SQL-Leger), adding encryption will not buy you
> ANYTHING. Adding SSL will only be a benefit once some sort of proper
> authentication mechanism is in place.
>
> > Undoubtedly the problem should be fixed - but it does NOT affect all
> > SQL-Ledger users, so I think some proper reporting of the vulnerability
> > is required - currently it sounds like scare mongering - or does it just
> > happen to coincide with this fork?
>
> That is total BS. There are people who are using internet facing
> installations of SL, this can be demonstrated by a google search for
> 'SQL-Ledger version'. They have a right to know that their application
> is severely flawed. Numerous attempts to get Dieter to fix this
> problem have been ignored, only by going public with this did he start
> to make noises about fixing it. While we were talking to him off list
> about it, he kept on insisting that it wasn't a security problem. If
> this is so, why is he fixing it now that it is public? It's either a
> problem or it's not.

This is simply a lie. I looked at this and started on a bug fix the minute
it came to my attention. I told you to submit a patch so we could expedite
this but only after numerous attempts telling you to submit a patch you
finally did, actually it wasn't you but you left it up to Travers to do
the work for you.

-- 
Dieter Simader    http://www.sql-ledger.com   (780) 472-8161
DWS Systems Inc.     Accounting Software       Fax: 478-5281
============ On a clear disk you can seek forever ==========

Dieter,

Can you give any sort of rough guess as to when the fix might be done?

Cheers
David

On Thu, 2006-09-07 at 17:40 -0600, Dieter Simader wrote:

> This is simply a lie. I looked at this and started on a bug fix the minute
> it came to my attention. I told you to submit a patch so we could expedite
> this but only after numerous attempts telling you to submit a patch you
> finally did, actually it wasn't you but you left it up to Travers to do
> the work for you.
> 

I am going through admin.pl right now and should have it completed fairly
soon.

It will work a bit differently. The session key is put together from the
login name and the password. This is setup for the cookie, a digest is
written to the user's config file for comparison. There is also a
serverside and browserside timeout. Multiuser access is granted if the
sessions are within the timeout value. All the variables must match or you
get a password prompt. Commandline access works just as before.

In theory there is no way to guess anything because the cookie is never
known anywhere outside of the browser. It's not stored in readable format.
The raw cookie is compared to a digested version and if the two don't
match you get a password prompt. In addition to the undigested version
I'll add another switch so the cookie can be scrambled. This however will
break multiple logins for the same user because the digest will never
match different browser sessions.

If anyone has any other ideas, by all means let me know.

-- 
Dieter Simader    http://www.sql-ledger.com   (780) 472-8161
DWS Systems Inc.     Accounting Software       Fax: 478-5281
============ On a clear disk you can seek forever ==========

On Fri, 8 Sep 2006, David Tangye wrote:

> Dieter,
>
> Can you give any sort of rough guess as to when the fix might be done?
>
> Cheers
> David
>
> On Thu, 2006-09-07 at 17:40 -0600, Dieter Simader wrote:
>
> > This is simply a lie. I looked at this and started on a bug fix the minute
> > it came to my attention. I told you to submit a patch so we could expedite
> > this but only after numerous attempts telling you to submit a patch you
> > finally did, actually it wasn't you but you left it up to Travers to do
> > the work for you.
> >
>
>
> -------------------------------------------------------------------------
> 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
>

On Thu, Sep 07, 2006 at 06:51:25PM -0600, Dieter Simader wrote:
> I am going through admin.pl right now and should have it completed fairly
> soon.
> 
> It will work a bit differently. The session key is put together from the
> login name and the password. This is setup for the cookie, a digest is
> written to the user's config file for comparison. There is also a
> serverside and browserside timeout. Multiuser access is granted if the
> sessions are within the timeout value. All the variables must match or you
> get a password prompt. Commandline access works just as before.
> 
> In theory there is no way to guess anything because the cookie is never
> known anywhere outside of the browser. It's not stored in readable format.
> The raw cookie is compared to a digested version and if the two don't
> match you get a password prompt. In addition to the undigested version
> I'll add another switch so the cookie can be scrambled. This however will
> break multiple logins for the same user because the digest will never
> match different browser sessions.
> 
> If anyone has any other ideas, by all means let me know.

Dieter, would it be difficult to (as an alternative) to support 
external authentication i.e. delegate the authentication to apache, 
and on the SL side just trust the REMOTE_USER environment variable, 
and bypass the SL authentication if this is set?

That would be very nice in terms of using ldap or some kind of 
single-signon authentication with SL, and would mean the truly 
paranoid could implement whatever crazy auth scheme they'd like 
themselves.

You'd still need the SL user database for authorization of course.

Thanks and regards,
Gavin

-- 
Gavin Carr
Open Fusion - Open Source Business Solutions [ Linux - Perl - Apache ]
http://www.openfusion.com.au
- Fashion is a variable, but style is a constant - Programming Perl

> Dieter, would it be difficult to (as an alternative) to support 
> external authentication i.e. delegate the authentication to apache, 
> and on the SL side just trust the REMOTE_USER environment variable, 
> and bypass the SL authentication if this is set?
>
> That would be very nice in terms of using ldap or some kind of 
> single-signon authentication with SL, and would mean the truly 
> paranoid could implement whatever crazy auth scheme they'd like 
> themselves.
>
> You'd still need the SL user database for authorization of course.
>   
I second this very much !

regards

Philippe

On 9/7/06, Gavin Carr <ga...@op...> wrote:
> Dieter, would it be difficult to (as an alternative) to support
> external authentication i.e. delegate the authentication to apache,
> and on the SL side just trust the REMOTE_USER environment variable,
> and bypass the SL authentication if this is set?

 One of our goals in LedgerSMB is to have a plugable authentication
scheme and probalby support LDAP and Kerberos (HTTP Basic Auth would
be fairly simple too). It requires a bit of re-wireing, but not too
much. Once we have it rolled out, anyone working on SL is more than
welcome to re-use the code. I suspect in the early days of the fork,
moving code from LedgerSMB to SL will be fairly easy, but will get
harder as the projects diverge. We will try to provide an easy
migration path from SL to LedgerSMB for as long as we can.

Cheers,

Chris

Why are you still here?!  Why don't you chat up your
grand plans on your own list?  Wait, I think I know -
there's nobody there, right?  So you're still here
trying to talk to someone...

Dave

--- Christopher Murtagh
<chr...@gm...> wrote:
 
>  One of our goals in LedgerSMB is to have a plugable
> authentication
> scheme and probalby support LDAP and Kerberos (HTTP
> Basic Auth would
> be fairly simple too). It requires a bit of
> re-wireing, but not too
> much. Once we have it rolled out, anyone working on
> SL is more than
> welcome to re-use the code. I suspect in the early
> days of the fork,
> moving code from LedgerSMB to SL will be fairly
> easy, but will get
> harder as the projects diverge. We will try to
> provide an easy
> migration path from SL to LedgerSMB for as long as
> we can.
> 
> Cheers,
> 
> Chris
> 
>
-------------------------------------------------------------------------
> 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
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Philippe Schelt=E9 wrote:
>> Dieter, would it be difficult to (as an alternative) to support=
=20
>> external authentication i.e. delegate the authentication to apache=
,=20
>> and on the SL side just trust the REMOTE_USER environment variable=
,=20
>> and bypass the SL authentication if this is set?
>>
>> That would be very nice in terms of using ldap or some kind of=
=20
>> single-signon authentication with SL, and would mean the truly=
=20
>> paranoid could implement whatever crazy auth scheme they'd like=
=20
>> themselves.
>>
>> You'd still need the SL user database for authorization of course.
>>  =20
>>    =20
> I second this very much !
>
> regards
>
> Philippe
>  =20
I too would look forward to multiple authentication schemes.

I use SL for my own personal business.  At work, I use a bug tracking=
=20
system that many of you have probably heard of - Bugzilla.  They have=
 an=20
option to either use their internal user database, LDAP, or external=
=20
environment variables.  No PAM yet, though.  But it could be a good=
=20
start for looking at code.  I use the LDAP authentication against my=
=20
company's active directory, and then bugzilla uses the username for=
=20
authorization.

The parallel here is that Bugzilla is also written primarily in Perl.=
..

Hope that helps point someone in the right direction...

Regards,
Frank

On Fri, 8 Sep 2006, Christopher Murtagh wrote:

> On 9/7/06, Gavin Carr <ga...@op...> wrote:
>> Dieter, would it be difficult to (as an alternative) to support
>> external authentication i.e. delegate the authentication to apache,
>> and on the SL side just trust the REMOTE_USER environment variable,
>> and bypass the SL authentication if this is set?
>
> One of our goals in LedgerSMB is to have a plugable authentication
> scheme and probalby support LDAP and Kerberos (HTTP Basic Auth would
> be fairly simple too). It requires a bit of re-wireing, but not too
> much. Once we have it rolled out, anyone working on SL is more than
> welcome to re-use the code. I suspect in the early days of the fork,
> moving code from LedgerSMB to SL will be fairly easy, but will get
> harder as the projects diverge. We will try to provide an easy
> migration path from SL to LedgerSMB for as long as we can.

How come you insist on answering questions not asked? Unless my eyes
decieve me the question was addresses to Dieter wrt to SL. I did not see
anything asking about what you intend to do with LedgerSMB, yet you insist
on providing an advertisment to your fork. Has this list been turned into the
LedgerSMB mailing list.

ALL OF THIS IS GETTING OLD.

We understand the problem, now PLEASE stop whining and either return to
talking about constructive issues with SL or move on to your own list and
continue to trash SL there if you prefer.

We get the point that you are forking SL. Good luck with that! That is the
beauty of open source.

Regards,

-- 
Tom Diehl		td...@ro...		Spamtrap address mt...@ro...