Si on part du principe que les objets sont référencés par leurs empreintes (MD5 par exemple) et les entités par leurs bi-clés, comment évolue un virus dans un tel environnement? Comment s’en protéger?
Première constatation, toute modification d’objet se voit!
Un objet qui a déjà été vérifié (même empreinte) n’a pas à être revérifié. Il faut au minimum s’assurer qu’il n’a pas été corrompu (empreinte différente). Il doit donc être marqué (groupe) par une entité anti-virus. Le marquage peut être positif ou négatif.
Une fois vérifié à une endroit, le fichier est reconnu sain (ou non) à tous ses points de duplication, même si il est attaché à des entités qui ne se connaissent pas (pas de lien) ou n’échangent pas entre-elles. Cette validation de signatures peut-être centralisé au niveau de l’entité anti-virus et automatiquement reconnu par toute entité « cliente » qui lui sont liées, et cela pour tous les objets détenus par cette entité cliente.
Si le fichier est modifié par les voies normales, il acquière une nouvelle empreinte… et devient donc un nouvel objet enfant. sauf compromission de l’entité, ce nouvel objet apparaîtra comme non signé et donc non validé. C’est comme si une entité modifiait un objet dont elle n’est pas source, créant ainsi une bifurcation d’objets indépendante. Cette bifurcation est géré par les différentes entités comme objet externe non validé et donc non pris en compte sauf action explicite de l’entité.
Si l’objet est modifié par une voie détournée, il est toujours référencé avec une empreinte mais il en a réellement une autre. Une simple vérification de l’empreinte réelle permet de lever le problème, et de resynchroniser l’objet depuis une source externe non compromise. Indépendamment du virus, c’est un mécanisme classique de réparation de données. Cette vérification d’empreinte peut être réalisée en temps réel lors de l’utilisation des objets, c’est le mode paranoïaque. Elle peut être aussi réalisé lors de phases de maintenance régulières, pas très sûr mais beaucoup moins pénalisante en temps et ressources sur de gros objets. La vérification d’empreinte étant de toute façon plus performante qu’une vérification intégrale par un anti-virus, et cette vérification étant systématique sur les ordinateurs actuels, elle doit rester systématique.
Il est fort probable que l’entité hôte des objets qui permet des modifications par des voies détournées soit elle-même corrompue. Si c’est une entité relai ce n’est pas grave, toute entité autre qui récupère un objet le rejettera comme invalide juste avec le mécanisme de vérification d’empreintes. Si c’est l’entité détentrice et signataire des objets… pourquoi se faire c***r à corrompre un objet alors qu’on peut simplement le modifier, signer et diffuser le nouvel objet enfant comme étant le remplaçant légitime…
Si l’objet est chiffré, même sans avoir à le communiquer, on sait si il est sain ou non. A condition que cet objet ai été présenté à l’entité anti-virus préalablement… Le processus de vérification de l’anti-virus se fait-il depuis l’entité cliente? Ou se fait-il par partage de l’objet proprement dit, et en clair, avec l’entité anti-virus? Dans le cas du partage, cela implique que l’on transmette de l’information sensible (qui nécessite chiffrement) à une entité tierce que l’on ne contrôle pas (qui peut à son tour potentiellement la rediffuser). Cela implique un temps de transfert et donc de traitement plus long. A moins que l’on dispose d’une copie d’entité anti-virus entièrement sous contrôle et apte uniquement à la vérification d’objets. De cette façon, on peut même cumuler différentes entités anti-virus concurrentes sans problème. Si on ne partage pas les objets à une entité anti-virus, il faut greffer un processus supplémentaire à entité cliente, et augmenter potentiellement le risque de compromission de cette entité.
Lors d’une mise à jours des signatures anti-virus, il faut refaire tout le processus de vérification des objets. En effet, un objet peut contenir un code malveillant non reconnu par un anti-virus, notamment lorsque ce code malveillant est tout nouveau. On gagne clairement à mettre en commun le résultat de ces vérifications.
Que fait-on d’un objet tant qu’il n’est pas vérifié par un anti-virus? On garde le même comportement que sur les ordinateurs actuels, l’objet n’est pas utilisable tant que l’anti-virus n’a pas fini le scan.
La contamination d’une machine hôte se constate soit par la diffusion régulière d’objets corrompus, dans ce cas c’est le mécanisme de correction d’erreurs qui entre en jeu. Soit elle se constate par la diffusion d’objets infectés, mais ces objets n’étant pas signés ils ne sont normalement pas pris en compte.
La contamination d’une entité ne se détecte que par la diffusion d’objets signés et infectés, c’est l’anti-virus sur l’entité réceptrice qui le détecte. L’empreinte de l’objet infecté étant diffusé par l’entité anti-virus, tout le monde (abonné à l’anti-virus) va instantanément reconnaître cet objet comme contaminé, et agir en connaissance de cause. Même l’entité contaminée peut ainsi savoir qu’elle a un problème.
Une des conséquences est que l’on va avoir naturellement tendance à unifier avec ses entités amies le choix de l’entité anti-virus retenu, avec un risque d’hégémonie d’un anti-virus et donc d’un point de vulnérabilité unique à tout un groupe d’entités proches.
Tout objet non référencé sera systématiquement passé à l’anti-virus et lié à la liste anti-virus adéquate.
Avec le temps, l’entité anti-virus va commencer à reconnaître une grand nombre d’empreintes saines ou infectées. Celle-ci va indéfiniment augmenter le nombre d’objets reconnus sans pour autant les stocker directement. Les objets reconnus contaminés seront liés par un objet spécifique, par exemple la « liste des contaminés ». Pour les objets reconnus non contaminés, ils ne seront liés que à l’objet intégrant les mises à jours anti-virus, plus spécifiquement à la version en cours, et ne seront pas transmis à la nouvelles version des mises à jours (objet enfant).
Une entité anti-virus peut à un instant donné déclarer un objet sain, puis suite à une mise à jour, déclarer le même objet comme infecté. Il faut aussi prévoir aussi le mécanisme inverse qui peut être mis en place suite à un faux positif avéré sur un objet. Prévoir un mécanisme de suppression du lien d’un faux positif vers l’objet « liste des contaminés ». Une requête sur l’immunité d’un objet spécifique doit se faire en premier sur la « liste des contaminés », puis sur l’objet mise à jour anti-virus courante.
Une entité anti-virus peut décider ou se voir imposer de déclarer certains objets comme infectés alors qu’ils ne le sont pas réellement. Par exemple déclarer que tel programme ou tel fichier vidéo ne doit être utilisé par personne. Le déclarer comme infecté est un bon moyen pour en limiter fortement l’usage. Cela peut être légitime ou non, et n’a rien à faire dans la lutte anti-virus de toute façon. L’utilisateur doit pouvoir entretenir une liste blanche (et une liste noir) d’objets qu’il considère comme sûr (ou non), et éventuellement s’abonner en plus à une entité dédié à la chasse aux objets illicites.
(Lien sur le wiki : http://wiki.nebule.org/nebule/…#Anti-virus )
2 réflexions au sujet de « Réflexion – Et l’anti-virus alors? »