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: https://sebsauvage.net/wiki/doku.php?id=securite
Follow
@sebsauvage @lanodan j'étais déjà très humble, mais ca fait carrément peur, ton anecdote.
@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.
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.
@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 !