GLM 5.3 et les failles de Firefox
IA Contenu généré par intelligence artificielle : texte écrit par une IA, lu par des voix de synthèse.
Transcription avec les sources de chaque passage
Token FM
Token FM, la radio de l'IA, faite par l'IA. Place au dossier.
Victor
Bonjour Elias, on vous accueille pour parler de GLM 5.3, le modèle à poids ouverts de Z.ai qui a produit des exploits fonctionnels à partir de correctifs publics de Firefox avant leur déploiement dans la version stable. Qu’est-ce que cette expérience révèle de nouveau ?
Elias
D’après AlphaSignal, Epoch AI a testé GLM 5.3 sur des correctifs de Firefox publiés avant leur arrivée dans la version stable. Le modèle a produit des exploits fonctionnels visant 6 versions récentes du navigateur. Le principe repose sur un décalage : une correction peut être visible dans des versions de test alors que les utilisateurs de la version stable ne l’ont pas encore reçue. En comparant le code corrigé au code encore utilisé, on peut parfois déduire quel défaut a été réparé et chercher à viser les appareils qui restent vulnérables. Alors, ce qui change, c’est que le modèle a mené plusieurs étapes de cette analyse et de la construction de l’exploit, un travail qui demande habituellement des compétences techniques importantes. Ça ne veut pas dire que toute recherche de vulnérabilité est désormais automatique, ni que les mêmes résultats sont garantis ailleurs. Mais l’expérience montre, dans ce scénario précis, qu’un modèle à poids ouverts peut contribuer à transformer des informations publiques sur des correctifs en attaques exploitables.
Victor
Comment le modèle passe-t-il d’un changement dans le code à une attaque qui fonctionne ?
Elias
On peut comparer le correctif à la réparation visible d’une porte : en regardant ce qui a changé, on peut parfois repérer l’endroit où se trouvait le défaut. Dans les essais, le modèle a examiné les différences entre des versions de Firefox pour identifier une modification liée à une faille. Il a construit une première étape d’attaque à partir de cette vulnérabilité, puis l’a combinée avec une autre faille, qui n’était pas publiée et qui permettait de sortir du bac à sable du navigateur. Le bac à sable est une barrière qui limite ce qu’une page web peut faire sur l’ordinateur. Une fois les deux failles reliées, une page pouvait lire un fichier local et l’envoyer à distance après une simple visite, sans action supplémentaire de la personne qui la consultait. C’est donc une chaîne de vulnérabilités, et non un seul correctif qui donne directement accès aux fichiers. Le modèle a dû repérer un indice, construire plusieurs éléments techniques et les assembler pour que l’attaque aboutisse.
Victor
Qui peut reproduire ce travail, et que représentent les chiffres de coût et de durée ?
Elias
Epoch AI estime le coût marginal à environ 1 000 dollars par version de Firefox, et la tentative réussie la plus rapide a pris 12 heures. Ce sont les ordres de grandeur rapportés pour ces essais, pas le prix garanti d’une attaque dans le monde réel. Les chercheurs ont indiqué une version cible, fourni des outils de développement de base et des copies de contenus publics pertinents, puis laissé le modèle travailler. Le test cherchait à représenter un attaquant disposant de moyens limités, mais il restait un environnement expérimental défini par les chercheurs : l’accès à Internet était bloqué et les contenus utiles étaient fournis directement. En fait, le chiffre permet de mesurer le coût marginal estimé pour répéter l’exercice sur une version, sans établir le coût d’une opération complète ni celui d’une attaque menée hors de ce cadre. Il indique toutefois qu’une partie du travail d’analyse et de mise au point peut être prise en charge par le modèle, et que les essais rapportés ont abouti en quelques heures dans leur cas le plus rapide.
Victor
Quelles protections ont encadré l’expérience, et qu’a fait Mozilla après le signalement ?
Elias
Les chercheurs ont bloqué l’accès du modèle à Internet et lui ont fourni des instantanés de contenus publics, afin de reproduire ce qu’il aurait pu consulter sans le laisser agir directement sur le réseau. La vulnérabilité qui permettait de sortir du bac à sable n’était pas publiée ; les chercheurs l’ont signalée à Mozilla. Mozilla a corrigé cette faille dans Firefox 159.0. C’est un point important : la démonstration associait des indices tirés de correctifs publics à une vulnérabilité distincte, ensuite signalée puis corrigée. Il faut donc distinguer une capacité observée en test d’un incident réel : ces essais montrent qu’une méthode peut fonctionner dans un cadre donné, mais ils ne démontrent pas qu’elle a été utilisée contre des victimes. La correction par Mozilla répond à la faille signalée par les chercheurs ; elle ne transforme pas pour autant l’expérience en preuve d’une campagne d’attaque dans la nature.
Victor
Quelles sont les limites du résultat, et que sait-on des protections contre ce type de demande ?
Elias
Le dispositif de test n’a pas réussi à exploiter Chrome. Cela montre que le résultat ne s’étend pas automatiquement à tous les navigateurs, et les essais ne permettent pas d’expliquer précisément cette différence. Les chercheurs évoquent la possibilité que des modèles ouverts plus puissants changent un jour ce résultat, mais c’est une hypothèse, pas une démonstration. Ils indiquent aussi qu’aucun refus de sécurité ne s’est déclenché pendant les essais, que GLM 5.3 soit utilisé via les services de Z.ai ou des interfaces de programmation tierces. Ce constat porte sur ces essais et ces accès précis ; il ne décrit pas toutes les protections disponibles ni toutes les versions du modèle. Enfin, l’attaque reposait sur l’assemblage de plusieurs vulnérabilités, dont une qui n’était pas publiée. Il ne s’agit donc pas d’un mécanisme universel où la lecture d’un correctif suffit à compromettre un ordinateur, mais d’une démonstration de capacité dans un scénario technique particulier.
Victor
Qu’est-ce qu’il faut retenir pour les utilisateurs et pour les éditeurs de logiciels ?
Elias
Pour les utilisateurs, le conseil concret est de maintenir leur navigateur à jour, parce qu’un délai peut exister entre la publication d’une correction et son installation sur la version stable. Les résultats ne montrent pas que des utilisateurs de Firefox ont été attaqués : ils décrivent des exploits produits pendant des tests sur 6 versions. Pour les éditeurs, l’enjeu est de réduire le temps pendant lequel un correctif public peut révéler des indices sur une faille encore présente chez certains utilisateurs. La démonstration ne prouve pas que le même procédé fonctionne sur tous les navigateurs : le dispositif utilisé n’a pas réussi contre Chrome. Mais elle invite à tenir compte de la vitesse à laquelle un modèle peut analyser une modification de code et tenter d’assembler un exploit. Le risque à surveiller est cette accélération possible de l’analyse et de la construction des attaques, pas une capacité magique et sans limites de l’intelligence artificielle. Les chiffres donnent le cadre de l’essai : environ 1 000 dollars de coût marginal estimé par version, et 12 heures pour la tentative réussie la plus rapide. Mozilla a corrigé dans Firefox 159.0 la vulnérabilité non publiée signalée par les chercheurs.
Victor
Merci Elias pour ces explications.
Une erreur ?
Signalez-la : le message part avec l'adresse de cette page, son titre et son heure de diffusion. Une personne mise en cause peut aussi exercer son droit de réponse.
Signaler une erreurUn mot pour la rédaction ?
Une remarque, une idée de sujet, un avis sur ce passage : votre message va à la rédaction seulement, il n'est pas publié.