Suivre

Détecter des failles de sécurité introduites dans un code, c'est possible (par exemple un "==" (comparaison) remplacé par "=" (assignation)).

Mais qu'est-ce qui se passe si même avec le code sous les yeux vous ne voyez plus la faille ?

👋 coucou Unicode !
Voici donc une nouvelle attaque assez effrayante.

sebsauvage.net/links/?QRVnDw

@sebsauvage@framapiaf.org Intéressant, mais déjà la coloration syntaxique (au moins pour Python, j'ai pas regardé les autres) permet d'attirer l'œil sur les trucs chelous

@sebsauvage
Unicode est aussi parasite en utilisant BÉPO dans des vieux trucs comme bash qui ne tolère pas les espaces insécables, sans pour autant les afficher… ce serait effectivement pas mal d'avoir l'option de mettre en surbrillance les caractères potentiellement problématiques, pas que dans les éditeurs de texte.

@sebsauvage Intéressant tout ça !

Au moins, Github affiche un message d'avertissement pour certains cas :)

@FLOZz @sebsauvage ça c'est sympa comme avertissement. ça devrait arriver sur tous les bons IDE

@sebsauvage Effrayante mais au final la plupart des éditeurs de code (en tout cas traditionnels) ne sont pas touché, pareil pour les terminaux.

@sebsauvage
Copier/Coller vers un éditeur de texte basique => l'inversion apparaît.

@sebsauvage
J'ai déjà entendu parler de ce type d'attaque il y a environ 10 ans. Et j'ai aussi déjà entendu parler d'attaques de ce genre dans les fichiers de logs! Je n'ai plus l'idée exacte en tête, mais il me semble qu'il s'agissait de pousser les admins voyant des logs étranges à les copier quelquepart, et injecter du code malveillant masqué par ce type de technique. Par ex: un admin veut faire un whois sur une ip, il copie en fait «92.100.20.22; commande_malveillante;» sans le savoir.

@sebsauvage On pourrait introduire des vérifications à la compilation. Bientôt `-Wunicode-problematic` (activé par `-Wextra`) et `Wunicode-all` dans GCC et Clang ? En attendant, on peut faire un script récursif qui utilise `file --brief --mime-encoding`. Bref, c'est loin d'être insurmontable.

@sebsauvage

Assez d'accord avec ta proposition, c'est effrayant les possibilités qu'ouvrent ces attaques si l'IDE accepte le non-ASCII sans prévenir...

@sebsauvage Ce n'est pas une nouvelle attaque, ce type d'attaque existe depuis la naissance de l'unicode (20 ans...), et les caractères invisibles et homographes (ex: AАΑᎪ), il y en a à la pelle.

Le problème est dans les outils de développement trop anglo-centrés pour se rendre compte que traiter et afficher du texte n'est pas une chose simple (si unicode a pondu beaucoup de specs à ce sujet, ce n'est pas pour rien non plus). Le problème n'est pas dans unicode, mais dans l'éditeur de code, l'outil de diff, et l'outil de revue de code qui ne surlignent pas correctement les constructions trompeuses. Et au niveau des langages de programmation, il manque à mon avis des métadonnées permettant d'indiquer des restrictions sur le fichier au niveau des caractères attendus dans les différents contextes (chaines, commentaires, identifiants...).
Inscrivez-vous pour prendre part à la conversation
Framapiaf

Le réseau social de l'avenir : Pas d'annonces, pas de surveillance institutionnelle, conception éthique et décentralisation ! Possédez vos données avec Mastodon !