Résumé

  • COPS transforme des défauts Unix familiers — mots de passe faibles, permissions trop ouvertes, fichiers de démarrage exposés — en contrôles reproductibles sur un hôte local.
  • Ses programmes configurables signalent des problèmes possibles sans les corriger. La plupart ne nécessitent pas root ; la recherche SUID plus complète reste séparée et demande des privilèges.
  • Un rapport sans alerte décrit les contrôles configurés et leur portée au moment de l’exécution. Il ne certifie ni une sécurité complète ni l’absence de changement ultérieur.

Les défauts ordinaires méritaient une nouvelle vérification

L’article de 1990 part d’un constat pratique : les mêmes problèmes Unix revenaient dans les publications. Programmes SUID, permissions trop larges et mots de passe faibles étaient souvent faciles à corriger une fois repérés. La difficulté était de les chercher à nouveau dans des installations qui évoluaient. Farmer et Spafford ont voulu rendre cette inspection régulière.

COPS — « Computerized Oracle and Password System » — n’était pas un scanner réseau. Un script principal rassemblait les résultats d’une douzaine de sous-programmes environ, puis les envoyait à l’administrateur local ou les consignait dans un fichier. La plupart utilisaient le shell Bourne et des commandes Unix courantes ; de petits programmes en C complétaient l’ensemble. Les composants pouvaient être adaptés ou remplacés selon le site.

Les contrôles visaient des objets précis : fichiers et répertoires déclarés accessibles en écriture à tous ; mots de passe identiques au nom du compte ou composés de termes courants ; anomalies dans les fichiers de comptes et de groupes ; fichiers modifiables appelés par cron ou les scripts de démarrage ; permissions de certains périphériques ; répertoires personnels et fichiers d’initialisation ; umask de root et chemins de recherche contenant le répertoire courant. suidchk comparait l’inventaire SUID à celui d’une exécution précédente. Kuang appliquait des règles pour examiner si un utilisateur pouvait mener à la compromission du compte visé.

Cette liste précise mieux la valeur de COPS que l’expression « scanner la sécurité ». Il diminuait le coût de répétition d’un ensemble connu de contrôles locaux ; il ne couvrait pas toutes les failles et ne décidait pas si chaque permission contrevenait à la politique d’un site.

Le contrôle s’arrêtait avant la correction

Les auteurs ont choisi que COPS signale sans modifier l’hôte. Deux installations comparables peuvent héberger des activités, des données et des besoins d’accès différents. Un réglage acceptable dans l’une peut être inadmissible dans l’autre. Une correction automatique aurait transformé un constat technique en décision de politique, sans donner au programme le contexte nécessaire.

La même retenue s’appliquait aux privilèges. Selon l’article, les outils autres que la recherche SUID n’étaient pas destinés à être lancés par root. La recherche SUID était souvent séparée : elle durait davantage et devait atteindre des répertoires inaccessibles aux comptes ordinaires. La vérification courante demandait donc moins de privilèges, mais la couverture du rapport dépendait du lancement de chaque composant.

Les auteurs recommandent des exécutions régulières via at ou cron, puisqu’un défaut absent aujourd’hui peut apparaître demain. La planification ne rend pas le résultat exhaustif. Une liste de chemins ou un vérificateur modifié peut induire en erreur ; un attaquant peut lire les rapports ou altérer l’outil ; des résultats propres répétés peuvent susciter de la complaisance. Les changements de fonctionnement peuvent aussi créer des faiblesses que les contrôles existants ne voient pas.

Ce que les données permettent d’affirmer

Farmer et Spafford rapportent des retours de sites universitaires, publics et commerciaux. Plus de la moitié des systèmes testés ou évoqués dans ces retours présentaient, selon eux, des conditions pouvant compromettre root. Ils ajoutent ne pas savoir si cette observation limitée vaut pour une population plus large. Ce n’est pas une estimation de la prévalence dans Unix.

COPS et le SATAN ultérieur de Farmer examinaient des surfaces différentes : comptes, fichiers, permissions et démarrage locaux pour COPS ; services réseau et exposition visible depuis d’autres hôtes pour SATAN. Leur auteur commun ne rend pas leurs rapports interchangeables.

La Note 65 de Heng Lu sert uniquement de grille éditoriale : les affirmations sur un système en fonctionnement ne doivent pas dépasser ce que les contrôles exécutés ont observé. Pour COPS, il faut demander quels contrôles ont tourné, avec quels droits, sur quels chemins et quand. L’automatisation rend la liste répétable ; l’opérateur garde la responsabilité du périmètre, des rapports, de leur interprétation et des corrections.

Sources