The Story Behind CVE-2006-4244 and LedgerSMB

In general, one would think that when the author of software would fix major security issues as soon as possible. However, this is not always done. This entry shows my experience in the area of security disclosure when things go horribly wrong and when outright lies are told about people who work tirelessly to help ensure the security of their customers. In this latter category I find myself along with a couple others. It is hoped that others will find it easier to avoid some of the mistakes that I have made in approaching what became a very volatile situation. Furthermore, I would normally leave private emails private, but when public attacks are made on me, I do not feel the obligation to keep the attackers' emails private.

About a year ago, I discovered what I thought was a dangerous but contained exploit in SQL-Ledger. I promptly filed a bug report with the maintainer privately via the web site for which I received no reply. At the time, I suggested I would create a patch on my own and submit the report to Bugtraq if it was not fixed within 30 days. The only problem was that I didn't have any time, so the patch never got written. I didn't want to go to Bugtraq and simply cause many people to have horribly exposed systems so I kept silent. However, I was no longer happy with the way the application was maintained and I informed my customers of what they could do to minimize exposure to attack.

In April, I received a number of very hostile emails from the maintainer of the software for my efforts to build community-maintained documentation. I made the mistake of trying to get him to address my security concerns. He stated that he was not interested in fixing the problem.

On April 17th I wrote:

Session id's are not tracked by login on the server, allowing session

hijacking or even logging on once the user's .conf file exists without a

password.  The old password authentication was therefore more secure

than the current system.
To which he replied:



try it, crack it, hack it. server side cookies are a big security risk,

not client side cookies. The onus is on the user to log out, why should

the server babysit.
This reply indicated to me that he simply didn't understand the problem.  The issue is that one simply cannot trust a client that the administrator may have no control over more than the server.  At the time, I was not yet aware of the entire scope of the problem.    Indeed on a cursory code review, I would find that the session id was simply the UNIX epoch timestamp (or the return value from the Perl time function).  At this point, the full issue struck me and I was faced with a serious decision to make: whether to continue to trust Dieter or not with the security of my customers.  After discussing the matter for a while with others, I reluctantly decided that the only thing I could do was fork the software, especially .  This decision was made in early June, but at the time, I did not have the resources to seriously pursue creating such a fork.  And so things remained for another couple of months.

The catalyst for change came when I was approached by Josh Berkus and asked a number of questions about the viability of the SQL-Ledger community.  Josh introduced me to Chris Murtagh with the idea that we might be able to collaborate on a fork.  While I think that Josh's main interest was in having a fork, my main interest was in getting a security solution for my customers.  Within a day, Chris had created a basic patch which needed some tuning but corrected the problem relatively nicely by tracking random session id's in the database.  While this patch is not perfect, it actually provides an authentication system that is at least up to industry standards.  At that point we notified the list and Bugtraq did some further development and notified the list.  Chris sent the email to the list and I sent the email to Bugtraq.

At that point things got ugly.  Dieter's initial reply to Chris for the posting included this tidbit:

Now if you want to scare everyone start with how unsafe Windows is,

heck even Linux and tell everyone that if you don't lock this or that

anyone can attack you. Will it serve any purpose? NO!
Again, one must eventually conclude that Dieter did not understand that this was a fundamental design flaw in the authentication system of his application.  It is simply not possible to lock this problem out.  After another day we fully tested the patch and sent it to Dieter.  In the mean time, I got this nice email from Dieter:

Then fix it and submit a patch. It serves no purpose to fearmonger.



Did you ever wonder why Microsoft does not just buy out SQL-Ledger? It

would be drop in the bucket for them to get rid of the competition but

guys like you do it for them, and at no cost to them to boot.

Menschenskind how stupid is that?



Think what you do. It affects you just as it affects me, you more so

because if you force me to go proprietary you get no more code. Maybe you

think this will be a service to the general public to keep my code and the

code from other contributors out of the public protecting them from

"vulnerabilities" which are easily squashes if a person does the right

thing. THINK ABOUT IT, not scare the public!
The morning after we sent the patch, we got the following email:


Did you ever ask yourself how a user could get in if he does not have a

shell account. No shell account, no way to create a cookie file.



What you are doing is false sense of security because you believe it is

now safe for a user to have a shell account but in fact you just exposed

your system more so than before.



Think about it!



Your house is safe if you throw away the key. By not giving the user shell

access you throw away the key.
This email was so odd, it almost defies a response...  I suppose that in some exotic environments shell access might be required to create a cookie, but in the vast majority of environments (including essentially all Windows and Mac environments and most Linux and UNIX environments), shell access doesn't make a difference.

But by that point we were already working on our fork.  Since that point, Dieter has publically stated that it is a very technical issue which is not a serious problem.  Yet the National Vulnerability Database gives it a severity rating of 7 (high).

Preparing the fork took Chris and I about a week and a half of nearly sleepless nights.  Both of us are fathers of young children.  We both have families and other time commitments.  This has been an unbelievably exhausting time.  And in the end, we were publically attacked for our efforts.

A couple points to repeat for emphasis:

1. We created the security patch before starting work on the fork.
2. The release LedgerSMB took more than another week.
3. SQL-Ledger *still* has no official patch over a week
   
4. Dieter still suggests it is not a big deal despite the fact that nearly every private security company acknowledges that it is a serious problem.

Now, if I could do some things differently, I would. I have learned a number of valuable lessons from this experience.

1. I would not have confronted the maintainer of the software when he was already upset at me.
2. I would have gone to Bugtraq even without a patch in hand. In the end, perhaps this could have been avoided and the problem fixed a year ago had I followed through with my original plan.

Yet to my knowledge this vulnerability has not yet been exploited. I guess that as rough as this has been, it might save some people problems,