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

[Dieter S. <dsi...@sq...>]

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