A la place de IE ?

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.

Chris

"Christophe Lephay" <christophe-lephay@wanadoo.fr>, le 23 oct. 2004
20:39:24, écrivait ceci:

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 ?

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

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. Les deux concepts sont relativement distincts. En
terme de design, le fait qu'outlook partage un certain nombre d'éléments
avec IE ou le système d'exploitation hôte augmente bien évidemment le risque
du point de vue de la sécurité mais en facilite en contre-partie
l'exploitation. 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 ? Il est difficile de juger
du design d'une application à travers un simple reverse ingeneering qui
permet assez difficilement d'avoir une vision globale d'un logiciel.

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

Pourtant, je suis bien convaincu que ceux qui étudient les failles d'outlook
le font bien à partir de machines Windows.

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.

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.

Je dois dire que je ne comprends pas très bien cette notion de
"fonctionnalités implémentées et détournées", vu qu'il me semble que de tels
détournements sont la base de tout accès illicite (par définition).

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).

Chris

"Christophe Lephay" <christophe-lephay@wanadoo.fr>, le 24 oct. 2004
01:18:27, écrivait ceci:

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) ?

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.

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" ?

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 :-)

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.

Encore une fois cela dépend du logiciel. Mais il est vrai que trouver une
bonne grosse faille dans windows XP est bien plus intéréssant que sous
FreeBSD.

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.

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.

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.

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.

Cela se mesure sur la concurence et ce même si elle est moins massivement
utilisée.

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.

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.

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à

Oulla attention, il ne faut pas non plus faire d'amalgame. Certes certains
produits chez microsofts sont vraiment mal faits (du moins au vu du nombre
de failles et de bugs publiées) mais il en a aussi chez d'autres editeurs
de logiciels voir dans le monde opensource.

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 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.

Chris

Laurent Seguin wrote:

"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.

Les conséquences sont principalement l'accès à la machine avec les droit de
l'utilisateur, qui est bien souvent administrateur sur une machine
familiale. Cette conséquence est plus imputable à l'OS ou à l'utilisateur
qu'au logiciel lui-même.

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.

Oui, j'avais bien compris. Par contre, aurais-tu des exemples de ce que
devraient être une telle politique sécuritaire, sachant que ce rôle est,
selon moi, plus de la responsabilité du système d'exploitation que du
logiciel en lui-même. Un exemple qui me vient, c'est d'empecher les contenus
actifs. Ce serait une décision clairement sécuritaire, mais qui s'accompagne
de son lot d'inconvénients.

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é.

Là tu me surprends un peu. Aurais-tu un exemple concret de tels trous béants
qui ne serait pas lié à un bug(*) ?

(*) Ce que j'appelle du code robuste est du code permettant tant de limiter
l'apparition de bugs que leurs effets.

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.

C'est ce que je viens de faire (peut-être les 15 dernières) et les failles
présentent toutes les caractéristiques d'une attaque par débordement de
tampon, même si le mot n'a pas été dit clairement (les termes "exécution de
code arbitraire" et "non-vérification des entrées" impliquent souvent un
débordement de tampon).

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 :-)

On y trouve un recensement des bugs repérés mais aucune analyse en termes de
design.

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.

C'est vrai que le fait que des serveurs IIS soient plus souvent attaqués que
d'autres systèmes est intéressant. Mais là encore, celà reste insuffisant en
soi pour affirmer qu'il est *intrinsèquement* moins robuste ou sécurisé.
Comme explication plausible, il me vient l'idée que les administrateurs
Windows étaient jusqu'à peu beaucoup moins compétents que les
administrateurs unix. La robustesse d'un système dépend en dernier ressort
de la qualité de son administration. En particulier, il n'était pas rare à
l'époque (celle du décollage de Windows NT Server) qu'un même serveur fasse
office de serveur de domaine en même temps que de serveur Web, FTP ou mail,
ce qui en faisaient des cibles privilégiées.

Je ne dis pas que IIS est bien conçu, pas plus que je ne dis qu'il est mal
conçu. Je dis simplement que le type de failles me semblent du même ordre
que celles qu'on trouve ailleurs, et que leur nombre peut s'expliquer tout
autant par des explications purement humaines ou sociologiques que par des
problèmes de conception non sécurisée.

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.

C'est bien possible, même si je ne me prononcerai personnellement pas sans
avoir lu de description précise des failles en question. Ce qui est certain
(là je suis d'accord avec toi), c'est que les technologies basées sur les
contenus actifs (scripts, activeX) ne semblent pas avoir fait de la sécurité
leur préoccupation majeure à l'origine (peut-être un héritage imposé par
COM).

