Tavis Ormandy, du Project Zero chez Google, a publié récemment les détails d'une faille dans Transmission permettant à un utilisateur distant de prendre le contrôle du client BitTorrent.
En dépit de la politique habituelle des 90 jours, le chercheur n'a attendu que 40 jours pour révéler les détails de la brèche Pourquoi ? Parce qu'il fournissait cette fois la solution complète, avec le patch à appliquer au code. Plusieurs semaines après son envoi à l'équipe de Transmission, il n'avait aucune réponse, regrettant le manque de réaction.
La publication des détails permet au patch associé d'être récupéré notamment par toutes les distributions GNU/Linux, Transmission étant très utilisé sur ces dernières (et sous macOS). Chez Ars Technica, l'équipe de Transmission répond cependant qu'une mise à jour sera publiée aussi rapidement que possible, mais que la faille nécessite que l'accès distant ait été activé (inactif par défaut) et qu'aucun mot de passe n'ait été défini.
Dans un tweet, Ormandy ajoute qu'il ne s'agit que de la première d'un lot de failles de type DNS rebinding, exploitables dans plusieurs clients BitTorrent, car l'exploitation dans Transmission peut être reproduite ailleurs. Les noms des autres programmes n'ont toutefois pas été dévoilés, les 90 jours n'étant cette fois pas écoulés.
Commentaires (15)
#1
Voilà pourquoi je préfère mettre ce genre de logiciel derrière un nginx avec filtre/authentification…
#2
C’est de bonne guerre, les mises à jour de transmission sont quasiment inexistantes…
#3
une faille qui permet donc de prendre le contrôle sur une interface web accessible sans mot de passe ?
" />
#4
#5
#6
sauf que ce genre de soft télécharge et envoie des données sur internet donc n’est pas complétement isolé !
j’ai pas de mot de passe sur mes app qui sont en interne pure par contre dès que ça cause avec l’autre côté de l’UTM ça passe par ssl+mdp à minima
#7
Ce n’est pas une faille : on partage le contrôle du logiciel, c’est du peer-to-peer !
#8
Est-ce que KTorrent est touché ?
" />
“qu’aucun mot de passe n’ait été défini”
Où est l’option permettant de définir ce mot de passe ?
#9
Je ne suis pas sûr de bien comprendre l’étendue de la faille.
Il faut qu’un user connecté à une machine ayant accès au 9091/TCP du serveur transmission (donc localhost évidemment, mais valable aussi pour un NAS sur le LAN non, même si l’adresse est moins évidente à trouver ?) aille avec son navigateur sur un site malveillant ?
#10
Je sens qu’il va falloir mettre les navigateurs dans un container et derrière un pare-feu pour éviter ce genre de conneries ….
#11
Morale de l’histoire: utilisez un résolveur DNS configuré pour bloquer le DNS rebinding. Perso j’utilise Unbound.
#12
J’vois pas trop en quoi c’est la faute a transmission, si ca vient d’une faille dans un browser. Ou alors j’ai raté un truc.