Alerte sécurité SPIP + nouvelle version SPIP 2.0.9

Un grave problème de sécurité vient d’être corrigé dans SPIP ; tout ce qu’il faut savoir à ce propos.

Un grave problème de sécurité vient d’être corrigé dans SPIP ; tout ce qu’il faut savoir à ce propos.

(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

Discussion

40 discussions

  • 1

    L’écran de sécurité ne peut être récupéré : le lien ne marche pas :
    http://zone.spip.org/trac/spip-zone/browser/_core_/securite/

    une idée ?

    Répondre à ce message

  • 3

    Bonjour,

    Est-ce que cet écran doit être déployé quelquesoit les version de Spip ?

    -  Spip 2.0.10
    -  Spip 2.0.11
    -  Spip 2.0.12
    -  Spip 2.1.2

     ?

    Merci

    Répondre à ce message

  • 2

    Bonjour,
    Je ne sais pas si c’est normal, mais cette annonce datant de aout 2009 est affiché en page d’accueil du site. J’ai faillit croire qu’une version 2.1.9 était sortie ;-)

    Répondre à ce message

  • 2

    Bonjour à tous,
    Suite à l’alerte de sécurité ci-dessus, j’ai fait passer mon site de la version 2.0.7 à la version 2.0.9.
    Depuis, si quelqu’un fait « Répondre à cet article », quand il clique sur « Voir ce message avant de le poster » il déclenche l’erreur suivante : « Fatal error : Call to undefined function : cs_glossaire() in /homez.34/periple/www/xxx/squelettes-dist/formulaires/forum.php(275) : eval()’d code on line 1 »"
    Je suis hébergé chez OVH, et j’observe la même erreur sur mon site de test en local. J’utilise les plugins Couteau Suisse, Spip listes, Spip Bonux, Compositions, Mini Calendrier.

    Est-ce que quelqu’un a observé ce phénomène et a pu le corriger ?
    Merci par avance de vos réponses.
    JF David

    • Avez vous trouvé une solution à ce problème ?
      Je ne peux me résoudre à enlever le traitement typographique des forums !

    • Je savais que j’aurais du mettre à jour depuis longtemps, je me suis fait avoir, et je suis forfait pour le coup. Mon dernier backup date d’il y a plusieurs moi en plus. Grr

    Répondre à ce message

  • Bonjour,

    Suite à la mise à jour 1.9.2i, un petit détail incohérent est apparu. Lorsque l’on upload une image depuis le backoffice (via « ajouter une image »), le petit bout de code qui apparaît en-dessous n’est plus « img » mais « doc ». Bien entendu, il suffit de remplacer « doc » par « img » dans la zone de texte. Mais est-ce que quelqu’un saurait comment rectifier ce problème de manière à ce que l’on ait plus qu’un copier-coller à faire (depuis le cartouche image vers la zone texte) pour incorporer l’image ?

    Merci d’avances pour vos réponses.

    Répondre à ce message

  • Bonjour,

    Je viens de corriger la faille sur deux sites qui était en 1.9.2 et j’ai fait une vérification/test comme ils le préconisent sur le site de spip (http://www.spip.net/fr_article4200.html). J’ai ce message :

    “Error 403

    You are not authorized to view this page (test 0.9.2)”

    Est-ce bon signe ? L’écran de sécurité est-il bien installé selon vous ?
    Merci d’avance pour vos réponses.

    Répondre à ce message

  • 3
    alain bourdeau

    Bonjour,
    Aprés avoir fait la mise à jour en SPIP 2.0.9 par spip_loader.php,
    Dans la partie privée, j’obtient le message :

    Fichier documenter_objet introuvable

    Quand je cherche à entrer dans la gestion d’une rubrique, quelque soit la rubrique. Et je ne peux pas avoir la mise à jour d’un article ni la création d’un noueau.

    J’ai comme plugins important spip-thélia et acces_restreint.

    Que faut-il faire.
    Merci bien

    • alain bourdeau

      Je me réponds car j’ai trouvé.

      Le fichier documenter_objet.php doit se trouver dans /ecrire/inc

      Il m’a suffit de transférer une version que j’avais en local sur le site.

      Mais pourquoi ce fichier était éliminé de la version sur le site ? Mystère.

      Amicalement à vous

    • Avec le passage de la 2.0.8 à la 2.0.9, j’ai le message Fichier documenter_objet introuvable lorsque je clique sur article dans la partie privée.
      Je n’ai pas de probleme en 2.0.9 partant de zero.

    • le fichier documenter_objet.php ne se trouvait pas ecrire/inc : c’est corrigé.
      visiblement, lors du ftp, la copie ne s’est pas faite.

      c’est résolu.

    Répondre à ce message

  • 3

    Ce bout de squelette fonctionnait correctement sous spip 2.0.8 :

    <B_sub_rubrique>
    (qq chose ici)
    <BOUCLE_sub_rubrique(RUBRIQUES){id_parent}{par titre}{doublons}>
    <BOUCLE_recursive(BOUCLE_sub_rubrique)> </BOUCLE_recursive>
    </BOUCLE_sub_rubrique>
    </B_sub_rubrique>
    (qq chose ici)
    <//B_sub_rubrique>

    Sous 2.0.9 cela me donne une page blanche (y compris tout le code placé avant ou après la boucle) ; un contenu réapparait si je supprime l’appel récursif :

    <B_sub_rubrique>
    (qq chose ici)
    <BOUCLE_sub_rubrique(RUBRIQUES){id_parent}{par titre}{doublons}>
    
    </BOUCLE_sub_rubrique>
    </B_sub_rubrique>
    (qq chose ici)
    <//B_sub_rubrique>

    Une piste ?

    • J’ai recopié ton squelette, et je n’ai pas de page blanche du moment que la rubrique a des rubriques filles. Par ailleurs, ce genre de message doit être posté sur le site spip_forum, cet article n’étant pas consacré à des problèmes éventuels de la 2.0.9.

    • Je réponds ici, vu qu’il s’agit davantage d’une différence de comportement des versions qu’un bug à proprement parler (?). Voici ce que j’ai trouvé en retravaillant mes squelettes (désormais compatibles 2.0.9) :

      SPIP 2.0.8 supportait des boucles imbriquées dans des boucles récursives même si les boucles imbriquées étaient placées dans les parties optionnelles avant ou après ou dans la partie alternative.

      Avec SPIP 2.0.9 il vaut mieux s’arranger pour que les boucles imbriquées soient dans le « corps » de la boucle récursive (il me semble que c’est un problème de passage de paramètres pour les critères de des boucles imbriquées).

      Ca n’a rien à voir, mais j’ai remarqué que la balise #CHAPO renvoie désormais un contenu vide si l’article est virtuel, ce qui est somme toute plus pratique ; mais c’est mieux quand on le sait.

      Quand la documentation sortira t-elle en même temps que les nouvelles versions et non des années plus tard ?

    • Ce comportement me pose problème aussi. Je cherche
      à afficher un plan en mélangeant articles et rubriques, et j’ai besoin de mettre une boucle dans la partie optionnelle, pour pouvoir traiter le cas des rubriques qui ne contiennent que des articles, et le parametre ID_PARENT ne semble pas visible dans la partie optionnelle (ce qui est légitime à top-level, mais pas quand on commence à rentrer dans les appels récursifs).

      Bon, ce que je raconte ne doit pas être compréhensible si je ne donne pas la boucle en question. La voici donc (j’ai nettoyé des trucs inutiles ; j’espere ne pas en avoir enlevé trop) :

      <B_rub>
      <ul> 
        <BOUCLE_rub(RUBRIQUES){tout}{racine}{par num titre}{doublons} >
        <li>
            <a  href="#URL_RUBRIQUE">[(#TITRE)]</a>
            <B_sousrub>
            <ul>
      	<BOUCLE_sousrub(RUBRIQUES){tout}{id_parent}{par num titre}{doublons exclus}>
      	  <BOUCLE_art(ARTICLES){tout}{id_rubrique=#ID_PARENT}{par num titre}{titre<#TITRE*}{doublons}>
      	  <li> <a  href="#URL_ARTICLE">[(#TITRE)] </a> </li>
                </BOUCLE_art>
      	  <li> <a href="#URL_RUBRIQUE">[(#TITRE)] </a>
                <BOUCLE_recursive(BOUCLE_sousrub)>   </BOUCLE_recursive>
      	  </li>
      	       [(#REM) à cause de la condition titre inf #TITRE*, on a pu raté des articles :
      	        on en remet donc une boucle.]
      	      <BOUCLE_art_apres(ARTICLES){tout}{id_rubrique=#ID_PARENT}{par num titre}{doublons}>
         	      <li> <a href="#URL_ARTICLE">[(#TITRE)] </a>  </li>
      	      </BOUCLE_art_apres>
            </BOUCLE_sousrub>
            </ul>
            </B_sousrub>
            <B_art_opt> [(#REM) Pour afficher les articles sans rubriques soeurs]
            <ul>
      	<BOUCLE_art_opt(ARTICLES){id_rubrique=#ID_PARENT}{par num titre}{doublons}>
      	  <li>  <a href="#URL_ARTICLE ">[(#TITRE)]</a> </li>
              </BOUCLE_art_opt>
            </ul>
            </B_art_opt>
            <//B_sousrub>
        </li>
        </BOUCLE_rub>
      </ul>
      </B_rub>

      L’idee de cette boucle est d’afficher au même niveau les articles et les rubriques appartenant à une meme rubrique. Un probleme survient avec cette facon de proceder quand des articles sont dans une rubrique sans rubrique, d’où la boucle art_opt dans la partir optionnelle de la boucle principale.

      Et mon souci, c’est que #ID_PARENT semble invisible dans la boucle BOUCLE_art_opt. Je comprend de cette file que si ca se trouve, ca marchait avant...

    Répondre à ce message

  • 1

    Bonjour,
    j’ai mis à jour la version spip 1.9.2.f à la version 2.0.9.
    Le site s’affiche normalement. Le seul bug : lorsque que je veux me connecter au Back Office, le login ne semble pas être pris en compte. En le validant, il s’efface et rien ne se passe.

    Merci à vous .

    • Bonjour,

      J’ai exactement le même problème !..
      J’ai fais une mise à jour spip du 192d à 209, et depuis le 19 août je n’ai reçu aucune réponse ...
      Donc dans le cas où tu recevrais une réponse en privé, je suis preneur ...

      Le seul moyen que j’ai trouvé pour entrer est de faire une mise à jour virtuelle en supprimant « config et tmp » par ftp ( Attention, sauvegarder tous les réglages des plugins, car il faudra ré-inscrire tous les paramètres [1] .. ) :
      -  refaire l’indentification de la base de données ( pas de changement ),
      -  entrer un nouveau login et un nouveau mot de passe propre à ton identification avec spip ( puisqu’avec celui déjà existant cela ne fonctionne pas !!! ), et redonner ce nouveau login et/ou le passe une deuxième fois pour entrer dans la partie privée quand la mise à jour est terminée ...

      A priori le cookie de correspondance ( penser à bien l’activer .. avant de repasser dans la partie publique ) semble permanent, ou tout du moins il s’agit de le réactiver ( pour moi une fois depuis le 19 août ).
      Grand désavantage, .. il est impossible de travailler avec un autre navigateur, ou même sur un autre ordinateur, sans refaire une ré-installation virtuelle et avec un nouveau login et passe ( puisque toute nouvelle ré-identification est impossible, login qui s’efface et redemande, et redemande ... ), pas très pratique .., perte de temps ...
      Et je ne peux même pas savoir si à priori des intentions malveillantes dormantes extérieures ( quelles soient gouvernementales et/ou privées genre hadopi x et pirates autres ... ) sont à l’affût de prendre le contrôle éventuel du site ( !?. ) ...

      Mais c’est éventuellement une solution d’attente avant qu’enfin le groupe de programmeur de cette version réponde enfin au problème posé soit par une mise à jour partielle ou un patch qui permettrait de reprendre le contrôle total. Et surtout dans cette attente évite toutes intrusions possibles par des forums ou autre.

    Répondre à ce message

  • 1

    il me semble avoir fait la mis à jour normalement, pourtant dans l’espace privé il est toujours mentionné que j’ai affaire à la version 2.0.8, est-ce normal ?

    • non, tu dois voir figurer la mention SPIP 209 dans le backoffice (en bas de page)

      normalement pour un passage de SPIP 208 à SPIP 209,un message t’avertit que SPIP va effectuer une mise à jour.

    Répondre à ce message

  • 1

    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-09

    Ca 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

  • 11

    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.

    • Patrick

      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é ?

    • Patrick

      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 !

    • Patrick

      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 !

    • 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 »

      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"

      cs_decoupe()

      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...

    • Patrick

      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

    • Patrice Vanneufville

      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

  • Regis92

    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

  • 5

    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 :

      define('_IMG_GD_MAX_PIXELS',1000000);

      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

      define(’_IMG_GD_MAX_PIXELS’,1000000) ;

      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

  • Jean-Baptiste

    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

  • 6

    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

      <?php
      @include_once dirname(__FILE__).'/ecran_securite.php';
      ?>

      Qu’est ce qui ne va pas ?

    • avais-tu deja un fichier mes_options.php dans ecrire/ ? Dans ce cas, le mieux est de le deplacer dans config/, 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

  • 7

    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

    site en travaux Attention : un problème technique (serveur SQL) empêche l’accès à cette partie du site. Merci de votre compréhension.

    (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

      Action : mise à niveau de votre base SQL
      Vous venez de mettre à jour les fichiers SPIP. Il faut maintenant mettre à niveau la base de données du site.

      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

      SPIP 2.0.9 [14402]

      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

  • 1

    Mince, j’ai encore oublié de préciser la version de spip.
    Je suis en spip 2.0.7.
    C’est la raison pour laquelle je m’interroge sur l’emplacement du fichier...

    Ma question reste donc entière

    Cordialement,

    hleb

    • mais c’est clairement expliqué sur la page http://www.spip.net/fr_article4200.html :

      déposer le fichier ecran_securite.php dans le répertoire config/ du site
      [...]
      il convient d’ajouter le code suivant dans config/mes_options.php (fichier à créer le cas échéant) : @include_once dirname(__FILE__).'/ecran_securite.php';

    Répondre à ce message

  • 1

    J’ai un doute ?
    Où faut il placer le fichier ecran_securite.php ? Dans le répertoire config ? ou à la racine du site ?

    hleb

    • en spip 2.0.9, tu as juste à déposer ecran_securite.php dans le répertoire config/ et c’est tout.

      pour tester, tu peux appeler en url http://mon_site.fr/ ?test_ecran_securite=1 (ou encore http://mon_site.fr/ ?page=sommaire&test_ecran_securite=1)

      tu devrais alors avoir l’affichage d’une page erreur :

      Error 503
      You are not authorized to view this page (test 0.8)

      « (test 0.8) » étant la preuve de l’activité de l’écran

    Répondre à ce message

  • Bonjour,

    J’ai mon php qui est un rouillé...
    -  J’ai inséré entre mes balises php de mon fichier « mes_options » la commande

     @include_once dirname(__FILE__).'/ecran_securite.php';


    -  J’ai inséré le fichier ecran_securite

    Que dois je faire maintenant pour vérifier son bon fonctionnement ?
    Si je tape http://.../spip.php echelle=<, j’obtiens une erreur 404

    Merci par avance pour votre aide

    hleb

    PS : mon site est hébergé chez free.

    Répondre à ce message

  • 1

    Bonjour,

    nous avons installé l’écran sur un serveur où il y a des versions 1.8.3b, 1.9.2g, 1.9.2h, 1.9.2i, 2.0.3 et 2.0.9 de SPIP

    J’ai essayé sur différents sites le test « spip.php ?echelle=< »

    pour les sites en version 1.9.2x ou 2.0.x, je reste sur la page d’accueil.
    pour les 1.8.3b, le fichier spip.php n’existe pas (erreur 404 classique).
    Pas de différence avec le « ?echelle=< » ou pas.

    Comment vérifier que l’écran est bien installé ?
    Merci pour l’aide !

    Répondre à ce message

  • 1

    J’ai installé 2.0.9, mais impossible d’entrer dans ecrire, pour faire la mise à jour et remettre le site en fonction. Il ne détecte pas le login, même après vérification par courriel ( pass oublié ). j’ai déjà détecté le problème en local, il suffisait de changer le début de l’adresse ( genre 127.x.x.x , alors qu’il fonctionnait sur 192.x.x.x ! ).
    Comment entrer dans l’espace privé ?
    Merci

    • A noter que je suis passer de 1.9.2d à 2.0.9

    Répondre à ce message

  • 2
    Yannick

    Bonjour,

    J’ai voulu upgrader la version 2.0.8 à la 2.0.9 via « spip_loader.php » que j’ai placé à la racine de mon site (site en local) et j’ai eu des tonnes d’erreurs du genre :
    Warning : rename(./zip_314674a81575b49421/CHANGELOG.txt,.//CHANGELOG.txt) [function.rename] : File exists in D :\...\site_spip\spip_loader.php on line 125

    Pouvez-vous me dire d’où peut venir le problème ?

    Merci

    • Bonjour, j’ai la version 2.03, savez vous si il est possible de passer directement à la 2.09

      Merci
      A+isa

    • Maïeul

      normalement oui,

      comme d’habitude, fait une sauvegarde avant

    Répondre à ce message

  • 1

    Bonjour j’ai installé l’« ecran de sécurité ».

    Lorsque je test « /spip.php ?echelle=< » j’obtient : You are not authorized to view this page (echelle)

    est-ce normal, l’écran de sécurité est-il bien installé ?

    Cordialement,

    • > Lorsque je test « /spip.php ?echelle=< » j’obtient : You are not authorized to view this page (echelle)
      > est-ce normal, l’écran de sécurité est-il bien installé ?

      Oui, c’est OK, c’est le message que j’ai aussi, et qui provient bien du fichier ecran_securite.php (ligne 151 dans mon cas).

      Le coup du No Thanks doit etre une version precedente du meme truc, j’imagine...

      A noter que j’avais le fichier mes_options.php dans le repertoire « ecrire », et le fait d’en creer un autre dans le repertoire « config » ne fonctionnait pas. Je pense que le celui du repertoire « ecrire » etait pris en compte en priorite (cf http://www.quesaco.org/Ou-placer-me...).

      J’ai donc garde le fichier mes_options.php de « config » uniquement, et ca marche.

    Répondre à ce message

  • 1
    kreaclic

    Bonjour, je viens de transférer par ftp la mise à jour pour passer de la version 2.0.8 à la 2.0.9. Ca c’est fait.
    Quand je vais sur« .../spip.php ?echelle= »
    Je reste sur la page d’accueil et ne voit pas de No Thanks.
    J’ai cherché le fichier mes_options.php dans ecrire et config mais je n’en ai visiblement pas.
    Dois-je le créer ?
    Merci

    • essaye avec ../spip.php ?echelle=<
      avec le < à la fin, j’ai installé une version 2.09 sur une 2.08 et ça marche chez moi.
      Yannick

    Répondre à ce message

  • 1

    les vieilles versions en 1.8 sont elles aussi concernées ?

    • Non, la présente faille touche du code et des fonctionnalités ajoutées sur les branches 1.9 et 2.0, et ne concerne donc pas les version 1.8 et antérieures.

      Néanmoins, il est utile de rappeler que ces versions ne sont pas exemptes de défauts de sécurité qui ont pu être corrigés lors du développement des branches récentes.

      Il est conseillé, a minima, de deployer l’ecran de sécurité sur les sites qui utilisent ces vieilles versions.

    Répondre à ce message

  • Pour les « anciennes » versionns en 1.9.2h
    j’ai extrait un diff avec la 1.9.2h ;
    mais j’ai du aussi corriger la svn et ecrire/inc-version.php
    je joins le ZIP (dé-suffixer .jpg)

    (comme l’ont fait remarquer déjà plusieurs, c’est bien pratique et rapide ; merci a TC !!)

    Répondre à ce message

  • 1

    Bonjour à tous,
    Je n’arrive pas à acceder au patch pour la branche 1.9.2x

    Merci :-)

    Répondre à ce message

  • 2
    fredomkb1

    Bonjour à tous et un grand merci pour la célérité des dev’s de Spip !!!

    Juste par curiosité, pourriez-vous, sans trop entrer dans les détails bien-sûr, nous en dire un peu plus sur la faille de sécurité et la méthode utilisée pour l’exploiter ?

    Encore merci !

    • @fredomkb1 : honnêtement, on va éviter, histoire de laisser le temps aux gens de se mettre à jour avant de se faire pwner leur site. Si ça t’amuse, regarde les commits et déduis-en ce qu’il faut en déduire

    • fredomkb1

      Oui, en effet, il vaut mieux que tout le monde soit protégé avant d’en dire d’avantage...

      Ma question n’était évidemment pas motivée par une curiosité malsaine, seulement, travaillant avec d’autres applications en ligne (forums, blogs, galeries, etc.), je voulais juste me faire une idée de l’existence éventuelle de cette faille, ou semblable, sur d’autres programmes...

      Bref, la méthode d’intrusion et de prise de contrôle utilisée par ce hacker peut s’avérer aussi dangereuse sur d’autres systèmes que SPIP, autant profiter de cette découverte pour en avertir les autres communautés de développeurs... voilà l’origine de ma démarche...

      Mais, d’accord, j’irais jeter un coup d’oeil sur les commits, histoire de m’en faire une idée...

      Merci :-)

    Répondre à ce message

  • 1

    Bonjour,

    J’ai essayé de suivre les instructions sur ce lien :

    http://www.spip.net/fr_article4200.html

    Pour moi, ma version est spip 1.9.2 et je n’ ai pas compris au niveau serveur quel répertoire est il lisible par tous le site ? en plus je ne sais pas où trouver php.ini pour le modifier !!

    merci pour votre aide.

    • jacques

      Bonjour Ahlan,

      En fait sous spip 1.9.2 il faut que :
      -  tu déposes le fichier ecran_securité.php dans le dossier config.
      -  ensuite que tu rajoutes la ligne donnée par cédric plus bas dans ton fichier mes_options.php, dans le même dossier.

      Si le fichier mes_options.php n’existe pas tu le crées : tu créées un fichier texte dans le quel tu écris

      <?php
      @include_once dirname(__FILE__).'/ecran_securite.php';
      ?>

      et tu l’enregistres sous le nom mes_options.php

      C’est comme ça que j’ai fait pour un site sous 1.9.2g et alors le test

      Lorsque l’écran de sécurité est actif, spip.php ?echelle=< doit te renvoyer un brutal « No thanks »

      fonctionne bien.

      A signaler que sous spip 2.0 je n’ai pas besoin de la ligne dans mes_options.

    Répondre à ce message

  • 3
    Manu_TJ

    Bonjour

    j’ai une dizaine de sites SPIP à migrer et je suis en congés avec une connexion d’une lenteur infinie. Pour faciliter la mise à jour aux seuls fichiers modifiés, j’ai fait un un comparatif des différents packages et j’obtiens ceci :

    -  fichiers différents entre la 1.9.2h et la 1.9.2i
    backend-breves.html dans dist
    export_all.php dans ecrire\exec
    autoriser.php dans ecrire\inc
    notifications.php dans ecrire\inc
    inc_version.php dans ecrire
    index.php dans ecrire

    -  fichiers différents entre la 2.0.8 et la 2.0.9
    charger_plugin.php dans ecrire\action
    dater.php dans ecrire\action
    editer_article.php dans ecrire\action
    editer_site.php dans ecrire\action
    tourner.php dans ecrire\action
    abstract_sql.php dans ecrire\base
    trouver_table.php dans ecrire\base
    typedoc.php dans ecrire\base
    type_urls.php dans ecrire\configuration
    accueil.php dans ecrire\exec
    admin_declarer.php dans ecrire\exec
    admin_tech.php dans ecrire\exec
    articles.php dans ecrire\exec
    articles_edit.php dans ecrire\exec
    articles_forum.php dans ecrire\exec
    articles_versions.php dans ecrire\exec
    auteur_infos.php dans ecrire\exec
    calendrier.php dans ecrire\exec
    controle_forum.php dans ecrire\exec
    export_all.php dans ecrire\exec
    install.php dans ecrire\exec
    naviguer.php dans ecrire\exec
    rubriques_edit.php dans ecrire\exec
    agenda.php dans ecrire\inc
    ajouter_documents.php dans ecrire\inc
    article_select.php dans ecrire\inc
    autoriser.php dans ecrire\inc
    charsets.php dans ecrire\inc
    dater.php dans ecrire\inc
    diff.php dans ecrire\inc
    distant.php dans ecrire\inc
    documenter_objet.php dans ecrire\inc
    documents.php dans ecrire\inc
    editer.php dans ecrire\inc
    editer_mots.php dans ecrire\inc
    export.php dans ecrire\inc
    filtres.php dans ecrire\inc
    filtres_images.php dans ecrire\inc
    filtres_mini.php dans ecrire\inc
    forum_insert.php dans ecrire\inc
    headers.php dans ecrire\inc
    import.php dans ecrire\inc
    install.php dans ecrire\inc
    invalideur.php dans ecrire\inc
    lien.php dans ecrire\inc
    math.php dans ecrire\inc
    meta.php dans ecrire\inc
    minipres.php dans ecrire\inc
    modifier.php dans ecrire\inc
    nfslock.php dans ecrire\inc
    notes.php dans ecrire\inc
    plugin.php dans ecrire\inc
    prepare_recherche.php dans ecrire\inc
    presentation.php dans ecrire\inc
    presenter_liste.php dans ecrire\inc
    rechercher.php dans ecrire\inc
    revisions.php dans ecrire\inc
    rubriques.php dans ecrire\inc
    syndic.php dans ecrire\inc
    texte.php dans ecrire\inc
    utils.php dans ecrire\inc
    etape_sup2.php dans ecrire\install
    HTMLSax3.php dans ecrire\lib\safehtml\classes
    safehtml.php dans ecrire\lib\safehtml\classes
    svn10000.php dans ecrire\maj
    aiguiller.php dans ecrire\public
    assembler.php dans ecrire\public
    balises.php dans ecrire\public
    boucles.php dans ecrire\public
    compiler.php dans ecrire\public
    criteres.php dans ecrire\public
    interfaces.php dans ecrire\public
    phraser_html.php dans ecrire\public
    quete.php dans ecrire\public
    stats.php dans ecrire\public
    styliser.php dans ecrire\public
    mysql.php dans ecrire\req
    pg.php dans ecrire\req
    sqlite_generique.php dans ecrire\req
    inc_version.php dans ecrire
    index.php dans ecrire
    public.php dans ecrire
    editer_rubrique.html dans prive\formulaires
    login.php dans prive\formulaires
    ajaxCallback.js dans prive\javascript
    text.html dans prive\modeles
    forums.html dans prive\rss
    forums_interne.html dans prive\rss
    forums_prop.html dans prive\rss
    forums_public.html dans prive\rss
    forums_spam.html dans prive\rss
    forums_vide.html dans prive\rss
    statistiques.html dans prive\transmettre
    statistiques_article.html dans prive\transmettre
    style_prive.html dans prive
    style_prive_formulaires.html dans prive
    ecrire_auteur.php dans squelettes-dist\formulaires
    forum.php dans squelettes-dist\formulaires
    engines-list.txt dans squelettes-dist
    favicon.ico.html dans squelettes-dist
    ical.html dans squelettes-dist
    recherche.html dans squelettes-dist

    Qui peut me confirmer que ces listes sont correctes pour que je puisse lancer le correctif au plus vite ?

    Merci pour votre aide et bravo pour votre réactivité en plein milieu de la période estivale :)

    Manu

    • Déesse A.

      D’abord il faut savoir que la gravité sur la 1.9.2 est nettement moindre que sur la 2.0. Ensuite, la modification du seul fichier ecrire/index.php devrait suffire.

    • Shnoulle

      Tu peut peut être utiliser spip_loader.php, ta connexion sera peut utilisée.

    • Matthieu Marcillaud

      Le zip ci contre donne uniquement les fichiers modifiés entre 2.0.8 et 2.0.9 (Trac, quel outil puissant !) :
      Zip des modifications

    Répondre à ce message

  • Eric, je pense que c’est quand même bon, car je viens de la faire et je suis comme toi.
    Par contre, perso, j’ai pas utiliser « spip_loader », j’ai tout envoyer par FTP

    Sinon, j’ai suivi les instruction à la lettre ici :
    http://www.spip.net/fr_article1318.html

    Cela doit être une ancienne façon de faire, car j’ai pas eu « d’écran d’authentification par FTP »
    J’ai eu un message à propos de mettre la base à jour et puis c’est tout.

    J’ai dû faire comme il fallait, car le site semble être ok, mais je le signal quand même, pour les prochains qui feront la mise à jour et qui comme moi, débute :-)

    Répondre à ce message

  • mtfkarukera

    Merci les gars ! C’est sûr, comme dit Manu T, cette réactivité est impressionnante.

    Big up !

    Répondre à ce message

  • Bonjour,

    Je viens d’effectuer la mise à jour 2.0.8 vers 2.0.9 mais dans le bas de page de l’espace privé cela m’affiche :

    SPIP 2.0.9 [13982]

    13982 est la révision de la 2.0.8 non ?

    De plus le fichier CHANGELOG.txt ne contient pas les changements 2.0.8 - 2.0.9

    Merci

    Répondre à ce message

  • 1
    .Gilles

    Il me semble avoir lu qu’il suffit d’enlever les droits d’écriture dans le répertoire /config/ et tous les fichiers qu’il contient.

    Donc en attendant de faire de mise à jour, en risquant de planter les plugins, n’est-ce pas la première opération à recommander ?

    • marcimat

      Je crois que ce n’est justement pas suffisant, ne corrigeant qu’un des deux problèmes remontés.

    Répondre à ce message

  • 1

    J’ai un site sous cette version, et j’avoue ne pas vouloir le mettre à jour si c’est possible..

    Est-ce que cette faille de sécurité le concerne ?

    • Non, cette faille ne concerne pas la version 1.8.3.
      Mais tu devrais utiliser l’écran de sécurité car cette version contient d’autres défauts non corrigeables et bouchés par l’écran.

    Répondre à ce message

  • 2

    Bonjour,
    au secours !! Je viens d’appliquer le correctif comme d’habitude, mais quand je tape l’adresse de notre site : www.sudeducalsace.info, je n’ai plus qu’une page complètement blanche sans aucun message d’erreur par ailleurs (j’ai vidé le cache de mon butineur).
    Merci d’avance, Giampiero Russo

    • Loiseau2nuit

      Quel correctif ? Upgrade de SPIP ou Ecran de sécu ???

    • nico4peace

      tu as vidé de dossier tmp ?

    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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

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.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom