Suivre

Suite à l'évocation du problème par @lanodan, je me suis rendu compte que je n'avais jamais couché par écrit cette anecdote sur une faille de sécurité de ZeroBin.

Cela me semble suffisamment édifiant pour servir de leçon, et cela ma rendu terriblement humble sur la sécurité.

Autant en faire profiter tout le monde: sebsauvage.net/wiki/doku.php?i

@sebsauvage @lanodan

> Rappelez-moi à combien de librairies fait appel votre logiciel ?

Aucune : on fait appel à des bibliothèques 😝

@sebsauvage @framasky @lanodan c'est pas forcément un anglicisme… si tu as payés pour les fonctions et que tu les rends pas à la fin, c'est une librairie…
@sebsauvage Haha, j'ai vu tout de suite pourquoi avec "on s'arrête de comparer dès qu'on trouve un caractère différent".

Mais du coup ça me fait penser que je crois pas connaitre de trucs style strcmp()/strncmp() qui soient définit comme étant forcément en temps constant.

@lanodan
Bah oui, j'imagine que dans tous les langages les fonctions de comparaison sont "optimisées" (normale: on cherche à minimiser les cycles CPU).

@sebsauvage Ouais enfin c'est bizarre qu'il y en ait pas une variante qui soit faite pour être en temps constant.
Plus un avertissement comme quoi c'est pas forcément en temps constant donc à ne pas utiliser pour quelque chose de critique pour la sécurité.

C'est une fonction qui est relativement simple à implémenter mais y'a toujours le risque de se vautrer ou d'avoir le compilo' qui t'optimise le truc alors qu'il fallait pas.

@lanodan
haha oui je n'y avais pas pensé: Le compilo qui en optimisant introduit une faille de sécurité.

@sebsauvage C’est une des raisons de pourquoi explicit_bzero existe d’ailleurs.

@sebsauvage
> Quelqu'un qui vous dit que son système ne peut pas être piraté ment, soit en connaissance de cause, soit par ignorance, soit par orgueil.

C'est souvent des personnes qui oublient la partie modèle de menace.
Tout système est piratable parceque tu repose sur une tonne de trucs dont tu ne connais pas l'implémentation (coucou les CPUs Intel).

Par contre je pense qu'il est possible de faire une architecture robuste pour que ça soit considéré comme sécurisé ou en tout cas ne présentant pas trop de risques si un problème arrive.
Par example avoir une surface d'attaque qui soit ridiculement petite.

@sebsauvage @lanodan
> Plus vous augmentez les dépendances de votre logiciel, plus vous augmentez les risques de sécurité.

Par contre, tu doit pas gérer la sécurité de tout ton système et l'effort est "factoriser" (chaque projet qui utilise la lib peut potentiellement peut investir temps et/ou argent pour la securiser), non?
Ça me paraît pas simple, il y a aussi un compromis entre popularité donc sûrement beaucoup plus visé par des attaques mais beaucoup plus robuste.

@tradjincal

effectivement, mais c'est là où il faut vraiment balancer:

Plus utilisé = plus examiné/scruté donc moins de failles ?
Plus utilisé = cible plus intéressante ?
Plus utilisé = plus de fonctionnalité (log4j) = syndrome du kitchen sink = failles de sécurité (log4j est censé loguer, pourquoi il a des fonctions pour télécharger+exécuter ?)

Donc le choix est délicat.

@lanodan

@tradjincal @sebsauvage Popularité n'a aucune corrélation avec la robustesse.
Wordpress est un nid à merde en terme de sécu' mais une énorme majorité des sites web l'utilisent.

Et par contre pour le truc des dépendances, malheureusement ça dépend du language et de la culture.
En C, C++, python, … les libs sont souvent considérée comment étant dans le système et tu peux considérer que ta partie c'est juste appeler les bonnes fonctions et faire un minimum de bon choix de libs.
Y'en aurat toujours pour aller faire du vendoring de leur dépendances par contre, notamment avec la culture des monorepo (coucou Google et les trucs proprio).

Par contre en Java, NodeJS, Rust, Go, … c'est au devs de gérer ce merdier (coucou leftpad, coucou log4j) et c'est souvent juste pas géré.
Par example je considère que dependabot est une bombe à retardement.

@sebsauvage On pourrait aussi commencer la comparaison à un endroit aléatoire pour rendre plus difficile l'interprétation du temps d'exécution.
@lanodan

@oranadoz @sebsauvage Ça je pense que c'est une mauvaise idée.

Ta source d'aléatoire peut être mauvaise et ton code sera sans doute beaucoup plus complexe.
Alors que simplement parcourir la chaine de charactère, stocker faux si tu trouve une différence et retourner le résultat à la fin juste fonctionne.

@oranadoz @sebsauvage @lanodan Tu hashes le bousin, comme ça si c’est presque similaire, les hashs ont quand même rien à voir.

@sebsauvage @lanodan encore une fois, merci de partager comme tu le fais et de prendre le temps de le faire. C'est toujours bon à prendre ce genre d'info/astuce.
Les gens (moi y compris), prenez-en de la graine : même si ça vous semble trivial et si vous avez un peu de temps, partagez, partagez, partagez...

@sebsauvage @lanodan la fameuse timing attack. De toute manière, dès que tu dois comparer un secret, il faut que ça se fasse en temps constant.

@Matlink @sebsauvage Ouaip mais oublier de faire en temps constant ou de mal le faire c'est pas mal un classique (y compris sur les trucs où c'est très important style lib de crypto).

Pour ça que c'est pas mal d'avoir une autre personne au moins orienté sécu' pour vérifier le code / comportement de temps à autre.

@sebsauvage @lanodan j'étais déjà très humble, mais ca fait carrément peur, ton anecdote.

@fx @sebsauvage @lanodan
Ce qui est quand même énorme, c’est que l’algo pour la chaîne de caractères, c’est de comparer seulement deux chaînes de 160 caractères, stockées dans une variable au moment de l’appel de fonction, donc a priori pour n’importe quel ordi c’est hyper-rapide.

Et comme l’attaquant est à l’extérieur du réseau, c’est dingue qu’il ait pu repérer la différence de temps alors que la requête HTTP induit une latence potentiellement aléatoire !

@eurobxl @fx @sebsauvage
Le setup à pas été détaillé mais en fouillant un peu j'ai trouvé le commit, qui à l'audit en lien: https://github.com/sebsauvage/ZeroBin/commit/0b4db7ece313dd268e51fc47a0293a649927558a

Ça serait pas déconnant en 2014 et en considérant que tu peut potentiellement prendre une VM ou avoir un shell dans le même DC qu'une instance ZeroBin pour genre quelques centimes le temps de l'attaque.
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 !