[Rapport CCIA] - Le monopole de MS represente un risque

JustMe

27/09/2003 à 18:33

Fabien LE LEZ wrote:

On 27 Sep 2003 15:13:56 GMT, Manuel Viet
wrote:

Peut-être faut-il prendre en compte la spécificité des logiciels
inclus dans windows, tout de même. Les failles de linux existent,
et elles sont exploitées également, mais les logiciels de courrier,
en particulier, sont souvent beaucoup plus sûrs sous linux que
sous windows

Euh... Ne pas confondre "Outlook" et "Windows", quand même. Ça
m'étonnerait beaucoup que Mozilla ou Thunderbird soit franchement
moins sûr sous Windows que sous Linux.

bof si... Windows est une saleté en terme de gestion mémoire, controle
des process et controle des droits.... On ne peut jamais faire de bonnes
constructions sur des fondations pourries...

Manuel Viet

27/09/2003 à 18:57

Le 27 Sep 2003 15:58:06 GMT, Stephane Catteau écrivait:

Manuel Viet nous disait récement dans fr.comp.securite
<news: :

Le 27 Sep 2003 14:39:50 GMT, Stephane Catteau écrivait:

Peut-être faut-il prendre en compte la spécificité des logiciels
inclus dans windows, tout de même.
Tu confonds Outlook Express et "l'ensemble des logiciels de courrier

disponibles sous Windows".

Non. QED. Je me plaçais sous un angle statistique, c'est tout, et
l'utilisation d'OE est ultra-majooritaire pour le courrier.

Quant aux logiciels nunux, quelque chose me dit que Kmail utilise le
moteur de Konqueror pour son rendu HTML, ce qui le place au même rang
qu'Outlook Express face aux failles du navigateur par défaut de
l'interface graphique.

Re-non ; le moteur html de konqueror reste strictement userland. Les dll
d'IE ont des accès kernel space /via/ le code du GDI qui n'est pas pur.
Enfin, c'est ce que j'ai lu, je peux bien sûr me tromper.

C'est pour cela que je ne parle jamais de linux, mais de nunux. Or,
comme chacun le sait (si si, vous le savez aussi ;-)), il s'agit d'un
terme générique désignant le noyau, les distributions, et les logiciels
qui vont avec, tout comme "Windows" désigne trop souvent l'ensemble du
système, des logiciels et des utilisateurs.

Windows a fait sa grande unification, isnt'it ?

--
Manuel * mailto:
Sed quid igitur sum ? Res cogitans. Quid est hoc ? Nempe dubitans,
intelligens, affirmans, negans, volens, nolens, imaginans quoque &
sentiens. -- Descartes

Stephane Catteau

27/09/2003 à 19:59

Manuel Viet nous disait récement dans fr.comp.securite
<news: :

Le 27 Sep 2003 15:58:06 GMT, Stephane Catteau écrivait:

Quant aux logiciels nunux, quelque chose me dit que Kmail utilise
le moteur de Konqueror pour son rendu HTML, ce qui le place au même
rang qu'Outlook Express face aux failles du navigateur par défaut
de l'interface graphique.

Re-non ; le moteur html de konqueror reste strictement userland.

Ce qui n'empèche pas ses failles d'être exploitable par le biais de
Kmail. Pour peu que l'une d'entre elle (via la console Java
probablement) permette d'injecter du code, et le fait qu'il soit
strictement userland n'empèchera pas d'installer et utiliser un
rootkit.

Les dll d'IE ont des accès kernel space /via/ le code du GDI qui
n'est pas pur. Enfin, c'est ce que j'ai lu, je peux bien sûr me
tromper.

Tu ne te trompes pas, mais ce n'est pas à proprement parler un exploit
que d'arriver à un tel résultat. Cela tout simplement parce que,
jusqu'à XP et pour les éditions domestiques uniquement évidement,
Windows n'intègre pas la notion d'utilisateur. Il n'y a donc aucun
cloisonnement. Cependant, se baser sur ce cloisonnement pour dire "l'OS
est vraiment sûr", revient à ignorer qu'il n'est pas invulnérable.
D'ailleurs, la vrai faiblesse d'un nunux majoritaire viendrait de ce
qui fait aussi sa force, l'accessiblité des sources. Non que l'on
puisse y trouver plus facilement des failles, mais parce que l'on n'a
aucun mal à trojaner une lib ou une commande, tout comme l'on n'a aucun
mal à simuler l'ensemble de ses actions. Du coup, il suffit d'arriver à
prendre la main sur mv ou cp, ne serait-ce qu'une minute le temps de
les remplacer par une version à soit, pour pourvoir ensuite passer
outre les droits d'accès aux fichiers en remplacant simplement un
binaire ici, une lib là, par une version à soi qui se foutra royalement
des-dits droits. A partir de là la porte est grande ouverte.
Evidement, ce n'est pas quelque chose de trivial, mais si nunux
devenait majoritaire, ce genre d'attaque finirait par devenir à la
porter du premier script-kiddy venu. On pourrait même envisager des
outils avec une gestion des failles par plug-in. L'outil en lui-même
s'occupant d'installer les outils qui iront bien sur le système cible,
en utilisant le plug-in correspondant à la faille exploitable.
A noter que si ce problème n'est pas valable que pour nunux, des
systèmes comme les BSD, qui permettent de recompiler l'ensemble du
système en moins de dix lignes de commandes, minimisent les risques.

