|
RECHERCHE
|
:: Actualité ::
[Les News] [Recherche avancée] [SecALERT]
Rutkowska sur le code sécurisé
Ce qui se conçoit bien s’énonce clairement*. Joanna Rutkowska nous offre une « pensée philosophique » sur l’art de concevoir des logiciels sécurisés. Il existe, dit l’égérie des rootkits encapsulés, trois manières de concevoir un programme fiable :
- Par la minutie
- Par l’isolation
- Par l’obscurantisme
La minutie, c’est écrire des programmes en respectant les règles, en y mettant un soin, une attention, une concentration qui soient absolus.
« Vingt fois sur le métier remettez votre ouvrage.
Polissez-le sans cesse et le repolissez » *.
Hélas, nous sommes humains, et rien de ce qui est humain n’est parfait. Si écrire « proprement » est une nécessité, s’assurer de la propreté du résultat relève de l’impossible. Il n’existe aucun outil automatique qui puisse vérifier le travail de l’humain à ce stade, et en admettant même que les « langages sûrs » puissent constituer une solution, cela ne ferait que limiter les bugs d’intégration, et non ceux de conception.
La sécurité par isolation est celle qui consiste à répartir les risques au sein d’architectures segmentées : processus séparés, espaces mémoire isolés les uns des autres (ndlr : une approche tentée par les RTOS et les noyaux autonomes, auto-réparables expérimentaux). Seulement, la conception de tels ensembles pose de réelles difficultés d’intégration, auxquelles s’ajoute le fait que les noyaux actuels à partir desquels l’on pourrait imaginer ces dispositifs sont, eux, totalement monolithiques. Une faille interne à ces noyaux provoque un risque de brèche capable de briser le cloisonnement qui isole les différents processus.
Reste la sécurité par l’obscurantisme, ou plus exactement par le camouflage et les méthodes de brouillage logique. Ainsi l’adressage aléatoire ASLR et autres procédés qui contrent toute possibilité de « frappe » virale prédictive. Le programme ne s’achève jamais là où l’on peut s’y attendre, il ne s’installe jamais à la même adresse, son code compilé est d’une telle complexité qu’un Troyen n’y retrouve plus ses poulains. Bonne technique, excellent jeu de l’esprit, estime notre chercheuse. Mais qui pose là encore certains problèmes. En premier lieu, cette approche n’éradique pas le mal par la racine. Les failles, bien que cachées, existent toujours et, avec un peu de temps ou de méthode, l’on peu finir par trouver le moyen de déclencher une attaque en déni de service. Ce n’est donc qu’un pis-aller, une manière de reculer pour mieux sauter. En outre, cette montagne d’astuces empilées est susceptible de ralentir l’exécution des programmes. La méthode classique conserve tout de même certains avantages
Que le début, la fin répondent au milieu ;
Que d´un art délicat les pièces assorties
N´y forment qu´un seul tout de diverses parties*
Enfin, à l’instar de certains algorithmes de chiffrement, cette surcouche de camouflage peut elle-même cacher des défauts de conception, des failles qui rendent son fonctionnement inefficace.
Ces propos prennent une dimension quasi prophétique si l’on met en perspective cette typologie d’une part, et d’autre part l’évolution quasi certaine des systèmes d’exploitation vers des mécanismes de traitement massivement multithreadés, des opérations parallélisées synchrones, des flux de traitement optimisés pour optimiser les futures architectures multicore-multiprocesseurs.
* NdlC Note de la correctrice : Nous remercions Monsieur Nicolas Boileau de son aimable et involontaire collaboration, et ne pouvons que recommander la lecture de ses œuvre aux membres des comités ISO 27006, 7, 8 et suivants.
|
|
Les 10 actualités suivantes :
|
|
|
|
Les 10 actualités précédentes :
|
|
|
|