Cela se mesure sur la concurence et ce même si elle est moins
massivement utilisée.

Mais précisément pour cette raison, plus le fait qu'il est impossible
d'auditer le code source, il est impossible d'établir une quelconque mesure
qui soit fiable voire simplement éclairé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.

Il y a tout de même une assez forte corrélation.

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.

Je ne pense pas que celà ne se discute réellement. Ce n'est certainement pas
le seul facteur, mais c'en est un. Celà ne veut pas dire qu'un produit X
aura forcément plus de bugs qu'un produit Y sous le seul pretexte qu'il est
plus gros, mais c'est tout de même une tendance observable, particulièrement
entre les différentes versions d'un même logiciel (les versions plus
récentes ayant tendance à être plus volumineuses). Par ailleurs, Open Office
me semble moins lourd que son équivallent microsoft, soit parce qu'il offre
moins de fonctionnalités, soit parce qu'il bénéficie d'un meilleur design (à
supposer que le volume final reste un critère important du point de vue du
design). Pour finir, l'open office est tout de même bien plus récent. Bref,
il me parait plus exact de dire que moins de failles ont été trouvées à
cejour plutôt qu'il comporte en soi moins de failles.

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/

Comme je l'ai dit plus haut, ce sont des références sérieuses en matière de
recensement des bugs mais qui n'apporte pas réellement d'information
technique (ceci dit, j'ai profité de l'occasion pour les mettre dans mes
favoris).

Chris

On 23 Oct 2004 23:18:27 GMT, "Christophe Lephay"
<christophe-lephay@wanadoo.fr>:

Je ne suis pas certain de bien comprendre de quelle politique de sécurité tu
parles.

La sécurité, c'est un peu comme la gestion des exceptions en C++. On a
deux choix :

- soit les développeurs savent d'avance que le logiciel devra être le
plus sûr possible, et basent tout leur travail là-dessus : par
exemple, le module "affichage" est un truc totalement séparé et
hermétique, qui ne doit pas avoir accès au disque dur ; ou "Je ne sais
pas implémenter telle fonctionnalité de façon sûre, donc la
fonctionnalité sera mise en attente tant que je ne sais pas faire."

- soit les développeurs pondent un logiciel avec plein de
fonctionnalités, et trois semaines avant la fin du développement, on
s'aperçoit qu'il y a des trous partout, alors on rafistole comme on
peut. Ah tiens, pas de bol, on a oublié une demi-douzaine de trous.



--
;-)

Le Sun, 24 Oct 2004 08:58:18 +0000, Christophe Lephay a écrit :

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.


--
BOFH excuse #444:

overflow error in /dev/null

Cedric Blancher wrote:

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...

Chris

Le Sun, 24 Oct 2004 09:44:22 +0000, Christophe Lephay a écrit :

Arf, à croire que ma phrase était à nouveau ambigue !

Ah ouais...

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...

Et ? Est-ce que la rend moins vulnérable et moins facilement exploitable
qu'une machine lambda de configuration équivalente précédemment
identifiée ou prise au hasard sur une plage d'IP arbitraire ? Si une
machine possède une faille réalisable, alors l'exploitation dépend
très peu du niveau de compétence du pirate que tu mets en face, pourvu
qu'il dispose de l'outil adéquat, ce qui, l'histoire nous le montre,
n'est pas le plus compliqué.

La criticité d'une faille ne dépend que de deux facteurs directement
quantifiables : son impact et sa potentialité. Le premier mesure le
niveau d'atteinte au système obtenu lorsqu'on réalise la faille (local
root, remote root, remote shell, exécution limitée de commandes, etc.).
La seconde mesure la probabilité de réaliser la faille en fonction des
caractéristiques de la faille et du contexte, pouvant prendre en compte
la situation de la machine à laquelle elle s'applique. Sorti de ces deux
paramètres, le reste n'est que conjecture et peut mener à des
interprétations particulièrement fausses, pouvant conduire à de graves
incohérences, par exemple dans l'affectation des priorités de
résolution suite à un audit. L'exemple CodeRed/Nimda me semble très
parlant à ce sujet.

On est parti de la difficulté de pirater une machine sans connaissance
préalable, et maintenant on arrive à une machine X dont on connaît tout,
et ça devrait être difficile ? Ce thread devient suffisamment
trollesque comme ça pour qu'on ne commence pas à en rajouter en plus
avec des "c'est pas ce que je voulais dire" ou "tu m'as mal compris".


PS : tu n'es pas obliger de quoter _tout_ le message auquel tu réponds,
seules les parties pertinentes sont utiles.


--
BOFH excuse #1:

clock speed