C'est pour cela que je ne parle jamais de linux, mais de nunux.
Or, comme chacun le sait (si si, vous le savez aussi ;-)), il s'agit
d'un terme générique désignant le noyau, les distributions, et
les logiciels qui vont avec, tout comme "Windows" désigne trop
souvent l'ensemble du système, des logiciels et des utilisateurs.

Windows a fait sa grande unification, isnt'it ?

Tout comme les distributions nunux grand public sont entrain d'unifier
KDE et gnome, et finiront par nous sortir des versions en init 5
d'office et Windows compliant :-(

--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Manuel Viet nous disait récement dans fr.comp.securite
<news:slrn3utdmu3c17so8.dtt.manuel@fatboy.m-viet.net> :

Le 27 Sep 2003 15:58:06 GMT, Stephane Catteau écrivait:

Quant aux logiciels nunux, quelque chose me dit que Kmail utilise
le moteur de Konqueror pour son rendu HTML, ce qui le place au même
rang qu'Outlook Express face aux failles du navigateur par défaut
de l'interface graphique.

Re-non ; le moteur html de konqueror reste strictement userland.

Ce qui n'empèche pas ses failles d'être exploitable par le biais de
Kmail. Pour peu que l'une d'entre elle (via la console Java
probablement) permette d'injecter du code, et le fait qu'il soit
strictement userland n'empèchera pas d'installer et utiliser un
rootkit.

Les dll d'IE ont des accès kernel space /via/ le code du GDI qui
n'est pas pur. Enfin, c'est ce que j'ai lu, je peux bien sûr me
tromper.

Tu ne te trompes pas, mais ce n'est pas à proprement parler un exploit
que d'arriver à un tel résultat. Cela tout simplement parce que,
jusqu'à XP et pour les éditions domestiques uniquement évidement,
Windows n'intègre pas la notion d'utilisateur. Il n'y a donc aucun
cloisonnement. Cependant, se baser sur ce cloisonnement pour dire "l'OS
est vraiment sûr", revient à ignorer qu'il n'est pas invulnérable.
D'ailleurs, la vrai faiblesse d'un nunux majoritaire viendrait de ce
qui fait aussi sa force, l'accessiblité des sources. Non que l'on
puisse y trouver plus facilement des failles, mais parce que l'on n'a
aucun mal à trojaner une lib ou une commande, tout comme l'on n'a aucun
mal à simuler l'ensemble de ses actions. Du coup, il suffit d'arriver à
prendre la main sur mv ou cp, ne serait-ce qu'une minute le temps de
les remplacer par une version à soit, pour pourvoir ensuite passer
outre les droits d'accès aux fichiers en remplacant simplement un
binaire ici, une lib là, par une version à soi qui se foutra royalement
des-dits droits. A partir de là la porte est grande ouverte.
Evidement, ce n'est pas quelque chose de trivial, mais si nunux
devenait majoritaire, ce genre d'attaque finirait par devenir à la
porter du premier script-kiddy venu. On pourrait même envisager des
outils avec une gestion des failles par plug-in. L'outil en lui-même
s'occupant d'installer les outils qui iront bien sur le système cible,
en utilisant le plug-in correspondant à la faille exploitable.
A noter que si ce problème n'est pas valable que pour nunux, des
systèmes comme les BSD, qui permettent de recompiler l'ensemble du
système en moins de dix lignes de commandes, minimisent les risques.

C'est pour cela que je ne parle jamais de linux, mais de nunux.
Or, comme chacun le sait (si si, vous le savez aussi ;-)), il s'agit
d'un terme générique désignant le noyau, les distributions, et
les logiciels qui vont avec, tout comme "Windows" désigne trop
souvent l'ensemble du système, des logiciels et des utilisateurs.

Windows a fait sa grande unification, isnt'it ?

Tout comme les distributions nunux grand public sont entrain d'unifier
KDE et gnome, et finiront par nous sortir des versions en init 5
d'office et Windows compliant :-(

--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Vous avez filtré cet utilisateur ! Consultez son message

Manuel Viet nous disait récement dans fr.comp.securite
<news: :

Le 27 Sep 2003 15:58:06 GMT, Stephane Catteau écrivait:

Quant aux logiciels nunux, quelque chose me dit que Kmail utilise
le moteur de Konqueror pour son rendu HTML, ce qui le place au même
rang qu'Outlook Express face aux failles du navigateur par défaut
de l'interface graphique.

Re-non ; le moteur html de konqueror reste strictement userland.

Ce qui n'empèche pas ses failles d'être exploitable par le biais de
Kmail. Pour peu que l'une d'entre elle (via la console Java
probablement) permette d'injecter du code, et le fait qu'il soit
strictement userland n'empèchera pas d'installer et utiliser un
rootkit.

Les dll d'IE ont des accès kernel space /via/ le code du GDI qui
n'est pas pur. Enfin, c'est ce que j'ai lu, je peux bien sûr me
tromper.

