Skip to main content

Mise à jour des tests de Snyk Security Labs : l’éditeur de code IA Cursor.com

Écrit par
Headshot of Danny Allan

Danny Allan

feature automation pink

14 janvier 2025

0 minutes de lecture

L’équipe de Snyk Security Labs cherche à détecter et à contribuer à corriger les vulnérabilités des logiciels utilisés par les développeurs du monde entier, avec pour objectif global d’améliorer la sécurité des logiciels. Pour cela, nous ciblons les outils utilisés par les développeurs, notamment les solutions logicielles récentes et populaires. Face à l’essor fulgurant des outils d’IA, et plus particulièrement des environnements de développement assistés par l’IA, nous avons intégré ces logiciels à nos cycles de recherche.

Parmi ces logiciels figure l’éditeur de code IA Cursor, un concurrent de VSCode et d’autres IDE populaires auprès des développeurs. Ce logiciel intègre une assistance au codage par IA à l’expérience de développement. Avec ce type de recherche, nous espérons ne découvrir aucune vulnérabilité. Mais si nous en trouvons, nous avons ainsi l’occasion de la signaler de manière responsable afin de mieux protéger tous les développeurs qui utilisent ce logiciel. Cursor encourage publiquement le signalement des vulnérabilités de sécurité dans son produit et a publié un guide ainsi qu’un canal dédié à ces signalements.

Dans le cadre de ses recherches, l’équipe de recherche de Snyk Security Labs a déterminé que le logiciel intègre plusieurs extensions privées. Les extensions de VSCode, sur lequel repose l’éditeur de code IA Cursor, sont créées comme des dépendances Node.js classiques et décrites dans des fichiers package.json. Nous avons envisagé un vecteur d’attaque potentiel : Cursor pourrait traiter en interne les extensions VSCode comme des packages NPM et les récupérer dans un dépôt interne lors des builds. Si tel avait été le cas (nous savons désormais que ce n’est pas le cas) et que le système de build avait été mal configuré, il aurait pu y avoir un risque d’attaque par confusion de dépendances. Cette configuration nous semblait peu probable, mais elle méritait d’être étudiée : si elle s’était avérée réelle, elle aurait pu avoir des conséquences importantes pour les systèmes de Cursor comme pour ses utilisateurs.

Pour vérifier cette hypothèse, nous avons téléversé dans le dépôt NPM public des packages portant les noms que nous soupçonnions de faire partie du processus de build de l’éditeur de code IA Cursor. Il s’agit d’une technique couramment utilisée pour tester les risques de confusion de dépendances. Il était extrêmement improbable que ces packages soient installés par des développeurs ou des systèmes autres que ceux de Cursor visés par nos tests. En fait, il était peu probable qu’ils soient installés tout court. Nous avons néanmoins indiqué dans leur description qu’il s’agissait de packages de test provenant de l’équipe de Snyk Security Labs, fourni une adresse e-mail directe pour contacter leur auteur et limité leur disponibilité à une courte période (24 heures). Le code source de ces packages était très succinct et ne cherchait aucunement à masquer leur comportement. Les packages envoyaient des requêtes HTTP à nos chercheurs, contenant le nom d’utilisateur, le nom d’hôte, le répertoire courant et, dans les versions ultérieures, les variables d’environnement. Ces communications sortantes étaient nécessaires pour déterminer si l’installation était entièrement « à l’aveugle ». Dans la version ultérieure, les chercheurs de Snyk ont ajouté des champs supplémentaires aux données reçues afin de limiter les faux positifs causés par les scanners automatisés qui téléchargeaient et exécutaient les packages, un cas qui n’entrait pas dans le périmètre de la preuve de concept. Pour envoyer des signalements fiables et exacts à l’équipe de sécurité de Cursor, Snyk devait pouvoir confirmer que les installations avaient été exécutées par Cursor et que le problème de confusion de dépendances que nous avions identifié était bien réel.

Au final, Snyk Security Labs n’a relevé aucun signe indiquant que Cursor était vulnérable à une attaque par confusion de dépendances. De plus, aucune donnée sensible ne nous a été divulguée au cours de nos tests. Ces vecteurs d’attaque, peu complexes et peu probables, mais à fort impact, méritent d’être étudiés : leur faible niveau de difficulté peut les rendre relativement faciles à exploiter par des acteurs malveillants. Snyk Security Labs mène régulièrement des recherches sur les vulnérabilités et s’efforce de respecter les normes de test les plus strictes afin d’améliorer la sécurité des développeurs.

En testant ces vulnérabilités, Snyk Security Labs espère prendre les attaquants de vitesse et veiller à ce que les logiciels et systèmes utilisés chaque jour par les développeurs du monde entier soient sûrs.

Apprécié par les développeurs. Les équipes de sécurité lui font confiance.

Les outils Snyk, conçus pour les développeurs, offrent une sécurité intégrée et automatisée qui répond à vos exigences de gouvernance et de conformité.