Commençons par montrer qu'il convient de ne pas se fier aux implémentations matérielles ou logicielles usuelles mais, au contraire, de disposer des sources et de procéder à un inventaire méticuleux des "compromis non documentés"...
Ainsi est-il commode, pour mettre au point un système d'exploitation, de placer volontairement des trappes et raccourcis à travers la sécurité. Il n'est pas rare que ces trappes et raccourcis soient laissés car ... la mise au point n'est jamais vraiment finie. Le même processus peut se répéter lors de l'installation de ce système sur un site donné.
L'infestation du réseau Internet de novembre 1988 a été facilitée par le fait que le programme sendmail (dans sa version BSD4.3) était généralement installé avec l'option debug restée ouverte, permettant à un intrus d'entrer avant l'étage de contrôle [38, 13].
On se rappellera de ce que bon nombre de solutions proposées font des hypothèses très fortes sur le hardware, par exemple de cloisonnement étanche entre les espaces d'adressage d'une même machine.
D'autre part, une évaluation [24] de fiabilité portant sur 90 routines très fréquemment utilisées a été conduite pour sept implémentations différentes d'Unix. Le résultat a été qu'il était facile de "mettre en rideau" un bon quart d'entre elles (et jusqu'à un tiers dans l'une des implémentations). Et cela pour des fautes de programmation qui sont pourtant connues pour constituer des menaces en matière de sécurité.
Ainsi, une deuxième cause de l'infestation du réseau Internet déjà mentionnée était une implémentation fautive du démon fingerd [13, 38], utilisant gets au lieu de fgets, permettant de déborder la pile d'exécution et donc de prendre le contrôle d'un processus privilégié.
Parmi les erreurs signalées comme étant les plus fréquentes : l'absence de test sur les bornes d'un tableau, les pointeurs nuls qui pointent sur 0, le non-traitement des codes de retour, les saisies (il faut saisir dans des chaînes bornées), la gestion des entiers (e.g. faut-il étendre $FF en $FFFF ou en $00FF ?), les fautes d'atomicité. C'est à dire ce que l'on pardonnerait difficilement d'un étudiant.
Selon les auteurs de [24], cet état de fait peut s'expliquer par l'origine du système Unix, d'abord outil de recherche où il était naturel de privilégier les résultats, puis enjeu commercial dans lequel les potentialités ("it tastes great") étaient plus apparentes que la fiabilité.
Mais il n'est pas certain que les erreurs d'Unix, et son côté probabiliste -au risque de 1%- ne soient pas mieux connues que ceux d'autres systèmes uniquement parce qu'Unix est plus répandu, ou se prête mieux aux tests...
Qu'il soit permis d'ajouter que la "mode" en usage parmi les programmeurs C et qui consiste à privilégier le style plutôt que les fonctionnalités, quand il ne s'agit pas simplement d'être le plus ésotérique possible, n'est probablement pas une bonne chose. Qui peut se vanter de donner le résultat du programme listé Table 12 [18] ?
