Quels sont les risques de sécurités connus si on utilise plusieurs
VHosts avec plusieurs "oscommerce" dessus?
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Le Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno a écrit :
Quels sont les risques de sécurités connus si on utilise plusieurs VHosts avec plusieurs "oscommerce" dessus? rien si on prends la peine de faire tourner php en suexec :)
Va falloir aussi gérer les certificats (commerce en ligne => SSL) et donc ne pas faire de vhost par nom, mais par IP.
-- DV: Depuis que j'ai enregistré MacSoup, il arrête pas de geler. GC: Attends le printemps. -+- GV in Guide du Macounet Pervers : faites chauffer MacSoup ! -+-
Le Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno a écrit :
Quels sont les risques de sécurités connus si on utilise plusieurs
VHosts avec plusieurs "oscommerce" dessus?
rien si on prends la peine de faire tourner php en suexec :)
Va falloir aussi gérer les certificats (commerce en ligne => SSL) et donc
ne pas faire de vhost par nom, mais par IP.
--
DV: Depuis que j'ai enregistré MacSoup, il arrête pas de geler.
GC: Attends le printemps.
-+- GV in Guide du Macounet Pervers : faites chauffer MacSoup ! -+-
Le Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno a écrit :
Quels sont les risques de sécurités connus si on utilise plusieurs VHosts avec plusieurs "oscommerce" dessus? rien si on prends la peine de faire tourner php en suexec :)
Va falloir aussi gérer les certificats (commerce en ligne => SSL) et donc ne pas faire de vhost par nom, mais par IP.
-- DV: Depuis que j'ai enregistré MacSoup, il arrête pas de geler. GC: Attends le printemps. -+- GV in Guide du Macounet Pervers : faites chauffer MacSoup ! -+-
rien si on prends la peine de faire tourner php en suexec :)
J'ai trouvé plein de liens interessant à ce sujet sur le net. T'en as pas un plus interessants que les autres pour sa mise en oeuvre dans tes bookmarks, s'il te plait? :-)
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
rien si on prends la peine de faire tourner php en suexec :)
J'ai trouvé plein de liens interessant à ce sujet sur le net.
T'en as pas un plus interessants que les autres pour sa mise en oeuvre
dans tes bookmarks, s'il te plait? :-)
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
rien si on prends la peine de faire tourner php en suexec :)
J'ai trouvé plein de liens interessant à ce sujet sur le net. T'en as pas un plus interessants que les autres pour sa mise en oeuvre dans tes bookmarks, s'il te plait? :-)
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Erwann ABALEA
On Sat, 19 Feb 2005, Cedric Blancher wrote:
Le Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno a écrit :
Quels sont les risques de sécurités connus si on utilise plusieurs VHosts avec plusieurs "oscommerce" dessus? rien si on prends la peine de faire tourner php en suexec :)
Va falloir aussi gérer les certificats (commerce en ligne => SSL) et donc ne pas faire de vhost par nom, mais par IP.
Ou alors être fort et demander un certificat comportant une extension subjectAltName multivaluée (1 dnsName par vhost). Je ne connais pas d'AC publique qui puisse émettre ce genre de certif.
En dernier recours, un certificat wildcard, certains en vendent encore.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- If at first you don't succeed; Blame everyone else
On Sat, 19 Feb 2005, Cedric Blancher wrote:
Le Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno a écrit :
Quels sont les risques de sécurités connus si on utilise plusieurs
VHosts avec plusieurs "oscommerce" dessus?
rien si on prends la peine de faire tourner php en suexec :)
Va falloir aussi gérer les certificats (commerce en ligne => SSL) et donc
ne pas faire de vhost par nom, mais par IP.
Ou alors être fort et demander un certificat comportant une extension
subjectAltName multivaluée (1 dnsName par vhost). Je ne connais pas d'AC
publique qui puisse émettre ce genre de certif.
En dernier recours, un certificat wildcard, certains en vendent encore.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
If at first you don't succeed; Blame everyone else
Le Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno a écrit :
Quels sont les risques de sécurités connus si on utilise plusieurs VHosts avec plusieurs "oscommerce" dessus? rien si on prends la peine de faire tourner php en suexec :)
Va falloir aussi gérer les certificats (commerce en ligne => SSL) et donc ne pas faire de vhost par nom, mais par IP.
Ou alors être fort et demander un certificat comportant une extension subjectAltName multivaluée (1 dnsName par vhost). Je ne connais pas d'AC publique qui puisse émettre ce genre de certif.
En dernier recours, un certificat wildcard, certains en vendent encore.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- If at first you don't succeed; Blame everyone else
Christophe Casalegno
Rakotomandimby (R12y) Mihamina wrote:
J'ai trouvé plein de liens interessant à ce sujet sur le net. T'en as pas un plus interessants que les autres pour sa mise en oeuvre dans tes bookmarks, s'il te plait? :-)
J'ai ma façon à moi, celles décrites sur le net ne me convenant pas du tout (des tas de fichiers modifiés alors qu'il suffit de 5 lignes dans le suexec.c).
Je veux bien t'expliquer ma méthode, mais cela dépasse le contexte de ce forum.
On peut arranger çà avec un petit dial irc, tu as mon adresse email :)
J'ai trouvé plein de liens interessant à ce sujet sur le net.
T'en as pas un plus interessants que les autres pour sa mise en oeuvre
dans tes bookmarks, s'il te plait? :-)
J'ai ma façon à moi, celles décrites sur le net ne me convenant pas du tout
(des tas de fichiers modifiés alors qu'il suffit de 5 lignes dans le
suexec.c).
Je veux bien t'expliquer ma méthode, mais cela dépasse le contexte de ce
forum.
On peut arranger çà avec un petit dial irc, tu as mon adresse email :)
J'ai trouvé plein de liens interessant à ce sujet sur le net. T'en as pas un plus interessants que les autres pour sa mise en oeuvre dans tes bookmarks, s'il te plait? :-)
J'ai ma façon à moi, celles décrites sur le net ne me convenant pas du tout (des tas de fichiers modifiés alors qu'il suffit de 5 lignes dans le suexec.c).
Je veux bien t'expliquer ma méthode, mais cela dépasse le contexte de ce forum.
On peut arranger çà avec un petit dial irc, tu as mon adresse email :)
Le Sun, 20 Feb 2005 10:11:16 +0000, Erwann ABALEA a écrit :
Ou alors être fort et demander un certificat comportant une extension subjectAltName multivaluée (1 dnsName par vhost). Je ne connais pas d'AC publique qui puisse émettre ce genre de certif. En dernier recours, un certificat wildcard, certains en vendent encore.
Ça pose quand même un problème. Dans ce cas d'un hébergeur, le propriétaire du site n'est pas le propriétaire du certificat présenté au client. C'est pas top sain je trouve.
-- BOFH excuse #298:
Not enough interrupts
Le Sun, 20 Feb 2005 10:11:16 +0000, Erwann ABALEA a écrit :
Ou alors être fort et demander un certificat comportant une extension
subjectAltName multivaluée (1 dnsName par vhost). Je ne connais pas d'AC
publique qui puisse émettre ce genre de certif.
En dernier recours, un certificat wildcard, certains en vendent encore.
Ça pose quand même un problème. Dans ce cas d'un hébergeur, le
propriétaire du site n'est pas le propriétaire du certificat présenté
au client. C'est pas top sain je trouve.
Le Sun, 20 Feb 2005 10:11:16 +0000, Erwann ABALEA a écrit :
Ou alors être fort et demander un certificat comportant une extension subjectAltName multivaluée (1 dnsName par vhost). Je ne connais pas d'AC publique qui puisse émettre ce genre de certif. En dernier recours, un certificat wildcard, certains en vendent encore.
Ça pose quand même un problème. Dans ce cas d'un hébergeur, le propriétaire du site n'est pas le propriétaire du certificat présenté au client. C'est pas top sain je trouve.
-- BOFH excuse #298:
Not enough interrupts
Nicob
On Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno wrote:
rien si on prends la peine de faire tourner php en suexec :)
Pas d'accord. Si le code PHP est troué, l'attaquant gagne tout de même les droits correspondants à l'utilisateur lié au vhost. Ce qui peut lui servir à accéder au code source et au login/passwd de la base de données.
Par ailleurs, l'appli peut permettre par elle-même un accès complet aux données, suExec ou pas (faille de SQL-Injection).
Dans le cas contraire : les mêmes risques que pour toute application php tournant avec les droits d'apache.
Pas d'accord non plus ;-) Ca reviendrait à dire que les risques sont les mêmes avec vsftpd qu'avec wu-ftpd, vu que ce sont tous deux des serveurs FTP en C. Heureusement, ce n'est parceque l'appli est en PHP au dessus d'Apache qu'elle sera trouable ...
C'est comme partout : respect des bonnes pratiques, conception sécurisée, étude des risques spécifiques au langage, formation et sensibilisation des développeurs, revue de code ...
Nicob
On Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno wrote:
rien si on prends la peine de faire tourner php en suexec :)
Pas d'accord. Si le code PHP est troué, l'attaquant gagne tout de même
les droits correspondants à l'utilisateur lié au vhost. Ce qui peut lui
servir à accéder au code source et au login/passwd de la base de
données.
Par ailleurs, l'appli peut permettre par elle-même un accès
complet aux données, suExec ou pas (faille de SQL-Injection).
Dans le cas contraire : les mêmes risques que pour toute application
php tournant avec les droits d'apache.
Pas d'accord non plus ;-) Ca reviendrait à dire que les risques sont les
mêmes avec vsftpd qu'avec wu-ftpd, vu que ce sont tous deux des serveurs
FTP en C. Heureusement, ce n'est parceque l'appli est en PHP au dessus
d'Apache qu'elle sera trouable ...
C'est comme partout : respect des bonnes pratiques, conception
sécurisée, étude des risques spécifiques au langage, formation et
sensibilisation des développeurs, revue de code ...
On Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno wrote:
rien si on prends la peine de faire tourner php en suexec :)
Pas d'accord. Si le code PHP est troué, l'attaquant gagne tout de même les droits correspondants à l'utilisateur lié au vhost. Ce qui peut lui servir à accéder au code source et au login/passwd de la base de données.
Par ailleurs, l'appli peut permettre par elle-même un accès complet aux données, suExec ou pas (faille de SQL-Injection).
Dans le cas contraire : les mêmes risques que pour toute application php tournant avec les droits d'apache.
Pas d'accord non plus ;-) Ca reviendrait à dire que les risques sont les mêmes avec vsftpd qu'avec wu-ftpd, vu que ce sont tous deux des serveurs FTP en C. Heureusement, ce n'est parceque l'appli est en PHP au dessus d'Apache qu'elle sera trouable ...
C'est comme partout : respect des bonnes pratiques, conception sécurisée, étude des risques spécifiques au langage, formation et sensibilisation des développeurs, revue de code ...
Nicob
Christophe Casalegno
Nicob wrote:
On Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno wrote:
rien si on prends la peine de faire tourner php en suexec :)
Pas d'accord. Si le code PHP est troué, l'attaquant gagne tout de même les droits correspondants à l'utilisateur lié au vhost. Ce qui peut lui servir à accéder au code source et au login/passwd de la base de données.
La question était la suivante :
Quels sont les risques de sécurités connus si on utilise plusieurs VHosts avec plusieurs "oscommerce" dessus?
Ce qui me parait demander les risques vis à vis des différentes instances d'oscommerce entres elles, en suexec il n'y en a pas.
Par ailleurs, l'appli peut permettre par elle-même un accès complet aux données, suExec ou pas (faille de SQL-Injection).
Toujours pareil je répondais par rapport au contexte : plusieurs instances plusieurs bases pas de propagation des risques.
Dans le cas contraire : les mêmes risques que pour toute application php tournant avec les droits d'apache.
Pas d'accord non plus ;-) Ca reviendrait à dire que les risques sont les mêmes avec vsftpd qu'avec wu-ftpd, vu que ce sont tous deux des serveurs FTP en C. Heureusement, ce n'est parceque l'appli est en PHP au dessus d'Apache qu'elle sera trouable ...
Si le risque de corruption est différent il ne cesse jamais d'exister, le risque AVEC corruption est exactement le même quelque soit l'application.
On Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno wrote:
rien si on prends la peine de faire tourner php en suexec :)
Pas d'accord. Si le code PHP est troué, l'attaquant gagne tout de même
les droits correspondants à l'utilisateur lié au vhost. Ce qui peut lui
servir à accéder au code source et au login/passwd de la base de
données.
La question était la suivante :
Quels sont les risques de sécurités connus si on utilise plusieurs
VHosts avec plusieurs "oscommerce" dessus?
Ce qui me parait demander les risques vis à vis des différentes instances
d'oscommerce entres elles, en suexec il n'y en a pas.
Par ailleurs, l'appli peut permettre par elle-même un accès
complet aux données, suExec ou pas (faille de SQL-Injection).
Toujours pareil je répondais par rapport au contexte : plusieurs instances plusieurs bases pas de propagation des risques.
Dans le cas contraire : les mêmes risques que pour toute application
php tournant avec les droits d'apache.
Pas d'accord non plus ;-) Ca reviendrait à dire que les risques sont les
mêmes avec vsftpd qu'avec wu-ftpd, vu que ce sont tous deux des serveurs
FTP en C. Heureusement, ce n'est parceque l'appli est en PHP au dessus
d'Apache qu'elle sera trouable ...
Si le risque de corruption est différent il ne cesse jamais d'exister, le
risque AVEC corruption est exactement le même quelque soit l'application.
On Sat, 19 Feb 2005 17:35:42 +0000, Christophe Casalegno wrote:
rien si on prends la peine de faire tourner php en suexec :)
Pas d'accord. Si le code PHP est troué, l'attaquant gagne tout de même les droits correspondants à l'utilisateur lié au vhost. Ce qui peut lui servir à accéder au code source et au login/passwd de la base de données.
La question était la suivante :
Quels sont les risques de sécurités connus si on utilise plusieurs VHosts avec plusieurs "oscommerce" dessus?
Ce qui me parait demander les risques vis à vis des différentes instances d'oscommerce entres elles, en suexec il n'y en a pas.
Par ailleurs, l'appli peut permettre par elle-même un accès complet aux données, suExec ou pas (faille de SQL-Injection).
Toujours pareil je répondais par rapport au contexte : plusieurs instances plusieurs bases pas de propagation des risques.
Dans le cas contraire : les mêmes risques que pour toute application php tournant avec les droits d'apache.
Pas d'accord non plus ;-) Ca reviendrait à dire que les risques sont les mêmes avec vsftpd qu'avec wu-ftpd, vu que ce sont tous deux des serveurs FTP en C. Heureusement, ce n'est parceque l'appli est en PHP au dessus d'Apache qu'elle sera trouable ...
Si le risque de corruption est différent il ne cesse jamais d'exister, le risque AVEC corruption est exactement le même quelque soit l'application.
Quels sont les risques de sécurités connus si on utilise plusieurs VHosts avec plusieurs "oscommerce" dessus?
C'etait ma question
Ce qui me parait demander les risques vis à vis des différentes instances d'oscommerce entres elles, en suexec il n'y en a pas.
Entre elles, mais vraiment strictement entre elles, c'est pas mon problème. Mon problème c'est quand ça touche au système.
Bon... déjà on va essayer de trouver un moyen se créer une /tmp et /var/tmp montée en noexec, sur un serveur distant, en minimisant les pertes de données... Mon truc de "pscan" n'aurai pas _facilement_ pu s'executer si j'avais une partition /tmp noexec.
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Quels sont les risques de sécurités connus si on utilise plusieurs
VHosts avec plusieurs "oscommerce" dessus?
C'etait ma question
Ce qui me parait demander les risques vis à vis des différentes instances
d'oscommerce entres elles, en suexec il n'y en a pas.
Entre elles, mais vraiment strictement entre elles, c'est pas mon
problème.
Mon problème c'est quand ça touche au système.
Bon... déjà on va essayer de trouver un moyen se créer une /tmp et
/var/tmp montée en noexec, sur un serveur distant, en minimisant les
pertes de données...
Mon truc de "pscan" n'aurai pas _facilement_ pu s'executer si j'avais une
partition /tmp noexec.
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Quels sont les risques de sécurités connus si on utilise plusieurs VHosts avec plusieurs "oscommerce" dessus?
C'etait ma question
Ce qui me parait demander les risques vis à vis des différentes instances d'oscommerce entres elles, en suexec il n'y en a pas.
Entre elles, mais vraiment strictement entre elles, c'est pas mon problème. Mon problème c'est quand ça touche au système.
Bon... déjà on va essayer de trouver un moyen se créer une /tmp et /var/tmp montée en noexec, sur un serveur distant, en minimisant les pertes de données... Mon truc de "pscan" n'aurai pas _facilement_ pu s'executer si j'avais une partition /tmp noexec.
-- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Nicob
On Sun, 20 Feb 2005 19:00:45 +0000, Christophe Casalegno wrote:
Ce qui me parait demander les risques vis à vis des différentes instances d'oscommerce entres elles, en suexec il n'y en a pas.
Tout dépend de la config faite sur les droits de fichiers. Je viens de monter un OsCommerce dernière version, juste pour voir ...
Si quelqu'un est admin sur son OsCommerce, il peut browser tous les fichiers en lecture du file-system et uploader/créer des fichiers partout où il a des droits d'écriture (pas seulement dans son espace, hein, *partout* où il a les droits donc y compris /tmp la plupart du temps).
Restreindre l'exécution sur /tmp ne sera de toute façon pas suffisant, il faudrait aussi le faire dans les web-roots. Sinon, le scénario est facile à écrire : upload de nc, upload d'un local r00t, upload d'un phpshell, et hop, on se retrouve avec un reverse-shell root ;-) A partir de là, suExec ou pas ...
Nicob
On Sun, 20 Feb 2005 19:00:45 +0000, Christophe Casalegno wrote:
Ce qui me parait demander les risques vis à vis des différentes
instances d'oscommerce entres elles, en suexec il n'y en a pas.
Tout dépend de la config faite sur les droits de fichiers. Je viens de
monter un OsCommerce dernière version, juste pour voir ...
Si quelqu'un est admin sur son OsCommerce, il peut browser tous les
fichiers en lecture du file-system et uploader/créer des fichiers partout
où il a des droits d'écriture (pas seulement dans son espace, hein,
*partout* où il a les droits donc y compris /tmp la plupart du temps).
Restreindre l'exécution sur /tmp ne sera de toute façon pas suffisant,
il faudrait aussi le faire dans les web-roots. Sinon, le scénario est
facile à écrire : upload de nc, upload d'un local r00t, upload d'un
phpshell, et hop, on se retrouve avec un reverse-shell root ;-) A partir
de là, suExec ou pas ...
On Sun, 20 Feb 2005 19:00:45 +0000, Christophe Casalegno wrote:
Ce qui me parait demander les risques vis à vis des différentes instances d'oscommerce entres elles, en suexec il n'y en a pas.
Tout dépend de la config faite sur les droits de fichiers. Je viens de monter un OsCommerce dernière version, juste pour voir ...
Si quelqu'un est admin sur son OsCommerce, il peut browser tous les fichiers en lecture du file-system et uploader/créer des fichiers partout où il a des droits d'écriture (pas seulement dans son espace, hein, *partout* où il a les droits donc y compris /tmp la plupart du temps).
Restreindre l'exécution sur /tmp ne sera de toute façon pas suffisant, il faudrait aussi le faire dans les web-roots. Sinon, le scénario est facile à écrire : upload de nc, upload d'un local r00t, upload d'un phpshell, et hop, on se retrouve avec un reverse-shell root ;-) A partir de là, suExec ou pas ...
