Koha Library Software
Dear sirs, We have detected a vulnerabilities in Koha Library Software. Please contact us to obtain the details. Our disclosure policy is available here: http://en.securitylab.ru/lab/disclosure-policy.php Kind regards, Yuriy Marishev Security Engineer Positive Technologies Tel: +007 (495) 744-0144 Fax: +007 (495) 744-0187 ymarishev@ptsecurity.ru<mailto:ymarishev@ptsecurity.ru> www.ptsecurity.com<http://www.ptsecurity.ru/> en.securitylab.ru<http://www.securitylab.ru/>
* Yury Marishev (ymarishev@ptsecurity.ru) wrote:
Dear sirs,
We have detected a vulnerabilities in Koha Library Software. Please contact us to obtain the details.
Our disclosure policy is available here: http://en.securitylab.ru/lab/disclosure-policy.php
I have responded offlist, and I hope to hear the details shortly Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
Le 31/05/2011 09:33, Yury Marishev a écrit :
Dear sirs,
We have detected a vulnerabilities in Koha Library Software. Please contact us to obtain the details.
Our disclosure policy is available here: http://en.securitylab.ru/lab/disclosure-policy.php
Hi Yury, I propose you sent a mail to Chris Cormack <chrisc@catalyst.net.nz>. He is the Release Manager for Koha 3.6, and will make a follow-up of you mail to anyone that could help -chris, you can add me in the loop- Next question: we've spoken of a mailing list for such vulnerabilities. Should we create vulnerabilities@lists.koha-communitiy.org ? I think it could be helpfull. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Wed, Jun 01, 2011 at 09:47:05AM +0200, Paul Poulain wrote:
Next question: we've spoken of a mailing list for such vulnerabilities. Should we create vulnerabilities@lists.koha-community.org ? I think it could be helpfull.
I think Koha project need a communication canal for security issues: currently, the only one I know is using the release manager mail... And when I look in Koha code, there are work possible in security: but should I submerge release manager for 'small' issues (like using regex for sanitization before use user variables...) whereas he has enough work with 'release manager tasks' ? I think I would be better to have 'a team' for security issues, and a place for track these. It should be: - a list, as Paul propose. - a component in bugs.koha-community.org (like 'security' or 'vulnerabilities') - any other suggestions ? Personnally, I will choose both: have a list with moderated subscription (the team security), and a component in bugzilla (where the list is the default assignee). The list, for reporting and discussion about issues (some may need conceptual modifications), and the bugzilla component for tracking. It seems to me, that bugzilla could mark bug as confidencial. This would permit a minimum of discretion before bug correction. But it should be public after patching or releasing. -- Frère Sébastien Marie Abbaye Notre Dame de La Trappe 61380 Soligny-la-Trappe Tél: 02.33.84.17.00 Fax: 02.33.34.98.57 Web: http://www.latrappe.fr/
2011/6/2 Frère Sébastien <semarie-koha@latrappe.fr>:
On Wed, Jun 01, 2011 at 09:47:05AM +0200, Paul Poulain wrote:
Next question: we've spoken of a mailing list for such vulnerabilities. Should we create vulnerabilities@lists.koha-community.org ? I think it could be helpfull.
I think Koha project need a communication canal for security issues: currently, the only one I know is using the release manager mail...
And when I look in Koha code, there are work possible in security: but should I submerge release manager for 'small' issues (like using regex for sanitization before use user variables...) whereas he has enough work with 'release manager tasks' ?
I think I would be better to have 'a team' for security issues, and a place for track these.
It should be: - a list, as Paul propose. - a component in bugs.koha-community.org (like 'security' or 'vulnerabilities') - any other suggestions ?
Personnally, I will choose both: have a list with moderated subscription (the team security), and a component in bugzilla (where the list is the default assignee).
The list, for reporting and discussion about issues (some may need conceptual modifications), and the bugzilla component for tracking.
It seems to me, that bugzilla could mark bug as confidencial. This would permit a minimum of discretion before bug correction. But it should be public after patching or releasing.
I like these ideas. Do we have any dissenting opinions or should we make it so? In talking to my friends who work in security, they suggest a page prominently displayed somewhere that tells people how to let us know about security issues. Also never feel like you are bothering me, I would always, always rather know of any problems than not, So for the time being, if you know of any issues, let me know. You can gpg encrypt the mail using my gpg key if you wish. But lets get a more formal and documented process set up. Chris
Op vrijdag 3 juni 2011 07:10:19 schreef Chris Cormack:
I like these ideas. Do we have any dissenting opinions or should we make it so?
This method is pretty much the same as it's done in a number of other projects (e.g. Mozilla, Ubuntu), and it seems to work well for the most part. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204
Chris Cormack wrote:
2011/6/2 Frère Sébastien <semarie-koha@latrappe.fr>:
On Wed, Jun 01, 2011 at 09:47:05AM +0200, Paul Poulain wrote:
Next question: we've spoken of a mailing list for such vulnerabilities. Should we create vulnerabilities@lists.koha-community.org ? I think it could be helpfull.
I think Koha project need a communication canal for security issues: currently, the only one I know is using the release manager mail... [...] Personnally, I will choose both: have a list with moderated subscription (the team security), and a component in bugzilla (where the list is the default assignee). [...] I like these ideas. Do we have any dissenting opinions or should we make it so?
Please, no closed list for development discussions. If someone finds a security vulnerability and has a support provider, they should tell them. If they do not, contact the project release manager - hopefully we always have release managers who value security highly. I'd encourage everyone to practice full disclosure and discuss them on the BTS or koha-devel as much as possible. Hope that explains, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
Op vrijdag 3 juni 2011 22:03:50 schreef MJ Ray:
Please, no closed list for development discussions. If someone finds a security vulnerability and has a support provider, they should tell them. If they do not, contact the project release manager - hopefully we always have release managers who value security highly.
That's not really possible for people outside the project to figure out easily. We want to make it as easy as possible for vulnerabilities to be reported.
I'd encourage everyone to practice full disclosure and discuss them on the BTS or koha-devel as much as possible.
That's not how responsible disclosure (which is distinct from, and an improvement upon full disclosure) works. Typically you want as few people as possible to know about the vulnerability until it's been patched and released. This keeps the users as secure as is reasonably possible. The standard approach, taken by many open source projects, is to have some really easy way of confidentially reporting vulnerabilities, these are then resolved and released, at which point an announcement is made. Ideally this announcement consists of a workaround if possible, a patch for older versions (if you can't upgrade for some reason), and a release with that patch included. This ensures that the risk of an active exploit finding it's way into the wild is reduced before people have a reasonable chance to do something about it. This is one of the few situations where I think development in private, or at least semi-private, is a good thing. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204
Op vrijdag 3 juni 2011 22:03:50 schreef MJ Ray:
Please, no closed list for development discussions.
We're not talking about a secret cabal of self-chosen list members (anymore). Koha now has an (informally) elected list of officers who can be on the list: Release manager, release maintainer, QA manager. Let's keep it as simple as that. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
It would be hard for a sekrit society of developers to push through any changes that aren't documented publicly; we can all see the commit stream to Git, and if there are a sudden burst of patches being committed that violate the community's agreed-upon practices for submission and review, the community can call shenanigans on the person(s) doing the commits. In the case of any critical security fix, it would be the Release Manager's and Release Maintainers' responsibilities to justify the change set and the deviation from standard procedure; this is probably going to be as simple as "fixes this security issue" in the commit message. Once it's committed, a more robust report can be written up somewhere and linked. I don't think we're going to encounter these kinds of security issues often, so building a complex process to handle them seems counter-productive. I'd rather spend the time just finding/fixing any such issues. -Ian On Fri, Jun 3, 2011 at 8:38 AM, Owen Leonard <oleonard@myacpl.org> wrote:
Op vrijdag 3 juni 2011 22:03:50 schreef MJ Ray:
Please, no closed list for development discussions.
We're not talking about a secret cabal of self-chosen list members (anymore). Koha now has an (informally) elected list of officers who can be on the list: Release manager, release maintainer, QA manager. Let's keep it as simple as that.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Robin Sheat wrote:
Op vrijdag 3 juni 2011 22:03:50 schreef MJ Ray:
Please, no closed list for development discussions. If someone finds a security vulnerability and has a support provider, they should tell them. If they do not, contact the project release manager - hopefully we always have release managers who value security highly.
That's not really possible for people outside the project to figure out easily. We want to make it as easy as possible for vulnerabilities to be reported.
So let's document the current practice and make it easier? Changing the process, adding more steps and special bug cases seems wrong.
I'd encourage everyone to practice full disclosure and discuss them on the BTS or koha-devel as much as possible.
That's not how responsible disclosure (which is distinct from, and an improvement upon full disclosure) works. Typically you want as few people as possible to know about the vulnerability until it's been patched and released. This keeps the users as secure as is reasonably possible.
Delayed disclosure (the neutral name for what you describe, because it is highly irresponsible in the eyes of full-disclosure supporters) has often gone too far and resulted in people trying to keep problems secret for far too long, like until every vulnerable system is patched. There are also the risks that someone inside the privileged group leaks information to attackers, while good people outside that privileged group don't even know that there's a problem. Basically, what type of people are we? Would we tell our neighbours that their homes are insecure when there's a burglar about? Or would we keep quiet until we figured out how to secure our own home first? As far as I know, early all of the vulnerabilities that Koha has suffered have been discoverable with fairly simple tools if you knew where to point them - most have needed some access to intranet or related websites, thankfully.
The standard approach, taken by many open source projects, is to have some really easy way of confidentially reporting vulnerabilities, these are then resolved and released, at which point an announcement is made. [...]
I don't think there is any such standard (got a link?). Yes, many "open source" projects are really closed when it comes to security, but popularity is not a good argument for something, else Koha would almost never be adopted. The disagreement between full and delayed disclosure has been going on in general for at least 150 years, and over 20 for internet security. We're probably not going to change each others' views, but at least know that not everyone wants delayed disclosure. Hope that explains, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/
Op maandag 6 juni 2011 20:34:17 schreef MJ Ray:
So let's document the current practice and make it easier? Changing the process, adding more steps and special bug cases seems wrong.
No it doesn't. (If you can claim something in that manner, so can I :)
Delayed disclosure (the neutral name for what you describe, because it
That's not neutral at all.
is highly irresponsible in the eyes of full-disclosure supporters) has often gone too far and resulted in people trying to keep problems secret for far too long, like until every vulnerable system is patched.
Well then you establish a policy that doesn't have those issues. Problem solved.
There are also the risks that someone inside the privileged group leaks information to attackers, while good people outside that privileged group don't even know that there's a problem.
If you release everything in a full disclosure manner, you give the attackers information without getting it (and a fix) first to the people who have something to defend and will require a bit of time to do so. I think that's a bigger, actual risk than a hypothetical risk of disclosure. If you discover it's already in use in the wild, then you release immediately, falling back to full disclosure mode. Best of both worlds.
Basically, what type of people are we? Would we tell our neighbours that their homes are insecure when there's a burglar about? Or would we keep quiet until we figured out how to secure our own home first?
You're making a strawman argument. In particular the "there's a burglar about" bit. In this case, there isn't.
As far as I know, early all of the vulnerabilities that Koha has suffered have been discoverable with fairly simple tools if you knew where to point them -
Yes, but (afaik) they are generally discovered long after they're implemented, which suggests that this doesn't happen a lot.
most have needed some access to intranet or related websites, thankfully.
That's more good luck than good management.
I don't think there is any such standard (got a link?). Yes, many "open source" projects are really closed when it comes to security, but popularity is not a good argument for something, else Koha would almost never be adopted.
They're not closed. They're just not so open their brains fall out. They (in general, and I'm sure there are pathalogical examples too) simply try to ensure that a fix is available at the same time the attack information is available. Personally, I'm something of a fan of something along the lines of the policy described here: http://web.archive.org/web/20100813161135/http://www.wiretrip.net/rfp/policy... As an example, if you report a security issue on the Mozilla bug tracker, the bug is closed by default until a fix is released. Then it's opened. http://www.mozilla.org/projects/security/security-bugs-policy.html This is far more involved than anything I'd suggest for Koha however. My main concern is to avoid the world at large knowing how to exploit Koha before anyone can quickly work around the issue (I might know how to mitigate a SQL injection, but I go to one or two security conferences a year. Not everyone does.)
The disagreement between full and delayed disclosure has been going on in general for at least 150 years, and over 20 for internet security. We're probably not going to change each others' views, but at least know that not everyone wants delayed disclosure.
As someone who deploys Koha systems, I'd like to see a release of a fix with an announcement so that I know I need to update now, and the information required to do so is immediately available. If it's a difficult fix, then I'd consider something that mitigates the issue to be acceptable. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204
Hi, 1- I like very much Robin proposals 2- i've added the topic to the next IRC meeting (http://wiki.koha-community.org/wiki/General_IRC_Meeting,_14_June_2011) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Back to the original topic. I have not heard back at all from Yury, so have no information on the security issue. I will try to email again. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
2011/6/13 Chris Cormack <chrisc@catalyst.net.nz>:
Back to the original topic.
I have not heard back at all from Yury, so have no information on the security issue. I will try to email again.
I now have the report from Yury. Thank you Yury. It is not a major problem, but a problem nonetheless, happy to share info offlist and will have patches shortly. Chris
In security circles, if the reporter feels that the bug is not being recognized or dealt with adequately by the dedicated project team, then they have the option (and some responsibility) to report it to the wider community. But *starting* with public disclosure of a security issue is correctly regarded as irresponsible. It serves the ego, enables widespread casual exploits and makes the project look bad without giving them a chance to fix it first. Depending on the complexity of the bug and whether or not it is being actively exploited in the wild (and project release methodology), the acceptable duration can vary, anywhere from a couple weeks to several months. A reporting system can have a conservative revert-to-public duration built in. In no case is there grounds to just bury a security bug indefinitely. --joe
participants (11)
-
Chris Cormack -
Chris Cormack -
Frère Sébastien Marie -
Ian Walls -
Joe Atzberger -
Magnus Enger -
MJ Ray -
Owen Leonard -
Paul Poulain -
Robin Sheat -
Yury Marishev