Tu ne te trompes pas, mais ce n'est pas à proprement parler un exploit
que d'arriver à un tel résultat. Cela tout simplement parce que,
jusqu'à XP et pour les éditions domestiques uniquement évidement,
Windows n'intègre pas la notion d'utilisateur. Il n'y a donc aucun
cloisonnement. Cependant, se baser sur ce cloisonnement pour dire "l'OS
est vraiment sûr", revient à ignorer qu'il n'est pas invulnérable.
D'ailleurs, la vrai faiblesse d'un nunux majoritaire viendrait de ce
qui fait aussi sa force, l'accessiblité des sources. Non que l'on
puisse y trouver plus facilement des failles, mais parce que l'on n'a
aucun mal à trojaner une lib ou une commande, tout comme l'on n'a aucun
mal à simuler l'ensemble de ses actions. Du coup, il suffit d'arriver à
prendre la main sur mv ou cp, ne serait-ce qu'une minute le temps de
les remplacer par une version à soit, pour pourvoir ensuite passer
outre les droits d'accès aux fichiers en remplacant simplement un
binaire ici, une lib là, par une version à soi qui se foutra royalement
des-dits droits. A partir de là la porte est grande ouverte.
Evidement, ce n'est pas quelque chose de trivial, mais si nunux
devenait majoritaire, ce genre d'attaque finirait par devenir à la
porter du premier script-kiddy venu. On pourrait même envisager des
outils avec une gestion des failles par plug-in. L'outil en lui-même
s'occupant d'installer les outils qui iront bien sur le système cible,
en utilisant le plug-in correspondant à la faille exploitable.
A noter que si ce problème n'est pas valable que pour nunux, des
systèmes comme les BSD, qui permettent de recompiler l'ensemble du
système en moins de dix lignes de commandes, minimisent les risques.

C'est pour cela que je ne parle jamais de linux, mais de nunux.
Or, comme chacun le sait (si si, vous le savez aussi ;-)), il s'agit
d'un terme générique désignant le noyau, les distributions, et
les logiciels qui vont avec, tout comme "Windows" désigne trop
souvent l'ensemble du système, des logiciels et des utilisateurs.

Windows a fait sa grande unification, isnt'it ?

Tout comme les distributions nunux grand public sont entrain d'unifier
KDE et gnome, et finiront par nous sortir des versions en init 5
d'office et Windows compliant :-(

--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

John Doe

28/09/2003 à 00:56

Stephane Catteau wrote:

Du coup, il suffit d'arriver à
prendre la main sur mv ou cp, ne serait-ce qu'une minute le temps de
les remplacer par une version à soit, pour pourvoir ensuite passer
outre les droits d'accès aux fichiers en remplacant simplement un
binaire ici, une lib là, par une version à soi qui se foutra royalement
des-dits droits. A partir de là la porte est grande ouverte.

Le fait d'avoir un mv ou un cp à soit ne permet pas de passer outre les
droits d'accès aux fichiers (ou alors j'ai très mal compris...).
Les droits sont gérés pas le système qui permet l'ouverture ou non d'un
fichier.

Stephane Catteau

28/09/2003 à 01:47

John Doe nous disait récement dans fr.comp.securite
<news:bl53gv$22k7$ :

Le fait d'avoir un mv ou un cp à soit ne permet pas de passer
outre les droits d'accès aux fichiers (ou alors j'ai très mal
compris...). Les droits sont gérés pas le système qui permet
l'ouverture ou non d'un fichier.

Mais rien ne t'oblige à demander la permission au système. Code ton mv
ou ton cp pour qu'il fasse tout au plus bas niveau, en pompant
directement le code de toutes les fonctions externes utilisées à la
fois pas la commande et par les fonctions externes qu'elle utilise (en
remontant finalement jusqu'au kernel), et il te suffit ensuite de
modifier le controle des droits dans ton propre source. Dans la mesure
où tu as accès à tous les sources, il n'y a rien qui t'en empèche.
Raffinement suprème, tu peux faire cela par le biais d'un paramètre de
ton cru, ce qui permettra de garder un comportement normal sauf lorsque
c'est toi qui l'utilise avec l'option qui va bien.
Bon, il est probable que ça te fasse un cp ou un mv de grande taille,
mais si quelqu'un contrôle sérieusement l'intégrité du binaire[1], il
trouverait la modification même si elle n'ajoutait qu'un octet.
Le plus dur dans l'histoire reste d'arriver à installer ta version, le
reste n'importe quel programmeur C est capable de le faire.

[1]
Via un hash md5 par exemple.
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Stephane Catteau

28/09/2003 à 01:47

Thierry Herbelot nous disait récement dans fr.comp.securite
<news:3f75e993$0$27034$ :

Stephane Catteau wrote:

A noter que si ce problème n'est pas valable que pour nunux, des
systèmes comme les BSD, qui permettent de recompiler l'ensemble
du système en moins de dix lignes de commandes, minimisent les
risques.

