Bonjour,
une importante faille de sécurité a été corrigée dans dolibarr 16 mais comme beaucoup ne suivent pas forcément toutes les mises à jour je préfère poster un message dans l’espoir que vous puissiez faire le nécessaire sur vos installations.
Avant tout, seule la version 16 est impactée, la 15 (et avant) ne le sont pas et la 17 non plus.
Plus précisément, ça concerne les sous versions 16.0.0 16.0.1 16.0.2 16.0.3 et 16.0.4.
Veuillez remplacer votre fichier htdocs/public/ticket/ajax/ajax.php par celui ci:
Et ensuite, une fois le « coup de feu » passé je vous invite à analyser les logs de vos serveurs webs pour chercher si votre carnet d’adresse a été aspiré, si tel est le cas et conformément au RGPD vous devez suivre la procédure.
Note il semblerait que la version 17.0 soit sujette à la même réserve, décochez cette case si elle est active … « moins d’informations » semblent fuiter mais « trop quand même » …
Pour information, j’ai pu constater que cette faille était bel et bien exploitée, donc j’en rajoute une couche en vous encourageant à mettre à jour pour vous protéger, vous et vos éventuels clients.
En complément cette règle pour nginx qui bloque les appels à l’URL en attendant de patcher vos Dolibarr
if ($request_uri ~ajax.php?.email=[^&](?:%+.|__.)(?:&.$|$) ) {
return 403;
}
@pscoffoni une petite explication pour ce 2° patch ? de ce que j’en interprète il ne touche que les gens qui ont le module ticket d’actif ? merci en tout cas pour le fix et pour l’information ici
Pourquoi n’y-a-t-il pas une déclaration officielle d’une CVE pour cette faille de sécurité ?
Je trouve ça un peu inquiétant si les failles de sécurité ne sont pas signalées comme il se doit.
Peut-être que le fond de la question n’est pas tant le canal d’information que qui est à la source de l’information … le prochain devcamp sera probablement l’occasion de faire un RETEX à ce sujet … je pense qu’au fond la charge de travail est tellement importante pour un groupe très restreint de bénévoles qu’à un moment où un autre il y a des bricoles qui passent à côté de ce qu’on aurait rêvé avoir comme solution.
Vous connaissez sans doute l’image suivante
Et donc peut-être qu’il faudrait réfléchir à monter une « équipe sécurité » ? … pour que tout ne repose pas sur les épaules d’une seule ou deux personnes ?
Sachant que nous sommes souvent plus prêts à râler quand une situation comme celle qu’on traverse se présente que de donner 1€/mois pour participer au financement de l’équipe sécurité
Comme dans tout projet open source, ce sont des bénévoles derrières, qui ont une vie, un travail, etc… Et s’il leur reste du temps et de l’envie, font du Dolibarr.
Mais si une faille est corrigée c’est que quelqu’un a fait le travail, il ne s’agit donc plus à ce stade d’un problème de ressources bénévoles.
À partir de là comment peuvent être informés l’ensemble des utilisateurs qu’une faille sur leur installation existe et qu’il faut la corriger ?
Je lis les changelog quand une mise à jour est faite, et pour la v17 qui corrige cette faille il n’en est pas fait mention à ma connaissance.
NB : pour qu’il n’y ait pas de mauvaise interprétation, je précise il n’y a aucune critique négative dans mes messages, je cherche juste à savoir comment je peux faire pour être informé le plus rapidement possible de manière automatique qu’une faille de sécurité doit être corrigée (liste de diffustion, flux rss etc).
@pascal_z je suis sur la même démarche et l’explication la plus simple est celle que j’ai avancé : le flux de données que doivent gérer quelques bénévoles est énorme et nous sommes tous débordés, la priorité est allée à la correction du bug et ensuite sans doute vu l’état de fatigue et l’heure le reste est passé à la trappe.
Pour info voici la liste des commit avec les heures … début 20h47 « fin » 2h35 je n’ose pas imaginer la pugnacité nécessaire pour jongler avec le flux de commit, les branches de dolibarr à maintenir et la lucidité nécessaire pour accomplir cette tâche.
Alors c’est sûr qu’à 2h40 du matin c’est possible qu’on oublie de poser un tag « security » sur un patch et le lendemain d’autres urgences tombent … c’est bien pour ça que je parle de retexet d’équipe security.
Ce qui pourrait poser plus « question » à mon sens c’est que le mec qui a découvert la faille l’a faite remonter sur le canal documenté : Security Policy · Dolibarr/dolibarr · GitHub et / ou par mail à [email protected] et c’est là qu’on pourrait probablement ajouter des ressources humaines pour que pendant que certains codent d’autres documentent et préparent la com’ de crise → #équipe.
Tout à fait, mais Dolibarr repose sur un très (trop) petit nombre de personnes : @eldy, @FHenry, @grandoc, @aspangaro-Easya, etc. et quelques gros mainteneurs comme @frederic34, etc…
Au final moins de 10.
Ce que je n’ai jamais compris dans le projet Dolibarr, c’est le manque de volonté de se structurer plus. Je pense que des bonnes volontés existent, mais ne sont pas utilisées/intégrés.
Un temps, j’ai adhéré à l’association, pensant qu’on aurait des « communications » ou au moins, une fois par an, une discussion sur comment améliorer/Aider, mais jamais rien. J’ai arrêté de cotiser.
J’imagine qu’il faut aller aux devcamp, mais quand tu es développeur du dimanche, je n’ai pas trop l’envie de passer 2 jours à parler code PHP.
