Une correspondance qui refuse d’être sûre

Un scanner de bannières lit SSH-2.0-OpenSSH_8.9p1 sur un port et note un produit et une version. Un flux de vulnérabilités dit qu’une plage de versions de ce produit présente un problème connu. Rapprocher les deux tient en une ligne de code et constitue l’un des moyens les plus faciles de bâtir un écran de sécurité auquel personne ne fera plus confiance dans un mois.

La raison est que ces deux phrases ne sont pas la même sorte d’énoncé. L’une est une mesure faite sur un service qui peut vous mentir. L’autre est l’affirmation d’un tiers sur une plage de versions qu’il a peut-être écrite avant que le correctif existe. Un écran qui les affiche comme un seul chiffre a jeté précisément ce qui permettrait à la clientèle de décider quoi faire.

Quatre faits venus de quatre sources

La phrase cette machine a la CVE-1234 contient quatre affirmations distinctes.

• Joignable est mesuré. Une connexion TCP s’est établie à un instant donné.
• La version est déduite. Nous avons découpé un jeton dans une salutation, et le service peut être configuré pour dire n’importe quoi, et une distribution peut avoir rétroporté un correctif sans changer le numéro.
• L’avis appartient à quelqu’un d’autre. NVD dit qu’une plage de versions d’un produit est touchée.
• Activement exploité est encore une troisième partie. CISA dit que cette CVE est utilisée dans la nature.

Cela reste quatre colonnes. Les multiplier pour en tirer une note est exactement le composite dénué de sens que la spécification de cette fonction interdit, et traiter une entrée au catalogue des vulnérabilités exploitées comme une hausse de gravité est la même erreur en petit.

Une entrée KEV ne relève donc jamais une gravité. La gravité vient du score de base CVSS et de rien d’autre, la confiance reste faible parce que la preuve est une bannière, et l’exploitation est une colonne à part avec trois états : oui, non, et sans objet pour les constats qui ne reposent sur aucun avis. Mesuré sur les données de test : un avis Exim à CVSS 9,8 est critique et porte une marque KEV ; un avis OpenSSH à 8,1 est élevé et n’en porte pas. Le 9,8 est critique à cause de son score et non à cause de la marque.

Le catalogue ne peut par ailleurs, par construction, produire une correspondance à lui seul. Il porte un identifiant CVE, un éditeur, un nom de produit et une date, et aucune plage de versions. Confronter Apache HTTP Server à une bannière reviendrait à deviner. Il ne fait jamais que poser une marque sur un avis que NVD a déjà relié à une plage de versions.

Les flux sont des tables de plateforme

Les deux flux vivent dans des tables sans colonne d’organisation. Une CVE n’appartient à personne : ce n’est pas une donnée personnelle, ce ne sont pas les données d’une cliente, et c’est la même ligne pour tous les comptes de la plateforme. Elle ne figure donc pas dans le nettoyage qui tourne à la fermeture d’une organisation, ni dans une extraction de données personnelles. Le lien entre un constat et un avis, lui, appartient bien à la clientèle, et il figure dans les deux.

Le collecteur applique une liste blanche sur l’hôte et non sur l’adresse, et les adresses elles-mêmes sont dans le code. Un ouvrier qui lit une adresse dans l’environnement ou dans la base de données est une primitive de falsification de requêtes entourée d’un ordonnanceur : qui peut fixer cette valeur fait émettre à notre passerelle une requête depuis notre réseau, avec nos adresses sortantes. L’hôte de chaque adresse finale est vérifié lui aussi, de sorte qu’une redirection vers un autre hôte est refusée plutôt que suivie.

La table de vérité

Avec un nom de produit qui correspond et une règle CPE issue de l’avis, il n’y a que trois réponses possibles, et la plupart des lignes intéressantes produisent celle du milieu.

Seules comptent les entrées CPE dont la partie vaut a, pour application. Un o pour système d’exploitation ou un h pour matériel accrocherait Ubuntu 22.04 à une bannière SSH, et c’est exactement le genre de correspondance qui a l’air convaincante et ne veut rien dire : nous avons vu le service et non le système en dessous.

