David Bizeul , le 19 sept. 2004 15:46:46,
écrivait ceci:Autour de moi j'entends mes collègues constamment dire qu'il ne faut
pas utiliser Internet Explorer, car trop dangereux.
Plusieurs raisons a cela :
1 - Navigateur numéro 1 donc cible de choix pour le développement de
vulns
C'est une fausse raison. Si effectivement les logiciels massivement
utilisés étaient plus "attaquéé" Apache (70% des serveurs http)
serait donc aussi la cible de choix (l'exemple est valable avec bind)
? Pourtant on voit plus de serveur http sous IIS tomber que sous
Apache. AMHA il ne faut pas oublier le plus important : Le niveau
intrinsèque de sécurité du logiciel
David Bizeul <donotreply@nomail.com>, le 19 sept. 2004 15:46:46,
écrivait ceci:
Autour de moi j'entends mes collègues constamment dire qu'il ne faut
pas utiliser Internet Explorer, car trop dangereux.
Plusieurs raisons a cela :
1 - Navigateur numéro 1 donc cible de choix pour le développement de
vulns
C'est une fausse raison. Si effectivement les logiciels massivement
utilisés étaient plus "attaquéé" Apache (70% des serveurs http)
serait donc aussi la cible de choix (l'exemple est valable avec bind)
? Pourtant on voit plus de serveur http sous IIS tomber que sous
Apache. AMHA il ne faut pas oublier le plus important : Le niveau
intrinsèque de sécurité du logiciel
David Bizeul , le 19 sept. 2004 15:46:46,
écrivait ceci:Autour de moi j'entends mes collègues constamment dire qu'il ne faut
pas utiliser Internet Explorer, car trop dangereux.
Plusieurs raisons a cela :
1 - Navigateur numéro 1 donc cible de choix pour le développement de
vulns
C'est une fausse raison. Si effectivement les logiciels massivement
utilisés étaient plus "attaquéé" Apache (70% des serveurs http)
serait donc aussi la cible de choix (l'exemple est valable avec bind)
? Pourtant on voit plus de serveur http sous IIS tomber que sous
Apache. AMHA il ne faut pas oublier le plus important : Le niveau
intrinsèque de sécurité du logiciel
Laurent Seguin wrote:David Bizeul , le 19 sept. 2004 15:46:46,
écrivait ceci:Autour de moi j'entends mes collègues constamment dire qu'il ne
faut pas utiliser Internet Explorer, car trop dangereux.
Plusieurs raisons a cela :
1 - Navigateur numéro 1 donc cible de choix pour le développement de
vulns
C'est une fausse raison. Si effectivement les logiciels massivement
utilisés étaient plus "attaquéé" Apache (70% des serveurs http)
serait donc aussi la cible de choix (l'exemple est valable avec bind)
? Pourtant on voit plus de serveur http sous IIS tomber que sous
Apache. AMHA il ne faut pas oublier le plus important : Le niveau
intrinsèque de sécurité du logiciel
Je suis peu convaincu par l'argument. A quoi mesures-tu le "niveau
intrinsèque de sécurité" ? Au nombre de bugs trouvés ?
Le nombre de
failles trouvées peut tout aussi bien être uniquement lié au fait que
les machines des pirates sont elles mêmes souvent sous windows.
Quelqu'en soit la raison, outlook reste tout de même une cible
privilégiée pour les pirates (même si je n'ai jamais eu de problèmes
avec), mais rien ne permet d'affirmer quoique ce soit d'un point de
vue "intrinsèque.
Laurent Seguin wrote:
David Bizeul <donotreply@nomail.com>, le 19 sept. 2004 15:46:46,
écrivait ceci:
Autour de moi j'entends mes collègues constamment dire qu'il ne
faut pas utiliser Internet Explorer, car trop dangereux.
Plusieurs raisons a cela :
1 - Navigateur numéro 1 donc cible de choix pour le développement de
vulns
C'est une fausse raison. Si effectivement les logiciels massivement
utilisés étaient plus "attaquéé" Apache (70% des serveurs http)
serait donc aussi la cible de choix (l'exemple est valable avec bind)
? Pourtant on voit plus de serveur http sous IIS tomber que sous
Apache. AMHA il ne faut pas oublier le plus important : Le niveau
intrinsèque de sécurité du logiciel
Je suis peu convaincu par l'argument. A quoi mesures-tu le "niveau
intrinsèque de sécurité" ? Au nombre de bugs trouvés ?
Le nombre de
failles trouvées peut tout aussi bien être uniquement lié au fait que
les machines des pirates sont elles mêmes souvent sous windows.
Quelqu'en soit la raison, outlook reste tout de même une cible
privilégiée pour les pirates (même si je n'ai jamais eu de problèmes
avec), mais rien ne permet d'affirmer quoique ce soit d'un point de
vue "intrinsèque.
Laurent Seguin wrote:David Bizeul , le 19 sept. 2004 15:46:46,
écrivait ceci:Autour de moi j'entends mes collègues constamment dire qu'il ne
faut pas utiliser Internet Explorer, car trop dangereux.
Plusieurs raisons a cela :
1 - Navigateur numéro 1 donc cible de choix pour le développement de
vulns
C'est une fausse raison. Si effectivement les logiciels massivement
utilisés étaient plus "attaquéé" Apache (70% des serveurs http)
serait donc aussi la cible de choix (l'exemple est valable avec bind)
? Pourtant on voit plus de serveur http sous IIS tomber que sous
Apache. AMHA il ne faut pas oublier le plus important : Le niveau
intrinsèque de sécurité du logiciel
Je suis peu convaincu par l'argument. A quoi mesures-tu le "niveau
intrinsèque de sécurité" ? Au nombre de bugs trouvés ?
Le nombre de
failles trouvées peut tout aussi bien être uniquement lié au fait que
les machines des pirates sont elles mêmes souvent sous windows.
Quelqu'en soit la raison, outlook reste tout de même une cible
privilégiée pour les pirates (même si je n'ai jamais eu de problèmes
avec), mais rien ne permet d'affirmer quoique ce soit d'un point de
vue "intrinsèque.
"Christophe Lephay" , le 23 oct. 2004Je suis peu convaincu par l'argument. A quoi mesures-tu le "niveau
intrinsèque de sécurité" ? Au nombre de bugs trouvés ?
De faille de sécurité majeure oui.
Il y a des logiciels qui sont
développés avec une politique de sécurité dès l'étude (donc avant la
conception même) et les autres. Bien sur cela ne veut pas dire qu'il
n'y a pas ou n'aura pas de failles dans les premiers, seulement qu'il
ont intégrés dès le départ un soucis de sécurité.
C'est ça que j'appelle le niveau intrinsèque de sécurité et nous
savons depuis longtemps que IE n'a pas été développé avec une optique
sécuritaire (il y en a même qui disent que cela à été fait exprès).
Le nombre de
failles trouvées peut tout aussi bien être uniquement lié au fait que
les machines des pirates sont elles mêmes souvent sous windows.
La j'en doute un peu mais je n'ai aucune stats pour appuyer mes dires
Cependant, il est tout de même étonnant que l'on trouve plus de
failles dans un logiciel propriétaire fermé que dans un produit libre
(même si il est plus utilisé que le fermé). C'est quand même plus
simple de lire le code du soft et trouver la faille que de chercher à
taton voir faire du reverse engenering.
Quelqu'en soit la raison, outlook reste tout de même une cible
privilégiée pour les pirates (même si je n'ai jamais eu de problèmes
avec), mais rien ne permet d'affirmer quoique ce soit d'un point de
vue "intrinsèque.
Heuu si... La plupart des failles d'Outlook venaient de
"fonctionalités" implémentée dans le logiciel qui été détournées ; il
ne faut pas non plus mettre toutes les failles d'Outlook sur son dos
car vu qu'il utilise IE pour lire les mail, il en récupère donc les
failles.
Bref dire que si on trouve énormément de faille dans un logiciel
c'est du à sa popularité n'est pas forcement vrai.
"Christophe Lephay" <christophe-lephay@wanadoo.fr>, le 23 oct. 2004
Je suis peu convaincu par l'argument. A quoi mesures-tu le "niveau
intrinsèque de sécurité" ? Au nombre de bugs trouvés ?
De faille de sécurité majeure oui.
Il y a des logiciels qui sont
développés avec une politique de sécurité dès l'étude (donc avant la
conception même) et les autres. Bien sur cela ne veut pas dire qu'il
n'y a pas ou n'aura pas de failles dans les premiers, seulement qu'il
ont intégrés dès le départ un soucis de sécurité.
C'est ça que j'appelle le niveau intrinsèque de sécurité et nous
savons depuis longtemps que IE n'a pas été développé avec une optique
sécuritaire (il y en a même qui disent que cela à été fait exprès).
Le nombre de
failles trouvées peut tout aussi bien être uniquement lié au fait que
les machines des pirates sont elles mêmes souvent sous windows.
La j'en doute un peu mais je n'ai aucune stats pour appuyer mes dires
Cependant, il est tout de même étonnant que l'on trouve plus de
failles dans un logiciel propriétaire fermé que dans un produit libre
(même si il est plus utilisé que le fermé). C'est quand même plus
simple de lire le code du soft et trouver la faille que de chercher à
taton voir faire du reverse engenering.
Quelqu'en soit la raison, outlook reste tout de même une cible
privilégiée pour les pirates (même si je n'ai jamais eu de problèmes
avec), mais rien ne permet d'affirmer quoique ce soit d'un point de
vue "intrinsèque.
Heuu si... La plupart des failles d'Outlook venaient de
"fonctionalités" implémentée dans le logiciel qui été détournées ; il
ne faut pas non plus mettre toutes les failles d'Outlook sur son dos
car vu qu'il utilise IE pour lire les mail, il en récupère donc les
failles.
Bref dire que si on trouve énormément de faille dans un logiciel
c'est du à sa popularité n'est pas forcement vrai.
"Christophe Lephay" , le 23 oct. 2004Je suis peu convaincu par l'argument. A quoi mesures-tu le "niveau
intrinsèque de sécurité" ? Au nombre de bugs trouvés ?
De faille de sécurité majeure oui.
Il y a des logiciels qui sont
développés avec une politique de sécurité dès l'étude (donc avant la
conception même) et les autres. Bien sur cela ne veut pas dire qu'il
n'y a pas ou n'aura pas de failles dans les premiers, seulement qu'il
ont intégrés dès le départ un soucis de sécurité.
C'est ça que j'appelle le niveau intrinsèque de sécurité et nous
savons depuis longtemps que IE n'a pas été développé avec une optique
sécuritaire (il y en a même qui disent que cela à été fait exprès).
Le nombre de
failles trouvées peut tout aussi bien être uniquement lié au fait que
les machines des pirates sont elles mêmes souvent sous windows.
La j'en doute un peu mais je n'ai aucune stats pour appuyer mes dires
Cependant, il est tout de même étonnant que l'on trouve plus de
failles dans un logiciel propriétaire fermé que dans un produit libre
(même si il est plus utilisé que le fermé). C'est quand même plus
simple de lire le code du soft et trouver la faille que de chercher à
taton voir faire du reverse engenering.
Quelqu'en soit la raison, outlook reste tout de même une cible
privilégiée pour les pirates (même si je n'ai jamais eu de problèmes
avec), mais rien ne permet d'affirmer quoique ce soit d'un point de
vue "intrinsèque.
Heuu si... La plupart des failles d'Outlook venaient de
"fonctionalités" implémentée dans le logiciel qui été détournées ; il
ne faut pas non plus mettre toutes les failles d'Outlook sur son dos
car vu qu'il utilise IE pour lire les mail, il en récupère donc les
failles.
Bref dire que si on trouve énormément de faille dans un logiciel
c'est du à sa popularité n'est pas forcement vrai.
Laurent Seguin wrote:"Christophe Lephay" , le 23 oct. 2004Je suis peu convaincu par l'argument. A quoi mesures-tu le "niveau
intrinsèque de sécurité" ? Au nombre de bugs trouvés ?
De faille de sécurité majeure oui.
Majeure en terme de consequences possibles ou parce qu'elles ont été
exploitées (ou les deux) ?
Il y a des logiciels qui sont
développés avec une politique de sécurité dès l'étude (donc avant la
conception même) et les autres. Bien sur cela ne veut pas dire qu'il
n'y a pas ou n'aura pas de failles dans les premiers, seulement qu'il
ont intégrés dès le départ un soucis de sécurité.
Je ne suis pas certain de bien comprendre de quelle politique de
sécurité tu parles.
Il y a la sécurité au sens où il est question sur
ce forum, et il y a la robustesse du code.
Du point de vue de la
robustesse du code, les failles sont le résultat de pratiques assez
universelles et qui ne sont en rien spécifiques aux produits microsoft
(Apache aussi fait l'objet de failles par débordement de tampon).
C'est ça que j'appelle le niveau intrinsèque de sécurité et nous
savons depuis longtemps que IE n'a pas été développé avec une optique
sécuritaire (il y en a même qui disent que cela à été fait exprès).
Qui est "nous" ?
D'où "nous" tenons ces informations dans la mesure
où, précisément, le code source n'est pas accessible ?
Cependant, il est tout de même étonnant que l'on trouve plus de
failles dans un logiciel propriétaire fermé que dans un produit libre
(même si il est plus utilisé que le fermé). C'est quand même plus
simple de lire le code du soft et trouver la faille que de chercher à
taton voir faire du reverse engenering.
Si celà représente un investissement plus important, il est aussi
beaucoup plus rentable tant il est répandu.
Une explication au fait
qu'un serveur Apache, par exemple, fasse l'objet de moins d'attaques
réside aussi, d'apres moi, dans le fait qu'un serveur est presque
nécessairement tant mieux protégé ou surveillé que plus spécialisé
qu'une station de travail ou qu'un ordinateur familial.
L'attaque de
cibles précises nécessite des connaissances plus larges, et celà me
semble donc normal qu'un logiciel client aussi répandu qu'outlook soit
une cible privilégiée.
Bref dire que si on trouve énormément de faille dans un logiciel
c'est du à sa popularité n'est pas forcement vrai.
Ceci dit, vu que ce paramètre est le seul qui soit réellement connu,
les autres raisons sont, par nature, du domaine de la spéculation.
Indépendamment du nombre de failles repérées, il suffit de se référer
au nombre de fois où elles ont été exploitées pour ce rendre compte
que cette popularité reste un facteur majeur.
Un autre facteur, bien
entendu, c'est la taille de l'application. Statistiquement, on a plus
de chances de trouver des bugs dans un programme s'il est plus
volumineux qu'un autre.
Après celà, je suis tout pret à te croire dans tes critiques du point
de vue design, mais c'est tellement à la mode de balancer des clichés
sur microsoft ceci ou microsoft celà
qu'il va me falloir pour celà des
références sérieuses (par exemple des liens vers des articles parlant
de ce dernier écrits par des gens bien placés pour savoir de quoi ils
parlent).
Laurent Seguin wrote:
"Christophe Lephay" <christophe-lephay@wanadoo.fr>, le 23 oct. 2004
Je suis peu convaincu par l'argument. A quoi mesures-tu le "niveau
intrinsèque de sécurité" ? Au nombre de bugs trouvés ?
De faille de sécurité majeure oui.
Majeure en terme de consequences possibles ou parce qu'elles ont été
exploitées (ou les deux) ?
Il y a des logiciels qui sont
développés avec une politique de sécurité dès l'étude (donc avant la
conception même) et les autres. Bien sur cela ne veut pas dire qu'il
n'y a pas ou n'aura pas de failles dans les premiers, seulement qu'il
ont intégrés dès le départ un soucis de sécurité.
Je ne suis pas certain de bien comprendre de quelle politique de
sécurité tu parles.
Il y a la sécurité au sens où il est question sur
ce forum, et il y a la robustesse du code.
Du point de vue de la
robustesse du code, les failles sont le résultat de pratiques assez
universelles et qui ne sont en rien spécifiques aux produits microsoft
(Apache aussi fait l'objet de failles par débordement de tampon).
C'est ça que j'appelle le niveau intrinsèque de sécurité et nous
savons depuis longtemps que IE n'a pas été développé avec une optique
sécuritaire (il y en a même qui disent que cela à été fait exprès).
Qui est "nous" ?
D'où "nous" tenons ces informations dans la mesure
où, précisément, le code source n'est pas accessible ?
Cependant, il est tout de même étonnant que l'on trouve plus de
failles dans un logiciel propriétaire fermé que dans un produit libre
(même si il est plus utilisé que le fermé). C'est quand même plus
simple de lire le code du soft et trouver la faille que de chercher à
taton voir faire du reverse engenering.
Si celà représente un investissement plus important, il est aussi
beaucoup plus rentable tant il est répandu.
Une explication au fait
qu'un serveur Apache, par exemple, fasse l'objet de moins d'attaques
réside aussi, d'apres moi, dans le fait qu'un serveur est presque
nécessairement tant mieux protégé ou surveillé que plus spécialisé
qu'une station de travail ou qu'un ordinateur familial.
L'attaque de
cibles précises nécessite des connaissances plus larges, et celà me
semble donc normal qu'un logiciel client aussi répandu qu'outlook soit
une cible privilégiée.
Bref dire que si on trouve énormément de faille dans un logiciel
c'est du à sa popularité n'est pas forcement vrai.
Ceci dit, vu que ce paramètre est le seul qui soit réellement connu,
les autres raisons sont, par nature, du domaine de la spéculation.
Indépendamment du nombre de failles repérées, il suffit de se référer
au nombre de fois où elles ont été exploitées pour ce rendre compte
que cette popularité reste un facteur majeur.
Un autre facteur, bien
entendu, c'est la taille de l'application. Statistiquement, on a plus
de chances de trouver des bugs dans un programme s'il est plus
volumineux qu'un autre.
Après celà, je suis tout pret à te croire dans tes critiques du point
de vue design, mais c'est tellement à la mode de balancer des clichés
sur microsoft ceci ou microsoft celà
qu'il va me falloir pour celà des
références sérieuses (par exemple des liens vers des articles parlant
de ce dernier écrits par des gens bien placés pour savoir de quoi ils
parlent).
Laurent Seguin wrote:"Christophe Lephay" , le 23 oct. 2004Je suis peu convaincu par l'argument. A quoi mesures-tu le "niveau
intrinsèque de sécurité" ? Au nombre de bugs trouvés ?
De faille de sécurité majeure oui.
Majeure en terme de consequences possibles ou parce qu'elles ont été
exploitées (ou les deux) ?
Il y a des logiciels qui sont
développés avec une politique de sécurité dès l'étude (donc avant la
conception même) et les autres. Bien sur cela ne veut pas dire qu'il
n'y a pas ou n'aura pas de failles dans les premiers, seulement qu'il
ont intégrés dès le départ un soucis de sécurité.
Je ne suis pas certain de bien comprendre de quelle politique de
sécurité tu parles.
Il y a la sécurité au sens où il est question sur
ce forum, et il y a la robustesse du code.
Du point de vue de la
robustesse du code, les failles sont le résultat de pratiques assez
universelles et qui ne sont en rien spécifiques aux produits microsoft
(Apache aussi fait l'objet de failles par débordement de tampon).
C'est ça que j'appelle le niveau intrinsèque de sécurité et nous
savons depuis longtemps que IE n'a pas été développé avec une optique
sécuritaire (il y en a même qui disent que cela à été fait exprès).
Qui est "nous" ?
D'où "nous" tenons ces informations dans la mesure
où, précisément, le code source n'est pas accessible ?
Cependant, il est tout de même étonnant que l'on trouve plus de
failles dans un logiciel propriétaire fermé que dans un produit libre
(même si il est plus utilisé que le fermé). C'est quand même plus
simple de lire le code du soft et trouver la faille que de chercher à
taton voir faire du reverse engenering.
Si celà représente un investissement plus important, il est aussi
beaucoup plus rentable tant il est répandu.
Une explication au fait
qu'un serveur Apache, par exemple, fasse l'objet de moins d'attaques
réside aussi, d'apres moi, dans le fait qu'un serveur est presque
nécessairement tant mieux protégé ou surveillé que plus spécialisé
qu'une station de travail ou qu'un ordinateur familial.
L'attaque de
cibles précises nécessite des connaissances plus larges, et celà me
semble donc normal qu'un logiciel client aussi répandu qu'outlook soit
une cible privilégiée.
Bref dire que si on trouve énormément de faille dans un logiciel
c'est du à sa popularité n'est pas forcement vrai.
Ceci dit, vu que ce paramètre est le seul qui soit réellement connu,
les autres raisons sont, par nature, du domaine de la spéculation.
Indépendamment du nombre de failles repérées, il suffit de se référer
au nombre de fois où elles ont été exploitées pour ce rendre compte
que cette popularité reste un facteur majeur.
Un autre facteur, bien
entendu, c'est la taille de l'application. Statistiquement, on a plus
de chances de trouver des bugs dans un programme s'il est plus
volumineux qu'un autre.
Après celà, je suis tout pret à te croire dans tes critiques du point
de vue design, mais c'est tellement à la mode de balancer des clichés
sur microsoft ceci ou microsoft celà
qu'il va me falloir pour celà des
références sérieuses (par exemple des liens vers des articles parlant
de ce dernier écrits par des gens bien placés pour savoir de quoi ils
parlent).
L'attaque de cibles précises nécessite des connaissances plus larges
L'attaque de cibles précises nécessite des connaissances plus larges
L'attaque de cibles précises nécessite des connaissances plus larges
"Christophe Lephay" , le 24 oct. 2004Majeure en terme de consequences possibles ou parce qu'elles ont été
exploitées (ou les deux) ?
En terme de consequences.
Il y a des logiciels qui sont
développés avec une politique de sécurité dès l'étude (donc avant la
conception même) et les autres. Bien sur cela ne veut pas dire qu'il
n'y a pas ou n'aura pas de failles dans les premiers, seulement
qu'il ont intégrés dès le départ un soucis de sécurité.
Je ne suis pas certain de bien comprendre de quelle politique de
sécurité tu parles.
Dans le sens ou la sécurité est prise en compte lors du developpement.
Il y a la sécurité au sens où il est question sur
ce forum, et il y a la robustesse du code.
Non pas forcement, un soft peut être très rubuste dans le code écrit
mais laisser des trous béants car on a pas pris en compte le risque
de telle ou telle spécificité ou fonctiontionalité.
Du point de vue de la
robustesse du code, les failles sont le résultat de pratiques assez
universelles et qui ne sont en rien spécifiques aux produits
microsoft (Apache aussi fait l'objet de failles par débordement de
tampon).
Relis les 50 dernière grosses failles de sécurité des produits M$ tu
verras qu'on est loin de la faille type genre DoS ou BufferOverflow.
Tout ceux qui s'intéressent un peu à la sécurité et à la sureté des
logiciel.D'où "nous" tenons ces informations dans la mesure
où, précisément, le code source n'est pas accessible ?
Moi principalement du CERTA et de quelques sites de sécurité et
parfois d'ici même :-)
Une explication au fait
qu'un serveur Apache, par exemple, fasse l'objet de moins d'attaques
réside aussi, d'apres moi, dans le fait qu'un serveur est presque
nécessairement tant mieux protégé ou surveillé que plus spécialisé
qu'une station de travail ou qu'un ordinateur familial.
Oulla ne pas confondre les attaques sur les serveurs (http ou pas) et
sur les machines perso. Quand je citais Apache c'était pour démontrer
que par rapport à ISS il était bien moins attaqué (ou du moins les
attaques sont infructueux, ce qui ne veut pas dire qu'il n'a pas de
failles) et quand c'est le cas les conséquences sont généralement
moindres.
Certes mais quand on voit certaines "failles" de ce logiciel (qui
certes depuis ont été corrigées) qui sont en fait une non prise en
compte de la sécurité lors du développement d'une fonctionalité, on
doute du sérieux. Je pense notamment à l'execution de code arbitraire
sans la "zone sécurisée" ave les droits des utilisateurs ou le
téléchargement et l'installation de fichiers distant en transparent.
Cela se mesure sur la concurence et ce même si elle est moins
massivement utilisée.
Pour son exploitation, oui, certainement. Mais cela ne veut pas dire
qu'il suffit que le logiciel soit extrèmement implenté pour qu'il
devienne plus vulnérable.
Un autre facteur, bien
entendu, c'est la taille de l'application. Statistiquement, on a plus
de chances de trouver des bugs dans un programme s'il est plus
volumineux qu'un autre.
La aussi ça se discute :-) OpenOffice (premier exemple qui me vient à
l'esprit) est aussi imposant que son concurent et a eu quand même
beaucoup moins de faille.
qu'il va me falloir pour celà des
références sérieuses (par exemple des liens vers des articles parlant
de ce dernier écrits par des gens bien placés pour savoir de quoi ils
parlent).
Si tu veux du sérieux, je ne peux trop te conseiller le site du CERT
http://www.cert.org/ voir celui du CERTA http://www.certa.ssi.gouv.fr/
"Christophe Lephay" <christophe-lephay@wanadoo.fr>, le 24 oct. 2004
Majeure en terme de consequences possibles ou parce qu'elles ont été
exploitées (ou les deux) ?
En terme de consequences.
Il y a des logiciels qui sont
développés avec une politique de sécurité dès l'étude (donc avant la
conception même) et les autres. Bien sur cela ne veut pas dire qu'il
n'y a pas ou n'aura pas de failles dans les premiers, seulement
qu'il ont intégrés dès le départ un soucis de sécurité.
Je ne suis pas certain de bien comprendre de quelle politique de
sécurité tu parles.
Dans le sens ou la sécurité est prise en compte lors du developpement.
Il y a la sécurité au sens où il est question sur
ce forum, et il y a la robustesse du code.
Non pas forcement, un soft peut être très rubuste dans le code écrit
mais laisser des trous béants car on a pas pris en compte le risque
de telle ou telle spécificité ou fonctiontionalité.
Du point de vue de la
robustesse du code, les failles sont le résultat de pratiques assez
universelles et qui ne sont en rien spécifiques aux produits
microsoft (Apache aussi fait l'objet de failles par débordement de
tampon).
Relis les 50 dernière grosses failles de sécurité des produits M$ tu
verras qu'on est loin de la faille type genre DoS ou BufferOverflow.
Tout ceux qui s'intéressent un peu à la sécurité et à la sureté des
logiciel.
D'où "nous" tenons ces informations dans la mesure
où, précisément, le code source n'est pas accessible ?
Moi principalement du CERTA et de quelques sites de sécurité et
parfois d'ici même :-)
Une explication au fait
qu'un serveur Apache, par exemple, fasse l'objet de moins d'attaques
réside aussi, d'apres moi, dans le fait qu'un serveur est presque
nécessairement tant mieux protégé ou surveillé que plus spécialisé
qu'une station de travail ou qu'un ordinateur familial.
Oulla ne pas confondre les attaques sur les serveurs (http ou pas) et
sur les machines perso. Quand je citais Apache c'était pour démontrer
que par rapport à ISS il était bien moins attaqué (ou du moins les
attaques sont infructueux, ce qui ne veut pas dire qu'il n'a pas de
failles) et quand c'est le cas les conséquences sont généralement
moindres.
Certes mais quand on voit certaines "failles" de ce logiciel (qui
certes depuis ont été corrigées) qui sont en fait une non prise en
compte de la sécurité lors du développement d'une fonctionalité, on
doute du sérieux. Je pense notamment à l'execution de code arbitraire
sans la "zone sécurisée" ave les droits des utilisateurs ou le
téléchargement et l'installation de fichiers distant en transparent.
Cela se mesure sur la concurence et ce même si elle est moins
massivement utilisée.
Pour son exploitation, oui, certainement. Mais cela ne veut pas dire
qu'il suffit que le logiciel soit extrèmement implenté pour qu'il
devienne plus vulnérable.
Un autre facteur, bien
entendu, c'est la taille de l'application. Statistiquement, on a plus
de chances de trouver des bugs dans un programme s'il est plus
volumineux qu'un autre.
La aussi ça se discute :-) OpenOffice (premier exemple qui me vient à
l'esprit) est aussi imposant que son concurent et a eu quand même
beaucoup moins de faille.
qu'il va me falloir pour celà des
références sérieuses (par exemple des liens vers des articles parlant
de ce dernier écrits par des gens bien placés pour savoir de quoi ils
parlent).
Si tu veux du sérieux, je ne peux trop te conseiller le site du CERT
http://www.cert.org/ voir celui du CERTA http://www.certa.ssi.gouv.fr/
"Christophe Lephay" , le 24 oct. 2004Majeure en terme de consequences possibles ou parce qu'elles ont été
exploitées (ou les deux) ?
En terme de consequences.
Il y a des logiciels qui sont
développés avec une politique de sécurité dès l'étude (donc avant la
conception même) et les autres. Bien sur cela ne veut pas dire qu'il
n'y a pas ou n'aura pas de failles dans les premiers, seulement
qu'il ont intégrés dès le départ un soucis de sécurité.
Je ne suis pas certain de bien comprendre de quelle politique de
sécurité tu parles.
Dans le sens ou la sécurité est prise en compte lors du developpement.
Il y a la sécurité au sens où il est question sur
ce forum, et il y a la robustesse du code.
Non pas forcement, un soft peut être très rubuste dans le code écrit
mais laisser des trous béants car on a pas pris en compte le risque
de telle ou telle spécificité ou fonctiontionalité.
Du point de vue de la
robustesse du code, les failles sont le résultat de pratiques assez
universelles et qui ne sont en rien spécifiques aux produits
microsoft (Apache aussi fait l'objet de failles par débordement de
tampon).
Relis les 50 dernière grosses failles de sécurité des produits M$ tu
verras qu'on est loin de la faille type genre DoS ou BufferOverflow.
Tout ceux qui s'intéressent un peu à la sécurité et à la sureté des
logiciel.D'où "nous" tenons ces informations dans la mesure
où, précisément, le code source n'est pas accessible ?
Moi principalement du CERTA et de quelques sites de sécurité et
parfois d'ici même :-)
Une explication au fait
qu'un serveur Apache, par exemple, fasse l'objet de moins d'attaques
réside aussi, d'apres moi, dans le fait qu'un serveur est presque
nécessairement tant mieux protégé ou surveillé que plus spécialisé
qu'une station de travail ou qu'un ordinateur familial.
Oulla ne pas confondre les attaques sur les serveurs (http ou pas) et
sur les machines perso. Quand je citais Apache c'était pour démontrer
que par rapport à ISS il était bien moins attaqué (ou du moins les
attaques sont infructueux, ce qui ne veut pas dire qu'il n'a pas de
failles) et quand c'est le cas les conséquences sont généralement
moindres.
Certes mais quand on voit certaines "failles" de ce logiciel (qui
certes depuis ont été corrigées) qui sont en fait une non prise en
compte de la sécurité lors du développement d'une fonctionalité, on
doute du sérieux. Je pense notamment à l'execution de code arbitraire
sans la "zone sécurisée" ave les droits des utilisateurs ou le
téléchargement et l'installation de fichiers distant en transparent.
Cela se mesure sur la concurence et ce même si elle est moins
massivement utilisée.
Pour son exploitation, oui, certainement. Mais cela ne veut pas dire
qu'il suffit que le logiciel soit extrèmement implenté pour qu'il
devienne plus vulnérable.
Un autre facteur, bien
entendu, c'est la taille de l'application. Statistiquement, on a plus
de chances de trouver des bugs dans un programme s'il est plus
volumineux qu'un autre.
La aussi ça se discute :-) OpenOffice (premier exemple qui me vient à
l'esprit) est aussi imposant que son concurent et a eu quand même
beaucoup moins de faille.
qu'il va me falloir pour celà des
références sérieuses (par exemple des liens vers des articles parlant
de ce dernier écrits par des gens bien placés pour savoir de quoi ils
parlent).
Si tu veux du sérieux, je ne peux trop te conseiller le site du CERT
http://www.cert.org/ voir celui du CERTA http://www.certa.ssi.gouv.fr/
Je ne suis pas certain de bien comprendre de quelle politique de sécurité tu
parles.
Je ne suis pas certain de bien comprendre de quelle politique de sécurité tu
parles.
Je ne suis pas certain de bien comprendre de quelle politique de sécurité tu
parles.
Christophe Lephay wrote:L'attaque de cibles précises nécessite des connaissances plus larges
Après relecture j'ai trouvé ma phrase ambigue et susceptible de générer des
contre-sens. Par cible précise, j'entendais une machine particulière sans
qu'on en connaisse par avance le logiciel (dont l'OS) tournant dessus.
Christophe Lephay wrote:
L'attaque de cibles précises nécessite des connaissances plus larges
Après relecture j'ai trouvé ma phrase ambigue et susceptible de générer des
contre-sens. Par cible précise, j'entendais une machine particulière sans
qu'on en connaisse par avance le logiciel (dont l'OS) tournant dessus.
Christophe Lephay wrote:L'attaque de cibles précises nécessite des connaissances plus larges
Après relecture j'ai trouvé ma phrase ambigue et susceptible de générer des
contre-sens. Par cible précise, j'entendais une machine particulière sans
qu'on en connaisse par avance le logiciel (dont l'OS) tournant dessus.
Christophe Lephay wrote:L'attaque de cibles précises nécessite des connaissances plus larges
Après relecture j'ai trouvé ma phrase ambigue et susceptible de
générer des contre-sens. Par cible précise, j'entendais une machine
particulière sans qu'on en connaisse par avance le logiciel (dont
l'OS) tournant dessus.
Solution 1, très répandue : j'ai un scanner embarquant un exploit et
je le balance sur plusieurs classes C en séquence, sans
discrimination. Niveau de compétence : savoir lancer un exécutable.
Solution 2, un peu plus touchy : je lance un nmap -sS -sV -O sur
pleins de classes, voire en le restreignant à certains port pour
accélérer le process, et je récupère pleins d'OS avec des versions de
logiciels. Il
ne reste plus qu'à mettre les exploits en face. Niveau de compétence :
savoir se servir de nmap, savoir se servir du moteur de recherche de
la BID de SecurityFocus.
Christophe Lephay wrote:
L'attaque de cibles précises nécessite des connaissances plus larges
Après relecture j'ai trouvé ma phrase ambigue et susceptible de
générer des contre-sens. Par cible précise, j'entendais une machine
particulière sans qu'on en connaisse par avance le logiciel (dont
l'OS) tournant dessus.
Solution 1, très répandue : j'ai un scanner embarquant un exploit et
je le balance sur plusieurs classes C en séquence, sans
discrimination. Niveau de compétence : savoir lancer un exécutable.
Solution 2, un peu plus touchy : je lance un nmap -sS -sV -O sur
pleins de classes, voire en le restreignant à certains port pour
accélérer le process, et je récupère pleins d'OS avec des versions de
logiciels. Il
ne reste plus qu'à mettre les exploits en face. Niveau de compétence :
savoir se servir de nmap, savoir se servir du moteur de recherche de
la BID de SecurityFocus.
Christophe Lephay wrote:L'attaque de cibles précises nécessite des connaissances plus larges
Après relecture j'ai trouvé ma phrase ambigue et susceptible de
générer des contre-sens. Par cible précise, j'entendais une machine
particulière sans qu'on en connaisse par avance le logiciel (dont
l'OS) tournant dessus.
Solution 1, très répandue : j'ai un scanner embarquant un exploit et
je le balance sur plusieurs classes C en séquence, sans
discrimination. Niveau de compétence : savoir lancer un exécutable.
Solution 2, un peu plus touchy : je lance un nmap -sS -sV -O sur
pleins de classes, voire en le restreignant à certains port pour
accélérer le process, et je récupère pleins d'OS avec des versions de
logiciels. Il
ne reste plus qu'à mettre les exploits en face. Niveau de compétence :
savoir se servir de nmap, savoir se servir du moteur de recherche de
la BID de SecurityFocus.
Arf, à croire que ma phrase était à nouveau ambigue !
Une machine précise, je veux dire par la, par exemple, le serveur de La
Redoute qui va s'avérer après prise d'empreinte tourner sous xxx.yyy...
Arf, à croire que ma phrase était à nouveau ambigue !
Une machine précise, je veux dire par la, par exemple, le serveur de La
Redoute qui va s'avérer après prise d'empreinte tourner sous xxx.yyy...
Arf, à croire que ma phrase était à nouveau ambigue !
Une machine précise, je veux dire par la, par exemple, le serveur de La
Redoute qui va s'avérer après prise d'empreinte tourner sous xxx.yyy...