Mise à jour CRITIQUE de sécurité - Sortie de SPIP 3.1.1, SPIP 3.0.22 et SPIP 2.1.29

Deux failles de sécurité ont été découvertes récemment dans SPIP :
- une faille critique permettant l’injection de code PHP (merci à g0uZ et sambecks, team root-me)
- une faille secondaire permettant l’injection d’objets par unserialize (merci à Gilles Vincent)

Ces failles sont sérieuses et affectent toutes les versions de SPIP.
Il est impératif de mettre à jour votre site SPIP dès que possible.

Pour les sites qui ne peuvent pas être immédiatement mis à jour,
il est nécessaire d’installer la version 1.2.4 de l’écran de sécurité qui corrige la faille critique
http://www.spip.net/fr_article4200.html

Lire l’annonce complète sur le blog
https://blog.spip.net/789

Bonjour

Nous avons examiné votre suspicion de faille.

Toutefois, nous n’arrivons pas à reproduire l’injection décrite.

Inline
          image 1

A priori c’est donc un mauvais signalement de votre logiciel

Toutefois si vous avez des détails techniques sur l’attaque,
n’hésitez pas à nous la faire parvenir sur Cordialement

Cette réponse n’est absolument pas satisfaisante à mon avis.

Le « ça fonctionne chez moi » ne suffit pas pour dire que c’est un faux positif : il y a plein de failles remontées lors de mon audit avec HP Fortify que je n’ai jamais pu reproduire pour moult raisons (il faut un navigateur qui a des bugs de moteur d’analyse spécifiques, un serveur qui soit configuré sur un environnement donné, etc…)

Il faut pouvoir prouver qu’on a suffisamment verrouillé le paramètre ?page= pour qu’il n’y ait pas d’injection possible (même face à un post envoyé avec un encodage utf7 – malheureusement supporté par quelques serveurs – et plein de \0 par exemple)

Une première approche est déjà de préciser que l’écran de sécurité est désormais intégré à SPIP, ce qui n’est pas le cas des deux versions signalées - et qu’un utilisateur ne peut plus ne pas l’installer avec SPIP. Donc peut-être que le test qui déclenche l’erreur xsspage suffit ici à protéger une injection SQL.

Ce qui est dommage c’est que l’outil d’audit ne donne que la manifestation externe de la faille potentielle qui a été détectée, mais ne précise pas à quel endroit du code source (et son chemin d’exécution) est-ce que cette injection va précisément se produire (ce que fait HP Fortify). C’est certainement ce contexte qu’il faudrait demander - éventuellement à voir avec les développeurs du produit d’audit.

Cela me fait penser qu’on devrait nous aussi avoir un outils d’audit qu’on utilise en interne qui tourne sur SPIP, mais aussi sur les plugins qui sont souvent de vrai passoire (je pense particulièrement à skeleditor, mais il ne doit pas être le seul). En connaissez-vous un qui retourne moins de faux positifs que HP Fortify, qui puisse faire de l’analyse de code ET de l’étude de site en fonctionnement réel, tout en restant abordable pour nous (donc, vu notre fonctionnement, qui reste gratuit à moins que vous ayiez des pistes… ) ?

Il est important, me semble-t-il, de pouvoir anticiper les remontées de failles qui peut être un énorme problème (cf. la faille remontée avec son exploit pour la création d’un compte administrateur)

Qu’en dites-vous ?

.Gilles

Gilles Vincent a écrit :

Cette réponse n'est absolument pas satisfaisante à mon avis.

Le "ça fonctionne chez moi" ne suffit pas pour dire que c'est un faux
positif : il y a plein de failles remontées lors de mon audit avec HP
Fortify que je n'ai jamais pu reproduire pour moult raisons (il faut un
navigateur qui a des bugs de moteur d'analyse spécifiques, un serveur
qui soit configuré sur un environnement donné, etc..)

Il faut pouvoir prouver qu'on a suffisamment verrouillé le paramètre
?page= pour qu'il n'y ait pas d'injection possible (même face à un post
envoyé avec un encodage utf7 -- malheureusement supporté par quelques
serveurs -- et plein de \0 par exemple)

Une première approche est déjà de préciser que l'écran de sécurité est
désormais intégré à SPIP, ce qui n'est pas le cas des deux versions
signalées - et qu'un utilisateur ne peut plus ne pas l'installer avec
SPIP. Donc peut-être que le test qui déclenche l'erreur xsspage suffit
ici à protéger une injection SQL.

Si tu lis l'email qui signale la faille, l'utilisateur indique bien qu'il a l'écran de sécurité installé sur ses 2 SPIPs, cela légitime qu'on teste dans les mêmes conditions.

Par ailleurs si l'utilisateur ne fournit pas le modus operandi pour reproduire la faille c'est un peu compliqué... A ce compte là on peut passer beaucoup de temps à pister des failles imaginaires.

