Bonjour,
Trouvé sur le site du CNRS, le n°4 de la revue "Sécurité informatique"
(http://www.sg.cnrs.fr/FSD/securite-systemes/revue.htm) consacre un
numéro à SPIP (pdf) :
http://www.sg.cnrs.fr/FSD/securite-systemes/revues-pdf/si4.pdf
S
* stef dn tapuscrivait, le 09/04/2009 13:52:
Bonjour,
Trouvé sur le site du CNRS, le n°4 de la revue "Sécurité informatique"
(http://www.sg.cnrs.fr/FSD/securite-systemes/revue.htm) consacre un
numéro à SPIP (pdf) :
http://www.sg.cnrs.fr/FSD/securite-systemes/revues-pdf/si4.pdf
La conclusion : « Comme il y a des enjeux financiers, nous sommes convaincus qu’il reviendra, SPIP étant une vraie passoire même avec la
dernière version. »
n'est pas très rassurante...
mais pas très étayée non plus, l’essentiel de l’article étant un reportage live sur comment ces messieurs ont passé leur temps à écoper derrière un hacker qu’ils avaient laissé entrer avec une porte grande ouverte sur le serveur.
Cédric
mais pas très étayée non plus, l'essentiel de l'article étant un reportage
live sur comment ces messieurs ont passé leur temps à écoper derrière un
hacker qu'ils avaient laissé entrer avec une porte grande ouverte sur le
serveur.
Cédric
tu sous entends que la porte était vraiment grande grande ouverte et que
spip ou joomla même combat ?
S'lt
On peut retrouver ses commits :
http://trac.rezo.net/trac/spip/changeset/13867
http://trac.rezo.net/trac/spip/changeset/13869
http://trac.rezo.net/trac/spip/changeset/13857
Km
* Cédric Morin tapuscrivait, le 09/04/2009 14:27:
* stef dn tapuscrivait, le 09/04/2009 13:52:
Bonjour,
Trouvé sur le site du CNRS, le n°4 de la revue "Sécurité informatique"
(http://www.sg.cnrs.fr/FSD/securite-systemes/revue.htm) consacre un
numéro à SPIP (pdf) :
http://www.sg.cnrs.fr/FSD/securite-systemes/revues-pdf/si4.pdfLa conclusion : « Comme il y a des enjeux financiers, nous sommes
convaincus qu’il reviendra, SPIP étant une vraie passoire même avec la
dernière version. »
n'est pas très rassurante...mais pas très étayée non plus, l'essentiel de l'article étant un reportage
live sur comment ces messieurs ont passé leur temps à écoper derrière un
hacker qu'ils avaient laissé entrer avec une porte grande ouverte sur le
serveur.
Certes.
Ils avaient d'abord laissé un accès à tmp/ de SPIP.
Et avouent eux-même qu'ils ont pleins de .php3 qui datent de vieux squelettes...
Mais ça vaudrait peut-être la peine de les contacter pour qu'ils puissent expliquer à la team en off les failles qu'ils estiment avoir trouvées...
Peut être que les gens de la team sont des grands garçons qui ont déjà fait le nécessaire car ils connaissaient ce document avant …
Une lecture attentive comparée aux commits récents devrait te donner la réponse !
Cédric
* Cédric Morin tapuscrivait, le 09/04/2009 14:39:
De : Cédric Morin [mailto:cedric.morin@yterium.com]
Envoyé : jeudi 9 avril 2009 14:27
À : RealET
Cc : spip-dev@rezo.net
Objet : Re: [spip-dev] connaissez-vous Vlad ?mais pas très étayée non plus, l’essentiel de l’article étant un reportage live sur comment ces messieurs ont passé leur temps à écoper derrière un hacker qu’ils avaient laissé entrer avec une porte grande ouverte sur le serveur.
Oui, mais est-ce que par exemple on fait quelque chose contre le comportement d’apache qui va executer comme fichier php un toto.php.tata ?
Oui, mais est-ce que par exemple on fait quelque chose contre le
comportement d'apache qui va executer comme fichier php un toto.php.tata ?
C'est vraiment pas à SPIP de régler les problèmes de sécurité
d'apache, sinon où va-t-on.
Cela dit si tu as une URL je suis preneur
-- Fil
salut,
On peut retrouver ses commits :
http://trac.rezo.net/trac/spip/changeset/1385"Enfin, il faudrait insister dans la doc sur le fait que tmp/ et config/ doivent être interdits à la lecture publique, idéalement en les mettant à l'extérieur du DocumentRoot"
il faut faire comment ?
un changement dans un fichier de SPIP, j'imagine ?
du genre :
$rep_tmp = "../tmp" ;
$rep_tmp = "../config" ;
je pose la question car en formation demain je compte aborder ce sujet
avec les stagiaires (dev. web) pour insister sur leur rôle dans l'usage
d'outil comme SPIP (mise à jour + suivit de listes) et dans le
développement de script PHP.
a+
^Fabrice^^
Ce que je trouve dommage c'est qu'Apache ne permette pas facilement d'interroger son comportement.
En l'occurrence, le pb est que "tata" est une extension indiquant un fichier sans risque,
mais que l'installation d'Apache ne la connaissait pas, et du coup il s'est rabattu sur le ".php".
Si SPIP pouvait savoir les extensions acceptées par la config d'Apache en cours,
il pourrait restreindre ses propres acceptations.
Mais à part réécrire un interprète des fichiers de config d'Apache, je ne crois pas qu'il soit possible de savoir ça.
Committo,Ergo:Sum
Committo,Ergo:sum a écrit :
Mais à part réécrire un interprète des fichiers de config d'Apache, je ne crois pas qu'il soit possible de savoir ça.
c'est peut être possible en testant systématiquement toutes les extensions
comme avec les tailles max pour les image
genre pour toute extension ext acceptée par spip dans un contexte donné,
écrire un fichier jeteste.php.ext
avec dedans <?php crée un fichier 'pinponpinpon.txt' ?>
appeler le fichier par son url
et tester ensuite la présence du fichier pinpon :
s'il est là c'est que apache ignore ext et a exécuté le php...
(mais c'est plutôt apache qui devrait arrêter de faire ça...)
JL
s'il est là c'est que apache ignore ext et a exécuté le php...
(mais c'est plutôt apache qui devrait arrêter de faire ça...)
On a une solution avec un .htaccess dans IMG/ qui dirait
SetHandler _NO_NO_NO_
-- Fil
mais on retombe sur le pb que certaines instal' d'Apache ignore les .htacces systématiquement.
Committo,Ergo:Sum
s'il est là c'est que apache ignore ext et a exécuté le php...
(mais c'est plutôt apache qui devrait arrêter de faire ça...)On a une solution avec un .htaccess dans IMG/ qui dirait
SetHandler _NO_NO_NO_mais on retombe sur le pb que certaines instal' d'Apache ignore les .htacces
systématiquement.
Oui, mais là, aucun CMS ne peut faire quelquechose.
Ce ne paut pas être le problème de SPIP.
De plus, l'utilisation des php_flags etc ... peut poser problème sur
certains serveur (serveurs avec suphp notamment).
Rendre incompatible spip pour qu'il soit sécurisé sur certaines
version d'apache ?
Committo,Ergo:Sum
_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip
Bon courage !
Committo,Ergo:sum a écrit :
[...]
Ce que je trouve dommage c'est qu'Apache ne permette pas facilement
d'interroger son comportement.
En l'occurrence, le pb est que "tata" est une extension indiquant un
fichier sans risque,
mais que l'installation d'Apache ne la connaissait pas, et du coup il
s'est rabattu sur le ".php".
[...]
Bonjour,
je n'ai pas bien compris.
Est ce que placer un fichier php avec une extension supplémentaire
inconue (donc connue comme étant sans risque???) provoque ce genre
de chose?
Normalement, dans Apache, on précise les extensions qui sont
utilisées...
Si c'est un problème d'Apache, je suis très déçu par Apache.
A bientôt
Grégoire
S'lt
Dans le cas de toto.php.tata, ce n'est pas en soit un bogue :
http://httpd.apache.org/docs/1.3/mod/mod_mime.html#multipleext
Apache considère qu'il existe 2 extensions tata et php, du coup php
étant connu et autorisé il pourra interpréter le fichier.
Km
-----Message d'origine-----
De : recifs@gmail.com [mailto:recifs@gmail.com] De la part de Fil
Envoyé : jeudi 9 avril 2009 21:17
À : Olivier GENDRIN
Cc : Cédric Morin; RealET; spip-dev@rezo.net
Objet : Re: [spip-dev] connaissez-vous Vlad ?> Oui, mais est-ce que par exemple on fait quelque chose contre le
> comportement d'apache qui va executer comme fichier php un
toto.php.tata ?C'est vraiment pas à SPIP de régler les problèmes de sécurité
d'apache, sinon où va-t-on.
Cela dit si tu as une URL je suis preneur
Les urls ont été données, mais un simple str_replace('.php','_php',$chaine)
ferrait l'affaire.
Les urls ont été données, mais un simple
str_replace('.php','_php',$chaine)
ferrait l'affaire.
Au temps pour moi, je n'avais pas vu r13881.