Je lis que les failles critiques sous Wordpress, quoique problématiques, sont largement minimisées par le fait que, depuis Wordpress 3.7 (2013), il y a un système de mise à jour automatique des versions mineures (que l’on peut désactiver, mais par défaut c’est actif):
Ça évite notamment que les failles soient instantanément scannées dès qu’on publie un patch et que c’est annoncé sur l’ANSSI (par exemple), ce qui fait que la simple publication du patch expose tous les sites dans les heures qui suivent.
Est-ce que c’est imaginable avec SPIP pour les versions mineures?
Ou bien pour des mises à jour critique?
Ou bien juste pour l’écran de sécurité, qui serait poussé avec une rustine ad hoc?
Il y a bien Gilles Vincent / spip-auto-update · GitLab mais ça me semble trop technique sans compétences techniques. Alors que, de ce que je comprends, dans Wordpress c’est une fonction native du CMS.
Très rapidement : si c’était trivial et si important, il y a de grandes chances que ce fut déjà fait par quelqu’un·e; il n’y a pas ici de budget, ni le budget de WP et cela amène beaucoup de problématiques de sécurités notamment sur l’action de self-update. La problématique se pose maintenant parce que ça ennuie plein de monde de faire des mises à jour constamment… Mais sinon le ticket est là Mise à jour automatique de SPIP (#3348) · Issues · spip / spip · GitLab
Peut être qu’avec l’ère de l’IA qui code tout et sait fabuleusement copier ce qui est fait ailleurs quelqu’un·e se dévouera et sauvera tout le monde avec cela dans un plugin, mais de ce que je vois pour le moment, c’est que chacun y va de son script maison indépendant (c’est très bien, ça dépanne, mais sera t’il maintenu ?), mais sans toucher au cœur de SPIP, sans l’améliorer intrinsèquement et sans vision plus lointaine du code du logiciel. C’est bien dans l’urgence, mais ça ne rend pas vraiment les choses pérennes.
Ces problématiques de failles à boucher repoussent des chantiers de migration plus conséquents de code entamés en SPIP 5, mis en pause actuellement ; je n’ai aucune espèce d’idée de savoir si / quand / qui / on pourra les reprendre, car les ennuis sont probablement loin d’être finis sur la branche 4 : il est possible qu’on doive sortir une version 4.5 avec quelques aménagements (toujours PHP 7.4 min après discussions du coup quand même). Encore faut-il qu’il reste un peu d’énergie à l’équipe restante du core (perso j’ai un bel épuisement, et je me retiens bien de dire ce que je pense du code ^^ !).
Bref, si quelqu’un·e a ce besoin de maj automatique, je suis certain·e qu’iel trouvera une solution, et proposera un plugin magique… En attendant déjà on maintient un Spip Loader, c’est déjà pas si mal, même si évidemment c’est insuffisant vu le contexte.
Pour rappel, en 2014 j’avais envoyé une fonction pour faire la mise à jour auto de l’écran de sécu :
mais tout le monde avait mis le hola sur le mode « dans quoi on s’embarque ? »… et c’est resté du code mort ensuite (la fonction est toujours là et appelée, mais elle commence par un return;)
Je pense que la réaction aurait été différente après une vague d’attaques comme celles qu’on a eu récemment C’était une très belle idée, merci de la ressortir
Je ne suis pas dans la team, mais ma réflexion est qu’il n’y a aucun risque à faire des mises à jour automatiques de l’écran de sécurité.
Pour le problème de surcharge je pense qu’il est tout à fait possible de déployer des copies sur des serveurs alternatifs (comme c’est fait pour les logiciels linux) - perso je suis prêt à partager quelques ressources que j’ai à ma disposition.
Pour ce qui est des attaques en général, je suis convaincu que l’écran de sécurité ne peut pas se substituer aux mises à jour. Mais c’est toujours mieux que rien car il protège déjà de beaucoup d’attaques.
Mais l’écran de sécurité ne protège évidemment pas contre les attaques zero day, c’est le principe même de ces vulnérabilités: comme de toute façon on ne met à jour l’écran de sécurité que volontairement (et donc quand il est aussi facile de mettre à jour SPIP avec son nouveau patch), il sera toujours trop tard si on ne met pas son site à jour volontairement dans la journée qui suit la mise à jour.
Mais à partir du moment où l’attaque est identifiée, le patch du noyau publié, ma question de savoir si on aurait pu spécifiquement bloquer les attaques récentes avec une mise à jour automatique de l’écran de sécurité (donc sur des sites qui n’ont pas mis à jour tout SPIP volontairement). Quand on dit: «l’écran de sécurité ne protège pas contre telle attaque», c’est évident si l’écran de sécurité contient des règles génériques qui ne protègent pas contre cette attaque spécifique. Mais s’il est mis à jour automatiquement avant que les bots ne passent en exploitant la faille fraîchement découverte, est-ce qu’il ne pourrait pas devenir efficace?
Perso dès le premier site hacké, j’ai ajouté dans .htaccess le blocage des fichiers img_cache.php et image_cache.php, et surtout de tout appel avec un ?recherche=eval… dans l’URL. C’est spécifique à l’attaque qui était en cours, et ça aurait aussi bien se faire dans l’écran de sécurité.
«je sais pas si on peut faire plus claire.» Je sais: dis-moi si SPIP est encore une solution viable pour gérer un site connecté à l’internet, ou si c’est l’assurance de me faire hacker absolument tous les sites de mes clients si je pars deux jours en vacances.
l’écran de sécurité ne fait plus partie de SPIP 5-dev, il y a un autre mécanisme extensible avec spip-league/guard
son contenu actuel bloque des trucs des failles de très vieux SPIP plus maintenus, et personne ne s’est occupé jamais de le nettoyer (j’avais proposé dernièrement une PR à ce sujet, puis basculé sur spip-league/guard pour SPIP 5)
avec quelle version de PHP doit il être encore compatible ? PHP 5.6 pour les SPIP 3.2 qui étaient encore présents au fond de la classe (mais qu’on ne maintient plus non plus) ? encore moins ? l’étendue des versions de PHP à traiter est en soit déjà un problème dedans aussi pour la maintenance…
certaines failles précédentes ne pouvaient être bloquées par l’écran, (d’autres l’auraient pu avec un peu de temps et de volonté)
l’équipe qui s’occupait jusqu’à lors des releases de SPIP (dont je fais partie) préfère dire que c’est tout SPIP qu’il faut tenir à jour, pas simplement ce petit fichier miraculeux
Bien comprendre que l’écran n’est plus réellement mis à jour, ou rarement, pour le côté failles de sécu qu’on a eu ces derniers mois ou années (soit par manque de ressource humaine, soit par impossibilité de traiter les failles dans l’écran) : il ne faut pas trop se faire d’illusion sur ce qu’il offre, même en prepend, et avec les contraintes de versions PHP étendues c’est d’autant plus complexe et ça ne protégera pas des vieux sites pas à jour.
Là c’est sûr qu’on aurait pu bloquer certains des derniers truc avec quelques lignes dans l’écran : pour moi c’est du travail en plus, pour une sécurité trop partielle, qui ne vaut pas la mise à jour complète. En l’état des outils & automatismes présents (ou absents) lors de nos releases, c’est juste contraignant.
Maintenant comme le monde semble avoir une belle énergie, allez-y : il y a des tickets, comme par exemple Nettoyer l’écran de sécurité (#5055) · Issues · spip / spip · GitLab , le code de l’écran est encore public et peut être mis à jour à volonté… Peut être que des gens seront là pour aider lors d’une prochaine release (et surtout pour les mois suivants ensuite…): si c’est pour nous dire « il faut faire cela » mais qu’on n’a pas les automatismes ou moyens / ressource humaine de s’en occuper, ça fera pshiit…
Au vu de nos logs de serveur bloquer « img_cache » ou recherche=eval est totalement insuffisant… tous les noms de fichier y sont passés, tous les paramètres, pas que recherche…
l’écran de sécurité n’est pas la seule manière de maintenir SPIP à jour automatiquement. Il y a des pistes pour permettre cela sans l’écran de sécurité. On va y arriver.
Vous faîtes un travail formidable et spip, avec ses qualités et ses défauts est tout simplement génial.
J’ai voulu un jour tester wordpress et je suis vite revenu à Spip.
Il y a des périodes creuses et fastes dans le développement collaboratif! Il faut rester positif!
Si j’étais plus calée en dev, je m’impliquerai à fond dans l’avenir de SPIP!
Pour avoir un peu de recul, ils ont mis 10 ans chez WP avec de déployer les mises à jour automatiques pour les versions mineures.
Lors de la sortie de la version 3.7 ils ont annoncé avoir simulé 112 000 mises à jour automatiques sur des configurations réelles avant d’arriver à du zéro échec.
La version 5.0 de SPIP introduit un refonte du code qui permettra ce type de tests, on y arrivera aussi .
Je rappelle qu’il existe déjà un plugin qui propose la mise à jour auto des plugins : MajPlugins - SPIP-Contrib, que tout le monde pourrait tester
Je pense qu’il faut absolument mettre ceci en place si on veut que Spip survive. Je suis utilisateur de Spip depuis plus de 20 ans et administrant plusieurs sites dont quelques uns sont très populaires.
Comme beaucoup d’entre vous, j’ai aussi été touché par la faille du 20 août. Deux sites ont servi de fermes à spam pendant 24h.
Je fais donc comme tout le monde aujourd’hui, je scrute les mises à jour Spip et les failles, isolé les sites et mis en place un script qui contrôlent chaque changement de fichier ou des répertoires sensibles (tmp, config et IMG).
Mais à regret, cela ne m’a pas empêché d’aller voir ce qui se fait de mieux aujourd’hui et je suis revenu vers Spip. Mais la question resté posée.
D’ailleurs pour rebondir sur @b_b il y a d’autres manières de participer comme le graphisme ou la traduction. https://contrib.spip.net/Graphisme-parcours-benevole https://contrib.spip.net/Traduction-parcours-benevole
Et sans doute d’autres moyens encore.
Ne serait-ce que les retours de bugs, de problèmes rencontrés à participer, de remarques sur la clarté de certains éléments…
Avoir le regard de personnes qui ne sont pas dev est à mon avis très précieux pour rester accessible et collaboratif à tout les niveaux.
C’était une très belle idée, merci de la ressortir 