At 10:10 05.06.02, you wrote:
>On Wed, 5 Jun 2002, Daniel Cordey wrote:
>
> > commandes (ps, ls, telnet...), des modules du kernel et y compris le
> kernel
> > lui-m�me :-(
>
>allons-y: le BIOS (les cartes-m�res modernes n'ont plus de jumper/cavalier
>pour d�sactiver la programmation de l'EEPROM du BIOS), voire le microcode
>du processeur, voir les BIOS ou les microcodes des processeurs sp�cialis�s
>(un `virus' dans un chip SCSI est possible, car en g�n�ral ces chips sont
>programmables (dans un langage genre assembleur, RTL), ma�tres de bus et
>donc peuvent �crire et lire toute la m�moire: notamment avec le QLOGIC
>10xx et 21xx je saurais comment faire --- vu qu'une fois je me suis gourr�
>et ai corrompu des donn�es kernel avec :))
Ouaaaa merci, je n'ai jamais envisag� ce genre d'infection. Avec ce genre
de truc il est posible de ne pas pouvoir faire un syst�me de restauration
sans une intervention hard.
Ce serai interesent de faire une petite marche � suivre permettant
d'annalyser l'�tat d'un syst�me et de le restaurer en cas de doute. J'ai
quelques id�es que je couche en vrac pour voir si cela inspire quelques
personnes.
Cr�ation d'un cd bootable adapter � une config permettant de :
* booter avec un disque ram avec un minimum d'applications propre.
* se loger en root mono-utilisateur en n'utilisant si possible aucun
autre resource � part le bios.
* Faire un contr�l de checksum du BIOS et des diff�rents firmwares ou
microcode si ce n'est pas la premi�re utilisation. Si le control n'est pas
correcte remise � jour de ceux-ci. Il est possible que le chargement du
bios ou des firmwares ne soient possible qu'avec des programateurs externes.
* Generer une liste genre backup incr�mentiel des checksum's des
fichiers et des firmwares ainsi que la d�pendance entres fichiers et les
packages (RPM, debian etc) en recopiants les fichiers concern� et
�ventuellement les logs des backups des donn�es utilisateurs sur un support
non effacable.
* Controler les changements des checksum's et d�terminations
automatiques des packages et des donn�es utilisateurs devants �tre
r�install�s.
* R�installation des packages vitaux permettant un chroot et de pouvoir
r�installer les autres packages facilements.
* R�installation du reste des packages depuis une sources fiable apr�s
le chroot.
* R�installation des donn�es utilisateurs touch�es depuis les backup's
de la derni�re version jug�e fiable.
Ne vous privez pas pour compl�ter ou corriger cette liste, elle est l� pour �a.
>Encore que je ne connaisse personne capable d'�crire du *microcode* Intel,
>vu qu'en plus la doc ne doit pas �tre tr�s disponible.
Je ne savais m�me pas qu'Intel utilisait se genre de technique, je ne me
rappelait juste que d'IBM utilisait � fond ce genre de truc sur les
processeurs de ces main-frame. Faudrai peut-�tre que je me mette � jour.
Pour ce qui est du code, cela doit �tre du genre micro-code des micro 68332
pour la partie TPU, c'est space mais c'est l� que l'on comprend comment
fonctionne une puce.
>Heureusement pour nous les concepteurs d'attaques ont plein d'autres
>m�thodes simples, en commen�ant par le social engineering (cliquez ici
>pour voir des photos X) ce qui �vite les maux de t�te, en pratique, dans
>face aux attaques les plus sophistiqu�es.
Il est ou le lien ?
A+
Martial
----------
MuTECH
Martial Guex
Rue des Alpes
1452 Les Rasses
Switzerland
Phone : +41 24 454 46 35
Fax. : +41 24 454 46 32
Email : [EMAIL PROTECTED] ([EMAIL PROTECTED] for Microsoft Outlook users)
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