bien qu'étant un partisan de la recompilation de l'OS [1], ce
n'est pas une vraie bonne solution :
cet article (http://www.acm.org/classics/sep95/) montre comment
conserver une porte dérobée, même dans du logiciel "ouvert".

Je ne la vois pas comme une solution à part entière, mais comme un
plus par rapport à d'autres options possibles. Il faudra que
l'attaquant ait pensé à une astuce comme celle du lien que tu donnes[1]
pour que la recompilation ne serve à rien. De là, les plus paranos
pourront toujours augmenter leurs chances en allant récupérer le
binaire du compilateur[2] directement sur le FTP officiel du système.
Et s'ils sont encore paranos, ils peuvent le planquer dans un coin et
attendre une journée ou deux pour le cas où l'on s'apercevrait que le-
dit FTP a été compromis et que les binaires contienne du code hostile.
Pour ma part, je reste un petit parano et me contenterait d'un
recompilation ;-)

la recompilation des OS pose en fait un autre problème, qui est la
définition "certaine" des bons bits des exécutables (vu que chacun
les compile dans son coin, qui a raison quand deux machines ont
des binaires différents ? - au moins, quand les compilations sont
réalisées à Redmont, on a un jeu de binaires "de référence", même
si ces binaires sont par ailleurs pleins de trous)

Le binaire de référence reste le sien, avec ses petits bouts de code à
soi qu'on a fait comme un grand, et en priant qu'il n'y a pas aussi des
petits bouts de codes à un autre qui viennent s'y promener. Il suffit
d'avoir une machine de référence hors réseau pour pouvoir comparer par
la suite.

Ca me fait penser à une option qui permet de se débarasser du risque
que tu signales, la recompilation sur un ordinateur tier hors réseau.

1) On raccorde la machine A au réseau pour un petit coup de cvsup.
2) On débranche la machine A du réseau
3) On compile bien sagement sur la machine A
4) On passe le serveur B en mono-utilisateur
5) On configure le filtre de la machine A pour n'autoriser qu'une
connexion du client NFS du serveur B
6) On rebranche la machine A sur le réseau et on active le serveur NFS
7) On installe le monde sur le serveur B via NFS
8) On configure le filtre de la machine A pour ne plus autoriser les
connexions en provenance du serveur B
9) On repasse le serveur B en multi-utilisateur
10) on boucle en 4 jusqu'à ce qu'il n'y ait plus de serveur à
installer.
11) On débranche la machine A et on y refait un installation complète
depuis le CD.

Ca n'est pas sécurisé à 100%, mais les différentes fenêtres d'actions
restent courtes et il faut arriver à les chopper au bon moment. Il n'en
reste pas moins qu'il est préférable de ne pas faire ça à date fixe, et
qu'il faut installer les serveurs dans un ordre aléatoire, de façon à
éviter toute prédictibilité qui rendrait ces fenêtres plus facilement
exploitables.

[1]
Au passage merci pour lui.
[2]
En fait les binaires des différents éléments intervenant dans la
chaîne de reconstruction, ce qui inclus donc au moins make et perl.
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Thierry Herbelot nous disait récement dans fr.comp.securite
<news:3f75e993$0$27034$626a54ce@news.free.fr> :

Stephane Catteau wrote:

A noter que si ce problème n'est pas valable que pour nunux, des
systèmes comme les BSD, qui permettent de recompiler l'ensemble
du système en moins de dix lignes de commandes, minimisent les
risques.

bien qu'étant un partisan de la recompilation de l'OS [1], ce
n'est pas une vraie bonne solution :
cet article (http://www.acm.org/classics/sep95/) montre comment
conserver une porte dérobée, même dans du logiciel "ouvert".

Je ne la vois pas comme une solution à part entière, mais comme un
plus par rapport à d'autres options possibles. Il faudra que
l'attaquant ait pensé à une astuce comme celle du lien que tu donnes[1]
pour que la recompilation ne serve à rien. De là, les plus paranos
pourront toujours augmenter leurs chances en allant récupérer le
binaire du compilateur[2] directement sur le FTP officiel du système.
Et s'ils sont encore paranos, ils peuvent le planquer dans un coin et
attendre une journée ou deux pour le cas où l'on s'apercevrait que le-
dit FTP a été compromis et que les binaires contienne du code hostile.
Pour ma part, je reste un petit parano et me contenterait d'un
recompilation ;-)

la recompilation des OS pose en fait un autre problème, qui est la
définition "certaine" des bons bits des exécutables (vu que chacun
les compile dans son coin, qui a raison quand deux machines ont
des binaires différents ? - au moins, quand les compilations sont
réalisées à Redmont, on a un jeu de binaires "de référence", même
si ces binaires sont par ailleurs pleins de trous)

Le binaire de référence reste le sien, avec ses petits bouts de code à
soi qu'on a fait comme un grand, et en priant qu'il n'y a pas aussi des
petits bouts de codes à un autre qui viennent s'y promener. Il suffit
d'avoir une machine de référence hors réseau pour pouvoir comparer par
la suite.

Ca me fait penser à une option qui permet de se débarasser du risque
que tu signales, la recompilation sur un ordinateur tier hors réseau.

1) On raccorde la machine A au réseau pour un petit coup de cvsup.
2) On débranche la machine A du réseau
3) On compile bien sagement sur la machine A
4) On passe le serveur B en mono-utilisateur
5) On configure le filtre de la machine A pour n'autoriser qu'une
connexion du client NFS du serveur B
6) On rebranche la machine A sur le réseau et on active le serveur NFS
7) On installe le monde sur le serveur B via NFS
8) On configure le filtre de la machine A pour ne plus autoriser les
connexions en provenance du serveur B
9) On repasse le serveur B en multi-utilisateur
10) on boucle en 4 jusqu'à ce qu'il n'y ait plus de serveur à
installer.
11) On débranche la machine A et on y refait un installation complète
depuis le CD.

Ca n'est pas sécurisé à 100%, mais les différentes fenêtres d'actions
restent courtes et il faut arriver à les chopper au bon moment. Il n'en
reste pas moins qu'il est préférable de ne pas faire ça à date fixe, et
qu'il faut installer les serveurs dans un ordre aléatoire, de façon à
éviter toute prédictibilité qui rendrait ces fenêtres plus facilement
exploitables.

[1]
Au passage merci pour lui.
[2]
En fait les binaires des différents éléments intervenant dans la
chaîne de reconstruction, ce qui inclus donc au moins make et perl.
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Vous avez filtré cet utilisateur ! Consultez son message

Thierry Herbelot nous disait récement dans fr.comp.securite
<news:3f75e993$0$27034$ :

Stephane Catteau wrote:

A noter que si ce problème n'est pas valable que pour nunux, des
systèmes comme les BSD, qui permettent de recompiler l'ensemble
du système en moins de dix lignes de commandes, minimisent les
risques.

bien qu'étant un partisan de la recompilation de l'OS [1], ce
n'est pas une vraie bonne solution :
cet article (http://www.acm.org/classics/sep95/) montre comment
conserver une porte dérobée, même dans du logiciel "ouvert".

Je ne la vois pas comme une solution à part entière, mais comme un
plus par rapport à d'autres options possibles. Il faudra que
l'attaquant ait pensé à une astuce comme celle du lien que tu donnes[1]
pour que la recompilation ne serve à rien. De là, les plus paranos
pourront toujours augmenter leurs chances en allant récupérer le
binaire du compilateur[2] directement sur le FTP officiel du système.
Et s'ils sont encore paranos, ils peuvent le planquer dans un coin et
attendre une journée ou deux pour le cas où l'on s'apercevrait que le-
dit FTP a été compromis et que les binaires contienne du code hostile.
Pour ma part, je reste un petit parano et me contenterait d'un
recompilation ;-)

la recompilation des OS pose en fait un autre problème, qui est la
définition "certaine" des bons bits des exécutables (vu que chacun
les compile dans son coin, qui a raison quand deux machines ont
des binaires différents ? - au moins, quand les compilations sont
réalisées à Redmont, on a un jeu de binaires "de référence", même
si ces binaires sont par ailleurs pleins de trous)

Le binaire de référence reste le sien, avec ses petits bouts de code à
soi qu'on a fait comme un grand, et en priant qu'il n'y a pas aussi des
petits bouts de codes à un autre qui viennent s'y promener. Il suffit
d'avoir une machine de référence hors réseau pour pouvoir comparer par
la suite.

Ca me fait penser à une option qui permet de se débarasser du risque
que tu signales, la recompilation sur un ordinateur tier hors réseau.

1) On raccorde la machine A au réseau pour un petit coup de cvsup.
2) On débranche la machine A du réseau
3) On compile bien sagement sur la machine A
4) On passe le serveur B en mono-utilisateur
5) On configure le filtre de la machine A pour n'autoriser qu'une
connexion du client NFS du serveur B
6) On rebranche la machine A sur le réseau et on active le serveur NFS
7) On installe le monde sur le serveur B via NFS
8) On configure le filtre de la machine A pour ne plus autoriser les
connexions en provenance du serveur B
9) On repasse le serveur B en multi-utilisateur
10) on boucle en 4 jusqu'à ce qu'il n'y ait plus de serveur à
installer.
11) On débranche la machine A et on y refait un installation complète
depuis le CD.

Ca n'est pas sécurisé à 100%, mais les différentes fenêtres d'actions
restent courtes et il faut arriver à les chopper au bon moment. Il n'en
reste pas moins qu'il est préférable de ne pas faire ça à date fixe, et
qu'il faut installer les serveurs dans un ordre aléatoire, de façon à
éviter toute prédictibilité qui rendrait ces fenêtres plus facilement
exploitables.

[1]
Au passage merci pour lui.
[2]
En fait les binaires des différents éléments intervenant dans la
chaîne de reconstruction, ce qui inclus donc au moins make et perl.
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Eric Razny

28/09/2003 à 02:33

"Thierry Herbelot" <------%------thierry------% a écrit
dans le message de news:3f75e993$0$27034$

la recompilation des OS pose en fait un autre problème, qui est la
définition "certaine" des bons bits des exécutables (vu que chacun les
compile dans son coin, qui a raison quand deux machines ont des binaires
différents ? - au moins, quand les compilations sont réalisées à Redmont,
on a un jeu de binaires "de référence", même si ces binaires sont par
ailleurs pleins de trous)

Bonsoir.

Au moins quand les compilations sont réalisée sur ma machine je peux
optimiser en fonction du processeur etc... Et je n'ai donc *pas* à avoir les
même executables que mon voisin (sauf même options de compil et même
plateforme). Quand je fais tourner un serveur de jeu (bon, ok, bonjour
l'exemple!) j'en profite pour le compiler en static, le foutre dans une
root-jail avec user sans droit, grsecurity dessus etc. De plus ça permet
parfois d'être à l'abris d'un exploit lancé contre le service machin de la
distribution bidule. Je suis feignant et j'utilise des distribs mais je
vire, downloade et recompile systématiquement les trucs type openssl,
openssh, apache, sendmail, le kernel et les patches de sécu etc [1]...

Donc oui l'empreinte n'est pas la même d'un système à l'autre. Mais ce n'est
pas pour rien qu'il existe des outils comme aide ou tripwire. Le tout est de
faire le contrôle à partir d'un cd bootable et les exécutables en static.

Accessoirement les binaires "de référence" de MS varient suivant les patchs
et ne sont donc pas si facile à suivre que ça.

Et finalement je préfère mes binaires recompilés dont je dois prendre
l'empreinte pour la vérifier plus tard que des binaires plein de trous (je
te cite). Je ne pense pas que la sécurité soit meilleure en gardant des
merdes parce que je peux en contrôler l'empreinte : c'est la même que celle
de mon voisin[2] :(

Eric
[1] En écrivant je commence à me demander pourquoi je pars d'une distrib :)
[2] Je plaisante... mon voisin peut avoir le même trojan que moi! :)

"Thierry Herbelot" <------%------thierry------%------@herbelot.com> a écrit
dans le message de news:3f75e993$0$27034$626a54ce@news.free.fr...

la recompilation des OS pose en fait un autre problème, qui est la
définition "certaine" des bons bits des exécutables (vu que chacun les
compile dans son coin, qui a raison quand deux machines ont des binaires
différents ? - au moins, quand les compilations sont réalisées à Redmont,
on a un jeu de binaires "de référence", même si ces binaires sont par
ailleurs pleins de trous)

Bonsoir.

Au moins quand les compilations sont réalisée sur ma machine je peux
optimiser en fonction du processeur etc... Et je n'ai donc *pas* à avoir les
même executables que mon voisin (sauf même options de compil et même
plateforme). Quand je fais tourner un serveur de jeu (bon, ok, bonjour
l'exemple!) j'en profite pour le compiler en static, le foutre dans une
root-jail avec user sans droit, grsecurity dessus etc. De plus ça permet
parfois d'être à l'abris d'un exploit lancé contre le service machin de la
distribution bidule. Je suis feignant et j'utilise des distribs mais je
vire, downloade et recompile systématiquement les trucs type openssl,
openssh, apache, sendmail, le kernel et les patches de sécu etc [1]...

Donc oui l'empreinte n'est pas la même d'un système à l'autre. Mais ce n'est
pas pour rien qu'il existe des outils comme aide ou tripwire. Le tout est de
faire le contrôle à partir d'un cd bootable et les exécutables en static.

Accessoirement les binaires "de référence" de MS varient suivant les patchs
et ne sont donc pas si facile à suivre que ça.

Et finalement je préfère mes binaires recompilés dont je dois prendre
l'empreinte pour la vérifier plus tard que des binaires plein de trous (je
te cite). Je ne pense pas que la sécurité soit meilleure en gardant des
merdes parce que je peux en contrôler l'empreinte : c'est la même que celle
de mon voisin[2] :(

Eric
[1] En écrivant je commence à me demander pourquoi je pars d'une distrib :)
[2] Je plaisante... mon voisin peut avoir le même trojan que moi! :)

Vous avez filtré cet utilisateur ! Consultez son message

"Thierry Herbelot" <------%------thierry------% a écrit
dans le message de news:3f75e993$0$27034$

la recompilation des OS pose en fait un autre problème, qui est la
définition "certaine" des bons bits des exécutables (vu que chacun les
compile dans son coin, qui a raison quand deux machines ont des binaires
différents ? - au moins, quand les compilations sont réalisées à Redmont,
on a un jeu de binaires "de référence", même si ces binaires sont par
ailleurs pleins de trous)

Bonsoir.

Au moins quand les compilations sont réalisée sur ma machine je peux
optimiser en fonction du processeur etc... Et je n'ai donc *pas* à avoir les
même executables que mon voisin (sauf même options de compil et même
plateforme). Quand je fais tourner un serveur de jeu (bon, ok, bonjour
l'exemple!) j'en profite pour le compiler en static, le foutre dans une
root-jail avec user sans droit, grsecurity dessus etc. De plus ça permet
parfois d'être à l'abris d'un exploit lancé contre le service machin de la
distribution bidule. Je suis feignant et j'utilise des distribs mais je
vire, downloade et recompile systématiquement les trucs type openssl,
openssh, apache, sendmail, le kernel et les patches de sécu etc [1]...

Donc oui l'empreinte n'est pas la même d'un système à l'autre. Mais ce n'est
pas pour rien qu'il existe des outils comme aide ou tripwire. Le tout est de
faire le contrôle à partir d'un cd bootable et les exécutables en static.

Accessoirement les binaires "de référence" de MS varient suivant les patchs
et ne sont donc pas si facile à suivre que ça.

Et finalement je préfère mes binaires recompilés dont je dois prendre
l'empreinte pour la vérifier plus tard que des binaires plein de trous (je
te cite). Je ne pense pas que la sécurité soit meilleure en gardant des
merdes parce que je peux en contrôler l'empreinte : c'est la même que celle
de mon voisin[2] :(

Eric
[1] En écrivant je commence à me demander pourquoi je pars d'une distrib :)
[2] Je plaisante... mon voisin peut avoir le même trojan que moi! :)

Alain Thivillon

28/09/2003 à 05:49

Mais rien ne t'oblige à demander la permission au système. Code ton mv

Je pense qu'il te faut réviser un peu les fondamentaux d'Unix.

ou ton cp pour qu'il fasse tout au plus bas niveau, en pompant
directement le code de toutes les fonctions externes utilisées à la
fois pas la commande et par les fonctions externes qu'elle utilise (en
remontant finalement jusqu'au kernel), et il te suffit ensuite de

Je me demande bien comment tu vas arriver a copier un fichier sur
lesquels tu n'as pas les droits sans modifier le kernel (en imaginant
évidemment que tu n'aie pas déjà pas accès à /dev/ledisque en lecture,
ce qui voudrait dire que tu es déja root ou operator)

Enfin bon, j'ai peut être mal compris.

Cedric Blancher

28/09/2003 à 11:49

Dans sa prose, Stephane Catteau nous ecrivait :

D'ailleurs, la vrai faiblesse d'un nunux majoritaire viendrait de ce
qui fait aussi sa force, l'accessiblité des sources.

Ça me déçoit de te voir tomber dans de basses considérations de ce
genre.

Non que l'on puisse y trouver plus facilement des failles, mais parce
que l'on n'a aucun mal à trojaner une lib ou une commande, tout comme
l'on n'a aucun mal à simuler l'ensemble de ses actions.

Ce n'est pas vraiment plus compliqué sous Win32 avec un bon
désassembleur. On nous crache des pacthes pour faire sauter des
protections logicielles tous les jours, et on utilise exactement les
mêmes technique pour trojaniser des DLLs et autres exécutables. Les
rootkits sont loin d'être un exclusivité Unix.

Du coup, il suffit d'arriver à prendre la main sur mv ou cp, ne
serait-ce qu'une minute le temps de les remplacer par une version à
soit, pour pourvoir ensuite passer outre les droits d'accès aux
fichiers en remplacant simplement un binaire ici, une lib là, par une
version à soi qui se foutra royalement des-dits droits. A partir de là
la porte est grande ouverte.

Tu te perds là Stéphane. cp, mv et autres commandes nécessitant un
accès au système de fichiers n'y accèdent pas directement, mais passent
par des "appels systèmes" dont l'accès est régi par le noyau. Donc si
tu n'as pas les droits, le noyau fera échouer ta requête, quel que soit
le code que tu utilises. Ça serait trop facile sinon, tu pourrais rooter
une machine en deux temps, trois mouvements. Quand à l'accès direct aux
périphériques via les entrées de /dev, là encore, le DAC[1] est là,
géré encore une fois par le kernel.

Ce qui en gros veut dire que pour bypasser le DAC, tu dois corrompre le
kernel, en insérant par exemple un rootkit de type LKM. Et pour faire
cela, il faut être root.

Tu devrais aller jeter un coup d'oeil sur une présentation sur la
securité du kernel comme :

http://www.cartel-securite.fr/pbiondi/conf/ksec_defcon.pdf

Les bases y sont dégrossies.

[1] Discretionary Access Control

--

et je suis persuadé qu'on va bientôt pouvoir latter du
windowsien par serveur Q3 interposé :-) (la bonne parole ne se
propage jamais mieux qu'à grand coup de baffes :-))
-+- RR in Guide du linuxien pervers - "C'est beau le prosélitisme..."

Dans sa prose, Stephane Catteau nous ecrivait :

D'ailleurs, la vrai faiblesse d'un nunux majoritaire viendrait de ce
qui fait aussi sa force, l'accessiblité des sources.

Ça me déçoit de te voir tomber dans de basses considérations de ce
genre.

Non que l'on puisse y trouver plus facilement des failles, mais parce
que l'on n'a aucun mal à trojaner une lib ou une commande, tout comme
l'on n'a aucun mal à simuler l'ensemble de ses actions.

Ce n'est pas vraiment plus compliqué sous Win32 avec un bon
désassembleur. On nous crache des pacthes pour faire sauter des
protections logicielles tous les jours, et on utilise exactement les
mêmes technique pour trojaniser des DLLs et autres exécutables. Les
rootkits sont loin d'être un exclusivité Unix.

Du coup, il suffit d'arriver à prendre la main sur mv ou cp, ne
serait-ce qu'une minute le temps de les remplacer par une version à
soit, pour pourvoir ensuite passer outre les droits d'accès aux
fichiers en remplacant simplement un binaire ici, une lib là, par une
version à soi qui se foutra royalement des-dits droits. A partir de là
la porte est grande ouverte.

Tu te perds là Stéphane. cp, mv et autres commandes nécessitant un
accès au système de fichiers n'y accèdent pas directement, mais passent
par des "appels systèmes" dont l'accès est régi par le noyau. Donc si
tu n'as pas les droits, le noyau fera échouer ta requête, quel que soit
le code que tu utilises. Ça serait trop facile sinon, tu pourrais rooter
une machine en deux temps, trois mouvements. Quand à l'accès direct aux
périphériques via les entrées de /dev, là encore, le DAC[1] est là,
géré encore une fois par le kernel.

Ce qui en gros veut dire que pour bypasser le DAC, tu dois corrompre le
kernel, en insérant par exemple un rootkit de type LKM. Et pour faire
cela, il faut être root.

Tu devrais aller jeter un coup d'oeil sur une présentation sur la
securité du kernel comme :

http://www.cartel-securite.fr/pbiondi/conf/ksec_defcon.pdf

Les bases y sont dégrossies.

[1] Discretionary Access Control

--

et je suis persuadé qu'on va bientôt pouvoir latter du
windowsien par serveur Q3 interposé :-) (la bonne parole ne se
propage jamais mieux qu'à grand coup de baffes :-))
-+- RR in Guide du linuxien pervers - "C'est beau le prosélitisme..."

Vous avez filtré cet utilisateur ! Consultez son message

Dans sa prose, Stephane Catteau nous ecrivait :

D'ailleurs, la vrai faiblesse d'un nunux majoritaire viendrait de ce
qui fait aussi sa force, l'accessiblité des sources.

Ça me déçoit de te voir tomber dans de basses considérations de ce
genre.

Non que l'on puisse y trouver plus facilement des failles, mais parce
que l'on n'a aucun mal à trojaner une lib ou une commande, tout comme
l'on n'a aucun mal à simuler l'ensemble de ses actions.

Ce n'est pas vraiment plus compliqué sous Win32 avec un bon
désassembleur. On nous crache des pacthes pour faire sauter des
protections logicielles tous les jours, et on utilise exactement les
mêmes technique pour trojaniser des DLLs et autres exécutables. Les
rootkits sont loin d'être un exclusivité Unix.

Du coup, il suffit d'arriver à prendre la main sur mv ou cp, ne
serait-ce qu'une minute le temps de les remplacer par une version à
soit, pour pourvoir ensuite passer outre les droits d'accès aux
fichiers en remplacant simplement un binaire ici, une lib là, par une
version à soi qui se foutra royalement des-dits droits. A partir de là
la porte est grande ouverte.

Tu te perds là Stéphane. cp, mv et autres commandes nécessitant un
accès au système de fichiers n'y accèdent pas directement, mais passent
par des "appels systèmes" dont l'accès est régi par le noyau. Donc si
tu n'as pas les droits, le noyau fera échouer ta requête, quel que soit
le code que tu utilises. Ça serait trop facile sinon, tu pourrais rooter
une machine en deux temps, trois mouvements. Quand à l'accès direct aux
périphériques via les entrées de /dev, là encore, le DAC[1] est là,
géré encore une fois par le kernel.

Ce qui en gros veut dire que pour bypasser le DAC, tu dois corrompre le
kernel, en insérant par exemple un rootkit de type LKM. Et pour faire
cela, il faut être root.

Tu devrais aller jeter un coup d'oeil sur une présentation sur la
securité du kernel comme :

http://www.cartel-securite.fr/pbiondi/conf/ksec_defcon.pdf

Les bases y sont dégrossies.

[1] Discretionary Access Control

--

et je suis persuadé qu'on va bientôt pouvoir latter du
windowsien par serveur Q3 interposé :-) (la bonne parole ne se
propage jamais mieux qu'à grand coup de baffes :-))
-+- RR in Guide du linuxien pervers - "C'est beau le prosélitisme..."

lerailleznospamnews

28/09/2003 à 11:51

Stephane Catteau wrote:

Ce qu'il faudrait surtout, c'est qu'ils se rendent compte que si
c'était nunux qui avait la place dominante, la situation ne serait pas
si différente que cela.

Si car rapidement il n'y aurait pas un mais DES nunux, un par
constructeur de machine qui ajouterai des bouts plus ou moins à lui ce
qui rendrait l'effet spectaculaire des virus quasi nul et le
développement des souches virales un à côté nul, épisodique, sans grand
intérêt tel ce qui se passe sur les autres plateformes aujourd'hui comme
linux, BSD, Sun, Mac OSX, OS400... Bref tou l'intérêt serait d'avoir un
maximum de plateformes qui respectent des normes et non une norme d'OS.

--
Benoît Leraillez

La douleur des autres est tout à fait supportable, hors les cris.

[Rapport CCIA] - Le monopole de MS represente un risque

10 réponses

Veuillez sélectionner un problème