![[ICO]](/icons/blank.gif){kind=icon}
![[PARENTDIR]](/icons/back.gif){kind=icon}
Pour la postérité, sont reproduits ici, sans l'aimable autorisation du Dartmouth College, qui a fermé le site fort probablement suite à la panne d'une machine quelconque perdue dans un bureau, les McIlroy Facts, disponibles dans les archives Wikiwix. Ces quelques lignes valent leur pesant de cacahuètes, surtout en se replaçant dans le contexte des Chuck Norris Facts, qui semblent aussi fermés, ou des Bruce Schneier Facts, qui ont mal vieilli.
Exploit no0 : Doug McIlroy peut obtenir un 1 de /dev/zero.
Le fichier spécial de type caractère /dev/zero est un fichier particulier dont le contenu, si ce terme est seulement adapté, est contrôlé par le noyau d'un système d'exploitation de type Unix pour sortir une suite ininterrompue d'octets nuls 0b00000000 à tout programme qui tenterait d'en lire le contenu. La page de manuel de null(4) décrit entre autres le comportement de ce fichier. Étant un fichier de type caractère, lui sont associés des numéros majeurs et mineurs, qui sont respectivement le 1 et le 5 ; tout fichier de type caractère ayant ces même majeur et mineur aura le même comportement. Le fichier /dev/null est similaire en ce sens que toute tentative d'écriture sera acceptée, mais silencieusement stockée dans les limbes pour ne plus jamais être à nouveau lisible, en général à dessein.
Obtenir un 1 d'un fichier conçu pour ne sortir que des octets nuls constitue un exploit en soi si on considère l'obtention d'un octet comportant au moins un bit non nul : naïvement 0b00000001, représentant l'entier int 1, signé ou non signé, peu importe dans ce cas. Éventuellement, 1 peut avoir d'autres représentations. Typiquement 0b00110001 en ASCII est le code du caractère servant à représenter le chiffre 1. Un méthode triviale pour obtenir 1 de /dev/null serait donc de considérer un encodage dans lequel 0b00000000 servirait à représenter 1.
Dans le noyau Linux, l'implémentation de /dev/null se trouve dans le fichier drivers/char/mem.c, et la fonction décrivant principalement le comportement à adopter par le noyau en cas de lecture dans ce fichier est implémentée de la sorte :
static ssize_t read_iter_zero(struct kiocb *iocb, struct iov_iter *iter)
{
size_t written = 0;
while (iov_iter_count(iter)) {
size_t chunk = iov_iter_count(iter), n;
if (chunk > PAGE_SIZE)
chunk = PAGE_SIZE; /* Just for latency reasons */
n = iov_iter_zero(chunk, iter);
if (!n && iov_iter_count(iter))
return written ? written : -EFAULT;
written += n;
if (signal_pending(current))
return written ? written : -ERESTARTSYS;
cond_resched();
}
return written;
}
La partie où les zéros sont effectivement envoyés à la zone mémoire du programme qui lit dans /dev/zero est implémentée par la fonction iov_iter_zero, elle même implémentée dans lib/iov_iter.c, et qui va simplement mettre à zéro la zone de mémoire, de la taille d'un chunk, indiquée par le pointeur iter. Le reste est de la barbapapa syntaxique pour gérer les interruptions, et pour calculer la quantité de zéro lue dans le fichier par le programme, stockée dans la variable written.
Un noyau Linux modifié pourrait tout à fait effectuer un contrôle sur l'utilisateur qui demande à lire dans /dev/zero, et au cas où l'identifiant d'utilisateur correspond à celui de Doug McIlroy, alors un 0b00000001 pourrait être renvoyé à la place d'un 0b00000000.
Si Doug McIlroy a modifié le noyau de son système de manière adéquate ; alors cet exploit peut être reproduit dans la vraie vie.
Exploit no1 : Doug McIlroy peut changer les permissions d'un fichier avec un aimant et une épingle.
Traiter cette question requiert de comprendre deux aspects. Que sont les permissions sur un fichier, et qu'est ce qu'un aimant et une épingle peuvent bien avoir à faire dans l'affaire ?
Unix est un système d'exploitation qui se veut multi-utilisateurs. Cela a diverses implications essentielles en terme de sécurité, pour que lesdits utilisateurs d'une même machine ne se marchent pas sur les pieds. L'un des mécanismes mis en place pour éviter les problèmes est l'applications de divers droits aux fichiers présents dans l'ordinateur. À quoi est ce que ça ressemble sur le terrain ? La commande suivant renvoie une liste détaillée des informations relatives au fichier intitulé ls, stocké dans le répertoire bin, lui-même situé à la racine de la partition :
$ ls -l /bin/ls -rwxr-xr-x 1 root root 138856 Aug 29 22:20 /bin/ls
Le premier champs contient le type de fichier, ici - signifiant que ls est un fichier normal, ainsi qu'un descriptif des bits relatifs au droits en accès en lecture (bit r comme Read), écriture (bit w comme Write) et exécution (bit x pour eXecute), pour l'utilisateur auquel appartient le fichier (ici root, avec tous les droits rwx), son groupe (encore root mais cette fois ci en tant que groupe, avec les droits en lecture et exécution r-x, mais pas en écriture), et le reste des utilisateurs de la machine (avec les même droits que pour le groupe). Juste pour décrire les droits en lecture, écriture et exécution de chaque entité, neuf bits doivent être utilisés. Dans le cas présent, ces neuf bits pourraient être stocké dans deux octets comme suit : 0b00000001 et 0b11101101, 1 pour autoriser, et 0 pour interdire, ou pour faire du bourrage pour remplir le premier octet. Voilà qui devrait suffire à se faire une idée de la notion de permissions d'un fichier.
Maintenant attaquons la question des aimants et des épingles. Diverses méthodes permettent physiquement de mémoriser les informations binaires dont se servent les ordinateurs, en général pour stocker les fichiers. Toute une variété de supports a été inventée depuis le début des années 1950, notamment diverses variétés de supports dits magnétiques. Les disques durs modernes sont un exemple encore relativement courant de support magnétique. La planche de XKCD numéro 378 retranscrit cette idée quelque peu absurde de changer les bits un à un manuellement à merveille. Toutefois, pour reproduire cet exploit avec un disque classique, même avec une très bonne paire de lunettes, bonne chance pour ne serais-ce que distinguer un bit de son voisin, notamment sur les disques à recouvrement, de plus de dix téraoctets binaires de mémoire. Cependant, ces densités de données n'ont pas été toujours existantes, mais graduellement atteintes au fil du temps, par itérations successives de technologies toujours plus performantes.
Remontons dans le temps pour se placer à l'époque des états de services Doug McIlroy, notamment en tant qu'employé d'AT&T Bell Labs, et chef de deux joyeux lurons à qui sont dûs le langage C et Unix, disons à la toute fin des années 1960. À cette époque, les quelques disques durs existant dans le monde étaient des monstres coûtant quelques millions de dollars à eux seuls, pour stocker une poignée de mégaoctets binaires. Selon toutes vraisemblance, McIlroy aurait pu être confronté au stockage de données sur bandes magnétiques, et plus précisément sur bandes DECtape. D'après la documentation technique des DECtape 55, la bande magnétique était d'une largeur de trois quart de pouce, soit presque deux centimètres, et comprenait un total de dix pistes, servant à stocker cinq canaux redondés. Trois canaux servaient au stockage de donnée, les fameux data1, 2 et 3, un canal servait au recalage, le fameux timing et le dernier servait à calibrer le lecteur, c'était le fameux mark. Sur la bande, l'écart entre deux pistes consécutive ne représentait pas plus de deux millimètres. Physiquement, les têtes de lecture et écriture étaient des anneaux scindés comportant des spires reliées électriquement aux circuits logiques du lecteur de bandes. À la lecture, le changement de polarité des pistes était transmis magnétiquement aux anneaux brisés, et induisait un courant dans les spires, permettant de déterminer le bit stocké, 0 ou 1 dépendant du sens dans lequel est allé le courant. À l'écriture, un courant électrique passait dans les spires, qui se traduisait en champ magnétique fort entre les pôles nord et sud de l'anneau, notamment entre les deux extrémités du bris.
L'idée derrière l'aimant et l'épingle est donc d'assembler un aimant en fer à cheval, afin de provoquer une saturation magnétique de la bande, comme dans le cas de l'écriture avec les anneaux brisés, et ce notamment à l'emplacement des bits de permission sur le fichier. La largeur entre les pistes, 2 mm, est toute juste pour effectuer ces manipulations à la main. Mais quid de la longueur d'un bit ? La documentation annonce une densité d'environs 350 bits par pouce, qui donne au mieux, en comptant chacune des dix pistes comme participant indépendamment au stockage, ce qui est loint d'être vrai, environ 0.7 mm de longueur pour un bit de données sur la bande.
Si ces conditions géométriques étaient remplies, et que Doug McIlroy disposait d'une solide épingle de haute précision, capable de supporter le champ magnétique de saturation sans se tordre, alors peut-être que le changement de bits de permission a pu se faire avec cet outillage rudimentaire.
Doug McIlroy can get a 1 out of /dev/zero. Doug McIlroy can change file permissions using a magnet and a pin. Doug McIlroy can read data from /dev/null. Doug McIlroy can address 8 terabytes of RAM with only 32 bits. Doug McIlroy can handle SIGKILL. Doug McIlroy spawns Init. Doug McIlroy can hard-link across devices. Doug McIlroy can create 3-ended pipes. Doug McIlroy dreams in binary. Doug McIlroy eats serial ports for breakfast. Doug McIlroy doesn't have an Erdos number; Erdos has a McIlroy number. Doug McIlroy prototyped /dev/random with a toothpick and 4 cans of baked beans. Doug McIlroy invented pipes. Doug McIlroy thinks asm is for sissies. Doug McIlroy invented diff to win a bet. Doug McIlroy can read unbound variables. Doug McIlroy can disprove tautologies. Doug McIlroy's programs always terminate -- sometimes each other. Doug McIlroy's programs don't need a garbage collector; they pick up their OWN garbage. Doug McIlroy doesn't make system calls. System calls call Doug McIlroy. Doug McIlroy doesn't use malloc to allocate memory. He uses his bare hands. Doug McIlroy doesn't debug. He stares at tty0 until it fixes the problem. Once, Doug McIlroy got mad at his terminal and smacked the keyboard. The result is called "Unix." Alan Turing always wanted to win a McIlroy Award, but didn't qualify. No one has. In 1984, the Department of Justice broke up AT&lT because they had a monopoly. On Doug McIlroy. Doug McIlroy supervises the hypervisor. Doug McIlroy understands the internals of a hidden Markov model. Doug McIlroy patented macros. At Bell Labs, computers regularly crashed in fear when Doug McIlroy entered the room.
Ses exploits, les vrais !
Le texte suivant est un compte rendu un peu moins biaisé des facts associés à cette personne. Comme la liste des exploits, ce document est originaire du site web du Dartmouth College qui a été fermé :
M. Douglas McIlroy doug@cs.dartmouth.edu An Adjunct Professor of Computer Science at Dartmouth, M. Douglas McIlroy retired in 1997 from the Computing Sciences Research Center at Bell Laboratories (formerly a part of AT&T, now Alcatel-Lucent). At Bell Labs he headed the Computing Techniques Research Department from 1965 to 1986, and thereafter served as Distinguished Member of Technical Staff. Best known as the birthplace of the Unix operating system, the Computing Techniques Research Department did wide-ranging theoretical and applied research in programming languages, compilers, operating systems, design verification, algorithms, computational complexity, text processing, graphics, image processing, and computer security. In the area of computer languages, McIlroy participated in the design of PL/I (a general-purpose language of the 1960's), contributed to C++, and wrote unusual compilers for PL/I, Lisp, Altran (an algebraic manipulation system), and TMG (a compiler-writing tool). Long interested in data-stream processing, he conceived "pipes" for combining Unix programs, invented the classic coroutine prime-number sieve, and developed algorithms for processing power series. Other research topics include text and string processing, computer cartography, theorem proving, and dynamic storage allocation. The notion of "language extension" arose from his early work in macroprocessors, and "software components" from a 1968 NATO paper. In a lighter vein, he coauthored Darwin, the first game of survival among self-reproducing programs, and used the computer for word games. His more recent research addressed multilevel security for Unix, ultimately accurate bitmap graphics, and full-text indexing. He contributed to the design and construction of the Multics operating system. To Unix he contributed many utilities and subroutines, ranging from the lowly "echo", through "diff" for file comparison, "spell" for checking spelling, and "join" for database manipulation, to "speak", the first real-time text-to-speech program. McIlroy joined Bell Laboratories in 1958 after earning a bachelor's degree in engineering physics from Cornell University and a PhD in applied mathematics from the Massachusetts Institute of Technology. He taught while at MIT, and was a visiting lecturer at Oxford University from 1967 to 1968. He served the Association for Computing Machinery as national lecturer, Turing award chairman, member of the publications planning committee, and associate editor for the Communications of the ACM, the Journal of the ACM, and ACM Transactions on Programming Languages and Systems. He also served on the executive committee of CSNET (an evolutionary stage between the exclusive ARPANET and the public Internet), on various advisory panels to the Department Defense, the New Jersey Board of Higher Education, and the National Science Foundation, and on visiting committees at Argonne National Laboratories, Syracuse University, and the University of Texas at Austin. He coauthored several National Research Council reports, including "Computers at Risk" (computer security, 1990) and "Computing the Future" (directions for academic computer science, 1992). He is a past officer of the New York Map Society, a founding member of the International Federation of Information Processing Societies working group on programming methodology (WG2.3), and a fellow of the American Association for the Advancement of Science. In 2004 the Usenix Association presented McIlroy its lifetime achievement award "for over fifty years of elegant contributions to Unix and programming", and also its Software Tools User Group award. In 2006 he was elected to the National Academy of Engineering. In his previous home town of Bernardsville, New Jersey, McIlroy served as chairman of the shade tree commission, chairman of the environmental commission, alternate member of the planning board, and trustee of the public library. He now lives in Hanover, New Hampshire, where he serves on the conservation commission, chairs the town trails committee, and is the oldest active participant in the Skating Club at Dartmouth. updated 03/14/07
Ce texte traduit en Français donnerait à peu près cela :
M. Douglas McIlroy doug@cs.dartmouth.edu Professeur Adjoint de Sciences Numériques à Dartmouth, M. Douglas McIlroy s'est retiré en 1997 du Centre de Recherches en Sciences Numériques des Laboratoires Bell (appartenant anciennement à AT&T, aujourd'hui Alcatel-Lucent). Aux Bell Labs, il était à la tête du Département de Recherche en Techniques de Calcul de 1965 à 1986, après quoi il servit en tant que Membre Distingué des Équipes Techniques.
(C'est moi ou la traduction de ce titre est rend ridiculement mal ?)
Bien connu pour être à l'origine du système d'exploitation Unix, le Département de Recherches en Techniques de Calcul a couvert un large spectre de recherches théoriques et appliquées dans le domaine des langages de programmation, des compilateurs, des systèmes d'exploitation, de la vérification des concepts, de l'algorithmie, de la complexité calculatoire, du traitement de texte, des graphiques, du traitement d'images et de sécurité informatique. Dans le domaine des langages informatiques, McIlroy a participé à la conception du PL/1 (un langage généraliste datant de 1960), a contribué au C++, et a écrit des compilateurs hors du commun pour le PL/1, Lisp, Altran (un système de manipulations algèbrique), et TMG (un outil de construction de compilateurs). Intéressé pendant longtemps par le traitement de données en flux, il conçut les "tubes" pour combiner les programmes Unix, a inventé la coroutine classique de nombre premiers sieve, et développé des algorithmes de traitement de suites quadratiques.
(Ça vaudrait le coup de vérifier que ces power-series sont bien des suites quadratiques ; pôlynomes sonne pas trop mal non plus)
D'autre sujets de recherche comprennent le traitement de texte et de chaînes de caractères, la cartographie, la démonstration de théorème, et l'allocation dynamique de stockage. La notion d'"extension de langage" provient de ses travaux précoces sur les processeurs de macros, et "composants de logiciels" d'une publication pour l'OTAN de 1968. Sur un sujet plus léger, il est co-auteur de Darwin, le premier jeu de survie parmis des programmes auto-réplicants, et a utilisé l'ordinateur pour construire des jeux basés sur les mots. Ses recherches récentes on couvert la sécurité d'Unix à plusieurs niveaux, la précision ultime des images matricielles, et l'indexation au format texte. Il a contribué à la conception et la construction du système d'exploitation Multics. Sur Unix, il contribua à de nombreux utilitaires et sous-programmes, allant du simple "echo" à "speak", le premier synthétiseur vocal temps réel, en passant par "diff" pour comparer les fichiers, "spell" pour vérifier l'orthographe, et "join" pour effectuer des jointures de tables, à la façon des bases de données. McIlroy a rejoint les Laboratoires Bell en 1958 après avoir obtenu un grade de bachelor en physique pour l'ingénierie à l'Université de Cornell, et un doctorat de mathématiques appliquées à l'Institut de Technologie du Massachussett. Il a enseigné au MIT, et était un conférencier à l'Université d'Oxford de 1967 à 1968.
(La traduction peut être parfois un peu floue, mais cette fois ça va friser l'incompréhensible)
| Name | Last modified | Size |
|---|---|---|---|
| Parent Directory | - |
Cet article, n'est pas vraiment un article, mais plutôt un bête copier/coller qui mériterait franchement développement. Sa rédaction a démarré le 11 février 2019, en particulier suite à la découverte de l'histoire de la rédaction des premières pages de manuel Unix, en 1971.
Un peu de travail de traduction de la vraie biographie a été effectué dans la nuit du 6 au 7 juin 2019. Même si, soyons honnête, ce n'est pas la partie la plus intéressante de la page.