[Koha-devel] Fwd: Critical security bug in Koha!

Paul Poulain paul.poulain at biblibre.com
Thu Sep 2 14:18:09 CEST 2021


Je vous fais suivre ce mail de joubu, si qqn peut se pencher dessus et 
contribuer à le résoudre... (me tenir au courant svp)

A+



-------- Message transféré --------
Sujet : 	Critical security bug in Koha!
Date : 	Wed, 1 Sep 2021 11:34:23 +0200
De : 	Jonathan Druart <jonathan.druart at gmail.com>
Pour : 	Martin Renvoize <martin.renvoize at ptfs-europe.com>, Paul Poulain 
<paul.poulain at biblibre.com>, Nick Clemens <nick at bywatersolutions.com>, 
Tomas Cohen Arazi <tomascohen at gmail.com>, David Cook 
<dcook at prosentient.com.au>, Philippe Blouin 
<philippe.blouin at inlibro.com>, Marcel de Rooy 
<M.de.Rooy at rijksmuseum.nl>, Andrii Vashchuk <nugged at gmail.com>, Katrin 
Fischer <Katrin.Fischer.83 at web.de>, Chris Cormack 
<chris at bigballofwax.co.nz>, Galen Charlton <gmcharlt at gmail.com>, Mason 
James <mtj at kohaaloha.com>, Owen Leonard <oleonard at myacpl.org>



Hello everybody,

If you get this email I am expecting from you to talk about it to whom
could be concerned.

Yesterday a bug (28929) was reported about a possible privilege escalation.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28929
It is confirmed and is highlighly critical in some cases, and stay
critical in all other cases. It's really bad.
Basically we are missing filtering on patron's data when we create or
edit a patron. Which means a user can edit whichever info they want,
by modifying the DOM of the page.
And, it includes borrowers.flags (that's where it hurts really badly).

It impacts both OPAC and Staff interfaces.

What you should do:
1. Reduce the risks!
* Disable PatronSelfRegistration (!)
* Disable AutoApprovePatronProfileSettings (!) or you can totally
disable OPACPatronDetails
2. Make sure the staff interface is not accessible to the world
3. Remove old librarian accounts
4. Something else you have in mind? If so, please share!

Then you should (or ask your team to) help us. We will need people on
the bug to:
1. Write patches and discuss the best approach to fix the different
issues (there are patches already)
2. Test! and test! We will have to test on five different versions
(master+4 stables)!
3. QA, and *really* review, all the different versions (we really want
to prevent a mess publishing a fix that will introduce regressions).

We will then need to coordinate.
A plan (to discuss) could be:
1. Tell the big actors to be ready for an urgent release (This is the
goal of this email!)
2. Make the patches ready for the different versions (see the above)
3. Have all the packages ready, before we communicate publicly (Mason,
will you be available?)
4. Tell the people we know to upgrade (so, you, and those who are
aware of the problem)
5. Announce publicly

What do you think?

This info should not be public, but please communicate as much as you
can around you (people you trust of course).
No need to over communicate either, as we are not ready yet!

If you don't have access to the bug, just tell me (or Tomas, Katrin,
Martin, Nick, etc.)

Cheers,
Jonathan

-- 
Paul Poulain, Associé-gérant / co-owner
BibLibre, Services en logiciels libres pour les bibliothèques
BibLibre, Open Source software and services for libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20210902/435de5a3/attachment.htm>


More information about the Koha-devel mailing list