Depuis quelques temps j'ai un ordinateur qui met très longtemps à m'afficher les premiers messages de grub (environ 10 secondes après les derniers messages du bios). Il me semble qu'il y a quelques années cette machine arrivait plus rapidement à l'écran d'accueil de grub.
Aussi je m'interroge :
- Existe-t-il des rootkits s'installant vraisemblablement sur le MBR et dont le chargement peut précéder celui de grub ?
- Par qel moyen un tel logiciel pourrait-il être installer via le réseau sur une distro linux généralement à jour ?
- Comment détecter, voire capturer et éventuellement analyser, en tout cas déterminer de manière probante la présence d'un tel malware?
- Est-ce que réinstaller grub depuis le linux installer pourrait éventuellement suffire à me débarrasser de cette menace ?
# hidden menu tiemout ? ou autres options de grub ?
Posté par NeoX . Évalué à 3.
ce ne serait pas une option de grub que d'attendre pour laisser le temps au disque dur de se lancer ?
ou une option pour masquer le menu pendant X secondes ?
[^] # Re: hidden menu tiemout ? ou autres options de grub ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Oui c'est d'ailleurs ce qu'il fait ; mais en laissant d'abord l'écran noir pendant une dizaine de secondes ; ce qui ne laisse pas de m'étonner.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Lecteur de disquette / ou partition manquante
Posté par Olivier (site web personnel) . Évalué à 3.
GRUB peut s'amuser à chercher à un lecteur de disquette lors du boot. Si celui-ci n'existe pas, ou que le lecteur est vide, il y a un perte significative de temps lors du boot.
Autre hypothèse : la configuration de GRUB fait qu'il cherche une partition qui n'existe plus. Regarde dans le /boot/grub/menu.lst (GRUB1) ou /boot/grub/grub.cfg (grub2), et recherche :
permet d'afficher la liste des partitions
Enfin, il est possible que ton grub/linux ait changé la manière d'accéder aux disques : de /dev/hda il est passé à /dev/sda . Auquel cas, il est nécessaire de revoir la configuration de /boot/grub/menu.lst (GRUB1) ou /boot/grub/grub.cfg (grub2).
[^] # Re: Lecteur de disquette / ou partition manquante
Posté par claudex . Évalué à 1.
Normalement, Grub est mis à jour à chaque changement de noyau via une commande automatique (enfin, ça dépend de la distribution). Ça me semble donc peu probable (mais pas impossible).
Par contre, ne serait-ce pas le bios qui soit configuré pour démarrer d'abord sur disquette, puis sur USB, puis par CD-ROM et enfin par le disque qui poserait problème (le temps qu'il vérifie chaque média) ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Lecteur de disquette / ou partition manquante
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Chez moi, c'est un vieux grub de fedora d'il y a 3 ans qui gère le démarrage ; car grub est (était) une application 32 bits difficile à compiler avec un noyau 64 bits sans activer des options de retro-compatibilité.
Peut-être, mais d'une part la configuration de la machine n'a pas changé depuis sa mise en service, et d'autre part l'intervalle de dix secondes mentionné intervient une fois que les messages du bios se sont tous effacés.
Mais tout cela mérite certainement vérification. Merci pour les pistes.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Lecteur de disquette / ou partition manquante
Posté par claudex . Évalué à 3.
Je parlais de la configuration. Chaque fois que le nom du fichier de ton noyau change, la configuration de grub doit être mise à jour.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Lecteur de disquette / ou partition manquante
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Cette mise à jour là, je la commet « nécessairement » à chaque recompilation de noyau. J'aime bien garder les anciennes versions en réserve ; dans l'éventualité où j'aurais brisé quelques chose.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# rootkit en MBR -> très petit et donc rapide !
Posté par fred71 . Évalué à 2.
un rootkit en MBR sera composé de quelques centaines ou milliers d'instructions assembleur, ce qui devrait être invisible à un humain (pour ordre de grandeur, un simple petit printf exécute 645 000 instructions RING3+RING0).
Si tu veux analyser ton boot, tu peux faire exécuter une VM utilisant ce disque et tracer les instructions mais c'est pas mal de boulot quand même. (<pub>Si c'est dans un cadre professionnel et que tu as des moyens, on fait ce genre de presta à Tetrane </pub>)
[^] # Re: rootkit en MBR -> très petit et donc rapide !
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Mais rien n'empêche d'aller ensuite chercher pleins de jolies instructions, voir un noyau complet sur une partition, puis de faire semblant de laisser gentiment la main au chargeur de démarrage normal. Non ?
C'est dans un cadre professionnel mais sans aucun moyen …
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: rootkit en MBR -> très petit et donc rapide !
Posté par fred71 . Évalué à 2.
ben, le but d'un rootkit c'est d'être "invisible", donc... :)
Par exemple, un rootkit en MBR peut installer un bout de code en mémoire, protéger cette mémoire et lui donner des privilèges élevés. Ça, ça prend rien comme temps :)
Ensuite, depuis ton OS lancé, une petite appli peut utiliser ce MBR en allant taper dans cette zone "spéciale", qui lui donnera les maxi pouvoirs.
Donc si tu as noté un net ralentissement, à chaque démarrage, c'est soit un très mauvais rootkit soit, plus probablement, totalement autre chose (un disque qui fatigue ? un nouveau périphérique ? une carte réseau qui cherche à booter en réseau (PXE et autres) ? une nouvelle option de grub ? etc...)
[^] # Re: rootkit en MBR -> très petit et donc rapide !
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
En fait j'imagine(/ais) un logicielle ne s'appuyant pas du tout sur des exécutables de mon linux. En effet, sauf à ce qu'un élément de la chaîne de compilation soit corrompu, un petit « emerge -e @world » suffit normalement à nettoyer raisonnablement bien les binaires du système.
Mais tout cela ne sont que des élucubrations d'un type sans aucune connaissances en matière de menaces informatiques. Si personne n'a jamais entendu parler de telles vers, il est peu probable qu'il y en ait un qui soit justement arrivé sur ma machine et uniquement sur elle.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: rootkit en MBR -> très petit et donc rapide !
Posté par fred71 . Évalué à 2.
Même si tu avais affaire à un macro-rootkit, qui contiendrait une stack-IP et exfilterait toutes tes saisies claviers + sniff réseau local vers une machine distante, la durée de chargement ne serait pas notable au boot, 1 seconde graaaand maxi sur une machine moderne. Ou alors ce serait un mauvais :)
Et ce genre de système devrait contenir un hyperviseur, il y aurait de grandes chances que ton 'vrai' OS se comporte différemment (essaie de lancer virtualbox ou vmware, et regarde leurs logs. Si ils tournent dans un autre hyperviseur ils vont te le dire). À moins que ce soit un truc encore plus tordu (genre ce que fait Joanna Rutkowska) mais ça voudrait dire que tu serais une cible super importante, et tu ne posterais pas ici :p
Bref, c'est très peu probable :)
Cependant, ce n'est pas parce que ce n'est pas répandu ou connu que ça n'existe pas, surtout dans ce monde là :)
De manière générale, si tu as une activité sensible et que tu soupçonnes une intrusion/espionnage, je t'invite à te rapprocher d'organismes d'état (DCRI, DPSD, etc... tous ont des antennes régionales et sont très accessibles) qui pourront te conseiller, et éventuellement te rediriger vers l'anssi, ou des privés comme nous.
[^] # Re: rootkit en MBR -> très petit et donc rapide !
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Je n'en suis pas là. Non pas que le sujet sur lequel ne travail soit sans intérêt, loin de là ; mais plutôt parce que le gars assez doué pour tirer profit de mon travail avant que je ne le publie serait nécessairement plus doué que moi et perdrait donc définitivement son temps. En plus les codes que j'écris sont sous GPL et un simpe courrier suffirait à les obtenir avant publication.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# bug du bios ?
Posté par solsTiCe (site web personnel) . Évalué à 1.
ayant un inspiron 531 de chez dell j'ai toujours eu un délai d'au moins 20 secondes pour passer le POST.
C'est un bug du bios. en débranchant le lecteur de cartes intégré, ca marche mieux.
http://en.community.dell.com/support-forums/desktop/f/3514/p/18751058/18874044.aspx#18874044
[^] # Re: bug du bios ?
Posté par NeoX . Évalué à 2.
et en mettant le boot sur disque dur avant le boot sur USB, ca eviterait simplement qu'il teste tous les ports du lecteur multicarte ?
[^] # Re: bug du bios ?
Posté par solsTiCe (site web personnel) . Évalué à 1.
ouais j'essaierais mais je crois que j'ai déjà du le tenter
mais de toute façon, ça n'a plus d'importance car j'utilise le lecteur de l'imprimante qui se trouve moins bas: je ne suis pas obligé de m'accroupir pour insérer une carte ;-)
[^] # Re: bug du bios ?
Posté par NeoX . Évalué à 2.
ca commence à faire beaucoup de lecteur USB à tester avant de booter.
Donc oui, si tu ne bootes jamais sur USB (sur des cartes, ou sur la clef USB), tu peux changer l'ordre de demarrage dans le BIOS, ca devrait te faire gagner quelques secondes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.