(reprise texto d’un mail sur spip-ann)
Bonjour,
un grave problème de sécurité vient de nous être signalé ; ce problème
affecte toutes les versions de SPIP 2.0.x jusqu’à SPIP 2.0.8, ainsi
que la branche 1.9. Il permet à un attaquant ne disposant d’aucun mot
de passe de prendre le contrôle de votre site SPIP et de votre serveur
web.
L’alerte est d’autant plus sérieuse que le « trou » n’a pas cette fois
été découvert par un « gentil », mais par un véritable « méchant » qui a
pris le contrôle d’un site existant pour y insérer des malware.
Correctifs
Nous publions donc aujourd’hui deux versions de maintenance de SPIP,
qui corrigent ce bug :
- SPIP 2.0.9, dernière version stable et officielle, qui contient,
outre la correction de ce problème de sécurité, quelques
améliorations, listées ci-dessous.
- SPIP 1.9.2i, version de maintenance de la branche 1.9.2
à télécharger sur
=> http://files.spip.org/spip/stable/
=>http://files.spip.org/spip/archives/ (pour la version 1.9.2i)
ou, si vous utilisez spip_loader, en vous rendant à l’adresse
=> http://xxx.example.tld/spip_loader.php
Pour les spécialistes, le patch de sécurité stricto sensu pour la
branche 2.0.x, qui ne corrige aucun autre bug et n’apporte aucune
autre fonctionnalité, peut se trouver ici :
http://fil.rezo.net/secu-14346-14350+14354.patch
Il s’agit des révisions [14347] [14348] [14349] [14350] et [14354].
Pour la branche 1.9.2x le patch est ici :
http://trac.rezo.net/trac/spip/changeset/14354/branches/spip-1.9.2
Ecran de sécurité
Si vous n’avez pas la possibilité de procéder à la mise à jour
complète tout de suite, nous vous invitons à colmater sans attendre le
problème en installant sur votre site l’« écran de sécurité », que
vous pouvez découvrir à l’adresse :
http://www.spip.net/fr_article4200.html
Cet écran permet de bloquer une éventuelle attaque sans pour autant
devoir mettre à jour les fichiers de SPIP.
Crédits
L’attaque a été détectée et analysée par Thomas Sutton et Pierre Rousset.
Nous vous rappelons que le meilleur moyen pour nous signaler un problème
de sécurité est d’envoyer un mail à la liste spip-team arobize rezo.net
Discussions par date d’activité
40 discussions
je suis chez OVH ; ils m’ont signalé une attaque et ont donc bloqué mon hébergement ; j’ai supprimé un répertoire « cartoon » avec plein d’images... puis upgradé mes sites SPIP en 2.0.9 et j’ai réouvert.
6 heures plus tard, nouveau message d’OVH :
Blocage
Problème rencontré : Script flooding mailout
Commande apparente : 3952 ? S 15:19 0:00 /usr/bin/perl dm.cgi
Exécutable utilisé : N-A
Horodatage : Tue Sep 8 15:19:20 CEST 2009
Je fais quoi ?
Je ne sais pas si ton problème a à voir avec SPIP. Mais une fois que tu as été infecté, il faut trouver tous les scripts malicieux installé par le pirate et nettoyer complètement pour assainir ton site.
Répondre à ce message
Depuis que j’ai fait la mise à jour à cause de problème de sécurité, je suis un embêté par un problème de PHP qui ne passe plus…
Je suis en révision 14452 actuellement, et il ne m’est plus possible de faire ceci sans qu’il en résulte une erreur qui n’affiche plus certains éléments ou même des pages entières :
href="#URL_RUBRIQUE?date_liste=<?php echo $année;?>-<?php echo $mois; ?>"Pour avoir un affichage de l’URL du type :
www.site.com/rubrique/?date_liste=2009-09Ca m’était pourtant très utile pour une rubrique calendrier, pour afficher un certain type d’articles publiés le mois en cours.
Est-ce du à la correction de l’alerte de sécurité ou ça vient d’une autre mise à jour ?
Répondre à ce message
bonjour ;
comme beaucoup, je suis sensible à la sécurité. Je viens de faire la mise à jour de mon spip 2 installé le 12 juillet (donc récent, mais je ne sais plus la version) vers la dernière version, 2.0.9, à l’instant, grâce à spip_loader.php. Je trouve ça plus facile. Ca c’est bien passé, merci, sauf... ben oui, ce ne serait pas marant, sinon !
que depuis, le site tourne en rond au niveau de la maintenance :
page « la procédure de mise à jour doit être lancée afin d’adapter la base de données à la nouvelle version de SPIP. » -> je fait la mise à niveau de la base sql, puis ca revient sur la page « la procédure.... » et rebelote ! Le site a l’air de fonctionner en tant que visiteur, mais cela reste bloqué la dessus, impossible d’écrire un article !.
Est-ce un problème au niveau de Mysql, ou de la mise à jour, à votre avis ?
Merci de votre avis.
Rémi.
Bonjour,
Je rencontre un problème dont je me suis aperçu tout à fait fortuitement, en rédigeant un message d’essai sur 2 de mes sites.
La messagerie fonctionnait très bien en 208, puis depuis que je les ai basculés en 209, j’obtiens ceci en réponse lors de la visualisation du message, de plus, les anciens messages ne sont plus visibiles :
« Fatal error : Call to undefined function : cs_decoupe() in /mnt/102/sdb/c/0/monsite/squelettes-dist/formulaires/forum.php(275) : eval()’d code on line 1 »
Est ce que j’ai manqué une étape dans l’installation de 209 ou est ce un problème non encore signalé lié à la sécurité ?
Comme cela arrivait aussi en local, donc sur 4 sites en spip 209, j’ai changé le fichier forum.php de la 209 par celui de la 208, et les messageries remarchent, sur tous les serveurs.
Maintenant, est ce que je suis en sécurité ?
je me répond : la solution a été trouvé grace aux contributeurs sur IRC : en fait, il a fallut changer le numéro de version dans la base de donné : champ spip_meta -> version au lieu de la nouvelle version, il était rester à l’ancienne !
voila !
RE Bonjour,
Quelqu’un a t il testé la messagerie avec SPIP 2.0.9 [14407] ?
J’ai un message d’erreur depuis que j’ai changé de version, et les messages ne sont plus envoyés.
Il faut donner ton message d’erreur si tu veux qu’on puisse t’aider !
« Fatal error : Call to undefined function : cs_decoupe() in /mnt/102/sdb/c/0/monsite/squelettes-dist/formulaires/forum.php(275) : eval()’d code on line 1 »
Est ce un problème non encore signalé ?
Message déjà posté le 18 août, c’est pour cela que je n’ai pas repris le message d’erreur puisqu’il était déjà sur le forum. J’y précise entre autre comment j’ai contourné le problème.
Merci de me dire si pour toi, ça marche.
Salut,
As-tu mis les nouveaux formulaires et modèles qui sont dans le nouveau squelettes-dist ( 209 ) qui ont changé par rapport aux anciens ( tout du moins entre la 192d et 209 .. ) ?!.
Je vois par ailleurs sur forum.php ( 208 ) et forum.php ( 209 ), que le traitement est différent notamment à partir de la ligne 260 !..
As-tu comparé si il y avait aussi des changements entre les in_forum_... , puisse que forum.php fait appels aux in_forum_... .
Peut-être que tu trouveras également plus d’éléments dans ma réponse faite à David « incompréhension procédure mise à jour ? ».
Bonjour, et merci de répondre à mon message, apparemment, je suis le seul à avoir ce problème...
J’ai constaté ce dysfonctionnement en passant de la 208 à la 209.
Comme je l’ai dit par ailleurs, je l’ai contourné en plaçant le fichier 208 « forum.php » de la 208 à la place de la 209, et là tout remarche !
De toute manière, je ne vais pas me prendre la tête, parce qu’à ma première mise à jour j’ai trouvé bizarre que le numéro de la version n’ai pas changé, en regardant bien, je n’avais pas le fichier svn dans le zip.
J’attendrai donc que tout se calme et devienne stable. J’ai réglé mon problème de messagerie, c’est l’essentiel.
Bonne journée et merci encore.
PS : comme tu l’as compris, j’étais déjà en 208 avant de passer en 209.
Excuse, j’ai oublié de signer : Patrick
"Fatal error : Call to undefined function : cs_decoupe() in /mnt/102/sdb/c/0/monsite/squelettes-dist/formulaires/forum.php(275) : eval()’d code on line 1"a priori donc l’erreur concerne le plugin couteau suisse
pour s’assurer que l’erreur vient bien de spip, désactiver les plugins, vider les caches clients et serveur et le répertoire /tmp peut fournir une bonne indication...
Bonjour,
Effectivement, le couteau suisse est en cause, il bloque la messagerie.
J’ai replacé le fichier forum.php du dernier spip par celui de février, et ça marche.
Merci pour les infos, mais pour le moment, j’ai trop besoin du couteau suisse pour m’en passer.
Bonne journée
Bonjour.
Attention ! Le Couteau Suisse n’était pas en cause. Les versions de SPIP 2.0 parues entre le 10 juillet et le 9 août comportaient un bug silencieux sur la prévisualisation des messages (include manquant avant l’application « un peu compliquée » des traitements sur #TEXTE/forums) que le Couteau Suisse a permis de lever.
Remercions donc ici ce plugin, ainsi que Fil pour sa correction ;-)
Répondre à ce message
Bonjour,
Est-ce que la 1.9.2i apporte des fonctionnalités supplémentaires par rapport à la 1.9.2h, ou bien ne fait-elle que corriger la faille de sécurité en modifiant exec/export_all.php et index.php ?
Merci !
Répondre à ce message
Boujour,
J’ai 8 sites en spip 2.06 et j’ai pas vraiment envie de tout remettre à jour alors que je viens de le faire il y a pas longtemps.
J’aimerais savoir s’il suffit de modifier les 3 fichiers comme indiquer dans le patch de sécurité et s’il y a un moyen de vérifier que le site est bien protégé.
Répondre à ce message
Salut,
J’ai le même problème avec Spip 2.0.9, dès que je touche à la config avancée, toute l’admin et tout le site prennent le même message d’erreur que Patman. Ca n’a rien à voir avec les plugins (j’ai tout retiré) ni avec la base (remise à zéro). J’ai juste noté que vider les temporaires (notamment leur .htaccess, bizarrement) semble régler le problème, mais ça revient régulièrement.
*A tout hasard*, tu ne serais pas sur serveur 60gp chez OVH ? Parcequ’avec les mêmes fichiers sur un autre serveur ça marche parfaitement...
Exactement je suis sur un 60gp... cela proviendrait d’un mauvais paramétrage du serveur d’OVH ?! cela semble une piste, comment vérifier ce constat ? d’autant que dans un 60gp on a pas accès à la config du papache.
Alors question : qu’est ce qui à changé entre la 2.0.8 et la 2.0.9 qui fait appel à un fonctionnement serveur, qui n’est pas permis sur un 60gp et qui plante les modification de configuration du spip ??? ( ptete, un truc du genre correctif de sécurité majeur ;-))
Bonjour,
le problème n’est pas spécifique à cette version, et vient du calcul de la taille maxi des vignettes réalisables avec la librairie GD2.
Tu peux eviter ce calcul en definissant manuellement une valeur par défaut dans ton fichier
mes_options.php:Ainsi, SPIP n’essaiera plus de deviner cette valeur, procédure qui pose problème sur les petits hébergements comme le tien.
Merci ; mais en fait là, hélas, ça corrige rien. Je vais voir pour upgrader vers un 90plan ou équivalent, où ça plante pas ; ça me semble une bonne solution et ça va pas nous ruiner non plus...
Concernant le plantage des fonctions avancées la ligne
dans mes_options.php ne corrige pas l’erreur. Mais il y a de ça, tu as raison, j’ai (depuis la table meta) supprimé la génération des vignettes et après avoir vidé le cache cela à réussi... pendant un cour instant. Le temps qu’un nouveau cache ne se créé et là : replantage des fonction avancées. Je crois que je vais attendre que la version 2.1 sorte et je ferais une réinstalle totale avec migration des données au tamis pour valider chaque étapes. Il est vrai que l’hébergement OVH 60gp est pas cher, mais trop juste pour des fonctions nouvelles dans spip. Encore merci @ tous
Il ne faut pas s’attendre à ce que le problème soit corrigé dans une prochaine version si on ne trouve pas d’où ça vient, autrement dit si ceux qui ont le problème n’aide pas plus !
Répondre à ce message
Bonjour,
Merci pour cet article. Pour confirmation, les fichiers à mettre à jour pour intégrer le correctif de sécurité (afin d’éviter une mise à jour complète de SPIP) sont-ils bien :
pour SPIP 1.9.2 :
/ecrire/exec/export_all.php
/ecrire/index.php
pour SPIP 2.0 :
/ecrire/exec/export_all.php
/ecrire/exec/install.php
/ecrire/index.php
merci.
Répondre à ce message
Merci pour votre réactivité.
Y-a-t-il un moyen simple de vérifier que l’écran de sécurité est bien pris en compte ?
Lorsque l’écran de sécurité est actif,
spip.php?echelle=<doit te renvoyer un brutal « No thanks »Merci.
Dans mon cas cela ne fonctionne pas.
Je n’ai pas le message.
J’ai bien placé le fichier « ecran_securite.php » dans le dossier config et j’ai créé dans ce même dossier le fichier « mes_options.php » qui contient
Qu’est ce qui ne va pas ?
avais-tu deja un fichier
mes_options.phpdansecrire/? Dans ce cas, le mieux est de le deplacer dansconfig/, et d’y ajouter la ligne@include_once dirname(__FILE__).'/ecran_securite.php';Même chose pour moi, le test préconisé pour valider l’écran de sécurité ne fonctionne pas
Exact, j’aais déjà un fichier mes_options.php dans ecrire
C’est bien ca !
Merci
Bonjour,
Moi, non plus, en 1.9.2, je n’ai pas le message « No Thanks ».
Je pense avoir tout fait correctement pour l’installation de l’écran de sécurité et j’ai vérifié que je n’ai pas de « mes_options.php » dans ecrire/...
Quelqu’un peut-il m’aider à trouver ce qui ne va pas ?
Grand merci par avance.
Répondre à ce message
J’ai mis à jour de 2.0.8 en 2.0.9 avec spip_loade.php... jusque là no problemo. Sauf que quand j’ai voulu activer les statistiques du site, ben là, une réponse super bizarre >> _DOCTYPE_ECRIRE et il me met le message
(front et back) pendant un petit moment, sans avoir activé la fonction. j’ai testé, c’est toutes les fonctions avancées qui plante. Là s’arrête mon constat.
Un ch’tite soluce siouplé ?
merci
Oups mauvaise image...
Bonsoir,
As-tu essayé de changer le numéro de version dans la table « spip_meta » de ton sql, comme dit le « 18 août 17:37 , par remi » dans les messages ci-dessous !?.
Tu peux voir ton numéro de version actuelle dans le fichier « svn.revision ».
Quelle promptitude ! merci Gérard
Effectivement, j’ai modifier le num de la “version_installee” dans la table spip-meta. J’ai changé 14272 par 14398 (chiffre donné par mon fichier racine svn.revision)... De retour dans le back, spip m’interpelle
Oui, mais il fait le retour en arrière... dans la table spip_meta il repasse à l’ancienne version... et le problème persiste.
l’histoire de version est une partie de la solution, il y a une info résidente qui fait planter.
Mes plugins installés sont : Google analytics, Palette, cfg, Couteau Suisse, fckeditor-spip, Nyroceros, Flux RSS en articles, Bonux 2.0, plugin Squelette Median. Si c’est une piste ?
houla...
mais pourquoi, dans ce cas, toucher à spip_meta ?
je crois que la solution serait plutôt de ce côté là : http://trac.rezo.net/trac/spip/changeset/14400/branches/spip-2.0
car cela représente une partie de la solution... j’ai pu activer une des fonctions avancées (stat du site) avant que cela ne replante et remette le mauvais num version dans la base...
j’ai introduit la modification, que tu m’as donnée, dans mimipres.php . J’ai testé en cliquant sur validé de n’importe quelle fonction avancée. Cela enlève le mot _DOCTYPE_ECRIRE, mais tout le message site en travaux revient.
PIRE :: : j’ai de-nouveau utilisé spip_loader et suis passé en 14402...
mais à la fin de la mise à niveau en bas de la page back office j’ai
mais dans la table spip_meta j’ai “14272” (l’ancien numéro de version) qui est revenu dans “version_installee”
merci de ton intérêt denisb.
l’entrée de spip_meta : « version_installee » n’a rien à voir avec le numéro de commit svn affiché en pied de page dans l’espace privé.
il n’y a pas à y toucher.
Ok, tu as surement raison, je ne m’y connais pas assez...
Il n’empêche que cela m’a permis (pour un court instant) d’activer une fonction avancée... La vérité est ailleurs ;-)
Répondre à ce message
pour les collectionneurs impénitents qui s’accrochent à leur SPIP 1.8.3, l’écran de securité est à placer, avec le fichier mes_options.php correctement modifié, dans le répertoire ecrire
pour le tester
http://monsitespip.net/page.php?test_ecran_securite=1
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires :
|