La ligne discutable est borne basse seule. Une règle qui dit tout à partir de 8.0, sans borne haute, englobe des versions parues après l’avis et qui ont déjà réglé le problème. NVD écrit les plages ainsi quand le correctif n’était pas encore publié, et ne les révise pas toujours ensuite. Coller une telle règle sur une machine signalerait un serveur déjà corrigé comme vulnérable, et après deux signalements de ce genre la clientèle apprend à ignorer l’écran entier. Non vérifiée est l’étiquette honnête, et non vérifiée n’est pas une version réduite de confirmée. C’est une autre affirmation.

Quand un avis porte des dizaines de règles CPE, une par version touchée, le résultat le plus fort l’emporte. Si l’une tombe juste, c’est la réponse, même si dix vagues l’accompagnent.

Une réévaluation écrit une nouvelle révision et ne touche aucune preuve

Les flux changent. NVD corrige un score, une plage se resserre, une CVE qui correspondait la semaine dernière ne correspond plus. Le balayage qui réévalue les constats ouverts face aux flux actuels a une règle dure : il n’écrit et ne modifie jamais une occurrence.

Une occurrence est la réponse à était-ce là à 03:14. Une mise à jour de flux n’y change rien. Ce qui change, c’est la conclusion posée par-dessus, et celle-là reçoit une nouvelle ligne dans la table d’évaluations, avec son propre identifiant de révision nommant les deux instantanés de flux. Mesuré : après avoir déplacé un avis de CVSS 9,8 à 7,5, les lignes d’occurrence existantes sont revenues identiques octet pour octet.

Une correspondance disparue clôt le constat en closed_unverified et jamais en resolved_verified. Le second est un énoncé sur une mesure, et il n’y a pas eu de mesure. Ce qui a changé, c’est notre propre déduction. Le nom est toute la raison d’être de ce statut.

Rien n’est écrit non plus si rien n’a changé. L’instantané est d’abord comparé au jugement précédent, car un balayage qui dépose une ligne à chaque passage laisse en un mois cent vingt évaluations identiques sous chaque constat, et la chronologie devient illisible.

Pas de balayage sans un flux réussi

Le dernier verrou a coûté le moins de code et empêche le pire résultat.

Si aucun flux n’a jamais abouti, la révision d’avis courante est vide et le balayage revient aussitôt sans rien examiner. Sans ce contrôle, il tournerait, constaterait que la requête de candidats ne rend rien, et clôturerait tous les constats fondés sur un avis, chez toute la clientèle, comme ne correspondant plus. Une flotte entière passerait au vert sur la foi d’un flux cassé.

Une récupération ratée laisse en outre le cache précédent en place, avec son propre horodatage de réussite, de sorte que les deux questions quand avons-nous essayé pour la dernière fois et quand avons-nous réussi pour la dernière fois sont deux colonnes distinctes et non une seule pleine d’espoir.

Ce que cela coûte, et ce que cela rapporte

Le coût est que l’écran affiche beaucoup de lignes correspondance possible, non vérifiée, et celles-ci sont moins satisfaisantes qu’un chiffre. Il faut en regarder une et décider si la version en service est réellement touchée.

Ce que cela rapporte, c’est que les lignes marquées comme confirmées méritent qu’on agisse, et que chaque ligne peut être décomposée en les quatre faits qui l’ont formée : ce qui a été mesuré, ce qui a été déduit, ce que quelqu’un d’autre a affirmé, et ce qui est simplement inconnu. Un constat incapable d’expliquer d’où vient chacune de ses parties est un constat que quelqu’un finira par apprendre à sauter.

Issu du travail de sécurité de Provibr. Pourquoi un balayage d’exposition qui lit une bannière n’envoie aucune charge utile se trouve dans un scanner qui envoie zéro octet, et pourquoi un incident ne se referme jamais sur le silence se trouve dans un incident qui ne se ferme jamais sur un silence.