Hi Raphael I have read up on your discussion with the stable sec team. At the moment, sql-ledger is in testing and from what I have heard it would be possible to package and upload LedgerSMB, which fixes the security issues. Therefore, I would like to remove sql-ledger from testing. For lenny, ledgersmb could be used then. Any objections? Cheers Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20071021/187fab04/attachment.pgp
Hi Steffen, On Sun, 21 Oct 2007, Steffen Joeris wrote:> I have read up on your discussion with the stable sec team. At the moment, > sql-ledger is in testing and from what I have heard it would be possible to > package and upload LedgerSMB, which fixes the security issues. Therefore, I > would like to remove sql-ledger from testing. For lenny, ledgersmb could be > used then. Any objections?Yes. Until someone has done the job of packaging LedgerSmb I would like to keep sql-ledger. Please understand that we''re speaking of a financial application that companies are using... (mine included). Also it won''t be trivial to migrate from one to the other, so it''s a fair bit of work to create the package and offer a sane upgrade path. We already documented the fact that sql-ledger is not safe to use in a untrusted environment. Cheers, -- Rapha?l Hertzog Premier livre fran?ais sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Hi Raphael On Sun, 21 Oct 2007 07:38:57 pm Raphael Hertzog wrote:> Hi Steffen, > > On Sun, 21 Oct 2007, Steffen Joeris wrote: > > I have read up on your discussion with the stable sec team. At the > > moment, sql-ledger is in testing and from what I have heard it would be > > possible to package and upload LedgerSMB, which fixes the security > > issues. Therefore, I would like to remove sql-ledger from testing. For > > lenny, ledgersmb could be used then. Any objections? > > Yes. Until someone has done the job of packaging LedgerSmb I would like to > keep sql-ledger. Please understand that we''re speaking of a financial > application that companies are using... (mine included).I totally understand that and I would also want to have other software packaged for debian and to be kept there, but unfortunately ...> Also it won''t be trivial to migrate from one to the other, so it''s a fair > bit of work to create the package and offer a sane upgrade path. > > We already documented the fact that sql-ledger is not safe to use in a > untrusted environment.Well my point is that sql-ledger is in stable (and not security supported), which is the way it is. For lenny this should, IMHO, not happen again. I personally see it that way: ledgersmb is the one after sql-ledger and should be the new verison. For this, sql-ledger can be dropped in favour of ledgersmb. This somehow also makes it the responsibility of the sql-ledger maintainer to care for ledgersmb as a lenny version. If that is not the case, then the removal of sql-ledger (withough any alternative) should be considered. Cheers Steffen P.S. Raphael please note that this is no personal criticism, you know that I am not up for such things. Just my two cents to the sql-ledger security debate. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20071021/a6a99355/attachment.pgp
On Sunday 21 October 2007 14:04, Steffen Joeris wrote:> Well my point is that sql-ledger is in stable (and not security supported), > which is the way it is. For lenny this should, IMHO, not happen again. I > personally see it that way:I respectfully disagree with this. In my opinion, when you cannot trust your authenticated users of sql-ledger, you''ve got a lot bigger problems than this security issue. I''d like to see some real-world cases where this could be exploited before we start to remove things for which no adequate substitute is packaged yet. Of course once there''s a better package available, I''m all for deprecating this one. And also of course, it''s still a bug which should be fixed when reasonably possible. Thijs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 481 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20071021/4075907f/attachment.pgp
Hi, On Sun, 21 Oct 2007, Steffen Joeris wrote:> > Also it won''t be trivial to migrate from one to the other, so it''s a fair > > bit of work to create the package and offer a sane upgrade path. > > > > We already documented the fact that sql-ledger is not safe to use in a > > untrusted environment. > Well my point is that sql-ledger is in stable (and not security supported), > which is the way it is. For lenny this should, IMHO, not happen again. I > personally see it that way:I don''t see the problem of having that package it it doesn''t impose any work on the security team as it''s documented to be non-supported.> ledgersmb is the one after sql-ledger and should be the new verison. For this, > sql-ledger can be dropped in favour of ledgersmb. This somehow also makes it > the responsibility of the sql-ledger maintainer to care for ledgersmb as a > lenny version. If that is not the case, then the removal of sql-ledger > (withough any alternative) should be considered.I agree that ledgersmb should replace sql-ledger in the long term but they are doing major changes to the infrastructure which makes it a quite unstable fork at the time being. As for the responsibility of the sql-ledger maintainer, well, in an ideal world yes ... but the fact is that the sql-ledger maintainers are a bunch of busy guys whose interest for accounting apps is purely required by the necessity of accounting in companies and not really by passion... So while I''d like to already have a working ledgersmb package with a conversion script from sql-ledger to ledgersmb, but this is not the case and I thus disagree with a forced removal of the package. Cheers, -- Rapha?l Hertzog Premier livre fran?ais sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
On Sun, Oct 21, 2007 at 03:17:58PM +0200, Thijs Kinkhorst wrote:> On Sunday 21 October 2007 14:04, Steffen Joeris wrote: > > Well my point is that sql-ledger is in stable (and not security supported), > > which is the way it is. For lenny this should, IMHO, not happen again. I > > personally see it that way: > > I respectfully disagree with this. In my opinion, when you cannot trust your > authenticated users of sql-ledger, you''ve got a lot bigger problems than this > security issue.I agree. Cheers, Moritz
Hi. I am not a subscriber of this list but I wanted to provide some accurate information about SQL-Ledger and LedgerSMB, including migration issues and the like. I am a core developer of LedgerSMB and I would encourage people to write to me with any further questions. While I would discourage the use of SQL-Ledger because of security issues which are not trivial to fix, I would also suggest that the decision to deprecate a package should be made based on accurate information. LedgerSMB broke away from SQL-Ledger around 2.6.15. There have been no database changes in SQL-Ledger 2.6.x since we broke off and so we can assume that migration from any version of SQL-Ledger 2.6 will be similar. LedgerSMB and SQL-Ledger have different policies relating to database changes and the like. SQL-Ledger does not seem to have much of a policy per se (database changes can happen at any time) while LedgerSMB only makes such changes between branches (1.0 vs 1.1 vs 1.2, etc). We provide migration scripts from SQL-Ledger 2.6.x to LSMB 1.0, from LSMB 1.0 to 1.1, etc so in theory there shouldn''t be any problems. However, a few people do run into a few sorts of poblems relating to our database changes. Basically we enforce data integrity to a much greater extent and so some people have trouble migrating because their data is already messed up. THis usually occurs because of custom modifications, poor configuration of SQL-Ledger, etc. These issues are rare and when they occur they are usually a symptom of a deeper problem that should be fixed as soon as possible. The second area people occasionally run into problems involve deployment scenarios which are at odds with our security infrastructure. For example, we require a single username to be used by a single user at one time. Any other migration issues should be reported as bugs. If there is a lot of interest from you folks about packaging LedgerSMB, let me know and I would be glad to provide whatever assistance I am able. I know that one other core developer already releases .deb packages frequently, though not all releases have debian packages to date. I am sure we would be able to help ensure that the software could meet your needs both individually and collectively. Best Wishes, Chris Travers -------------- next part -------------- A non-text attachment was scrubbed... Name: chris.vcf Type: text/x-vcard Size: 171 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20071022/e8a610e1/attachment.vcf
Thijs Kinkhors wrote: >I''d like to see some real-world cases where this could be exploited before we > start to remove things for which no adequate substitute is packaged yet. I don''t think people understand what the danger is. Basically an accounting application is something which tracks, manages, and often even provides access to your company''s money. This is not monopoly money; it is the real thing. With access to an accounting application, an individual can create false invoices and print false checks in order to embezzle money from an organization. In an ideal environment, these things can be tracked and audited, so you have a great deal of confidence that you know who printed every check, you know who entered every invoice, etc. However, if the security of the system is compromised, you have the ability to tamper with these audit trails, allowing an individual to effectively cover up embezzlement activities. While this is somewhat easier where petty cash is concerned (as there is no independent record beyond internal voucher slips), it is not entirely out of the question with checking accounts and the like. In short such security issues allow people to steal your money. Ths is not unheard of in small to midsize businesses which is usually why either owners do most of the bookkeeping themselves or you have a strict separation of duties. In short no business of any size can afford to trust the bookkeepers in the way you suggest. Part of the problem is that we are not talking about a typical IT security scenario here. These sorts of attacks are generally done by people who know what they are looking for, and are using it to hide evidence of theft. It is also a big deal when you have to know that your books are accurage (for example during a tax audit or due to Sarbanes-Oxley, or equivalent, compliance requirements). As I said in my previous email, you should make your decisions based on facts. If the software is not maintained regarding security, it is your decision whether to distribute it or not. But you should be aware of the real-world risks of doing so: 1) SQL injection issues in SQL-Ledger are numerous, obvious, and easy to exploit to alter audit trails, change financial records, or the like. We, in the LedgerSMB project, are *still* finding these several months after we thought we converted everything to parameterized forms 2) SQL-Ledger only pretends to have a real authorization framework. THe "Access Control" section actually merely customizes the menu. It does not provide any effective security. Best Wishes, Chris Travers -------------- next part -------------- A non-text attachment was scrubbed... Name: chris.vcf Type: text/x-vcard Size: 171 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20071022/80e1432e/attachment.vcf