Ce qui est dommage c'est que l'outil d'audit ne donne que la
manifestation externe de la faille potentielle qui a été détectée, mais
ne précise pas à quel endroit du code source (et son chemin d'exécution)
est-ce que cette injection va précisément se produire (ce que fait HP
Fortify). C'est certainement ce contexte qu'il faudrait demander -
éventuellement à voir avec les développeurs du produit d'audit.

Cela me fait penser qu'on devrait nous aussi avoir un outils d'audit
qu'on utilise en interne qui tourne sur SPIP, mais aussi sur les plugins
qui sont souvent de vrai passoire (je pense particulièrement à
skeleditor, mais il ne doit pas être le seul).

Passoire toi même !
SkelEditor est un plugin qui par principe permet de modifier les sources du site, donc d'introduire n'importe quelle attaque. A ce titre il est un vecteur potentiel pour quiconque usurpe les droits de webmestre sur le site, en effet.
En l'occurence ce n'est pas une faille, mais une feature, par construction, à utiliser avec clairvoyance.

Tu parles de passoire, ce qui sous-entends que tu as identifié des failles du plugin exploitables sans être webmestre sur le site qui utilise le plugin ?
Tu as fais un signalement ? Tu as proposé un patch ?

Cédric

2016-09-22 12:01 GMT+02:00 Cédric Morin <cedric@yterium.com>:

Cela me fait penser qu'on devrait nous aussi avoir un outils d'audit

qu'on utilise en interne qui tourne sur SPIP, mais aussi sur les plugins
qui sont souvent de vrai passoire (je pense particulièrement à
skeleditor, mais il ne doit pas être le seul).

Passoire toi même !
SkelEditor est un plugin qui par principe permet de modifier les sources
du site, donc d'introduire n'importe quelle attaque. A ce titre il est un
vecteur potentiel pour quiconque usurpe les droits de webmestre sur le
site, en effet.
En l'occurence ce n'est pas une faille, mais une feature, par
construction, à utiliser avec clairvoyance.

Ce n'était pas le problème

Tu parles de passoire, ce qui sous-entends que tu as identifié des failles
du plugin exploitables sans être webmestre sur le site qui utilise le
plugin ?
Tu as fais un signalement ? Tu as proposé un patch ?

Je n'ai pas fais de signalement, ni proposé de patch. J'ai manqué de temps
et j'étais tellement dans la partie SPIP que lors de l'analyse on avait
fini par virer le plugin qui remontait trop de failles potentielles alors
qu'il n'aurait pas dû rester en prod.
De mémoire il y avait des trucs graves.

Je vais m'en occuper asap sachant que je n'aurais qu'une partie des
éléments qu'on avait détecté avant d'abandonner.
Cela dit, c'est aussi peut-être lié au mode d'analyse du code source par
Fortify : 1/4 des failles potentielles remontées était liées à ce plugin.
Cela semble vraiment exagéré, mais c'est peut-être simplement qu'il se
débrouille mieux avec le code du plugin qui est plus éloigné de l'API de
SPIP. Et Fortify remonte quand même plus de 95% de faux positifs en analyse
de code statique. Tous revus à la main, c'est super long.

Cédric

pour en revenir à ce rapport de type audit sur comportement, ce que je ne comprends pas c’est comment le payload déclaré peut avoir déclenché l’erreur xsspage de l’écran de sécurité.

2016-09-22 12:46 GMT+02:00 Gilles Vincent <gilles.vincent@gmail.com>:

pour en revenir à ce rapport de type audit sur comportement, ce que je ne
comprends pas c'est comment le payload déclaré peut avoir déclenché
l'erreur xsspage de l'écran de sécurité.

if ($_REQUEST['page'] !== htmlspecialchars((string)$_REQUEST['page']))
$ecran_securite_raison = "xsspage";

probablement le guillemet.

-- Fil

Avec une telle adresse c’est normal qu’on ait la page d’accueil

?lang=fr?page=…

=> la second attribut n’est pas pris en compte

?lang=fr&page=…

C’est autre chose, l’écran de sécurité fait son rôle et bloque tout appel mysql. il ne peut donc pas y avoir d’injection SQL dans ce cas précis.

Je suis le seul que ça dérange le nom de votre outil ?

Apparemment pas : https://twitter.com/quentin_ecce/status/634318377838870528

Je ne m’en prends pas à vous personnellement, mais je trouve que la promotion de la culture du viol devrait être prohibée, et ce serait bien de faire remonter l’observation à RENATER. Merci.

Jean-Daniel Tissot a écrit :

Alors pourquoi le rapport d'IKare révèle une vulnérabilité.
Je vais tester avec Kali Linux + OpenVas
(https://www.kali-linux.fr/scan/installation-et-utilisation-openvas)

Comme tout outil automatique, c'est un outil d'aide, qui permet de déblayer le terrain et de faire ressortir des cas intéressants parmi des centaines/milliers de possibilités.

Ce n'est jamais à prendre au pied de la lettre et necessite une analyse humaine/manuelle a posteriori pour determiner si l'erreur suspectée est un cas réel de faille ou non.

En l'occurence ici l'outil envoie une requete mal formée. Je ne sais pas si c'est une erreur/un bug de l'outil, ou si il attends que le site renvoie une erreur à la place d'une réponse 200 à ce type de requête mal fichue. Mais en effet je ne vois pas en quoi cela lui permettrait de déduire une faille sur cette base.

Le signalement est ici d'autant plus suspect que le parametre 'page' n'est jamais utilisé dans le core pour alimenter une requete SQL, uniquement pour faire une recherche de fichier sur le disque.
(mais on ne peut pas préjuger de ce qui est fait dans votre squelette ou sur le site concerné)

--
Cédric

Moi j’en déduis que c’est un faux positif. basta. On en parle plus