Auteur Sujet: Faille RTCPeerConnection  (Lu 12101 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Explication de texte
« Réponse #36 le: 04 février 2015 à 21:57:43 »
Tu enchaîne les posts pour accentuer le bruit que tu veux faire ou pas ?
Pour les mal-comprenants :

Ces messages correspondent à des sujets différents.

Le topic commence par deux sujets différents, j'en rajoute un troisième sujet principal, et ensuite de nombreux autres sujets liés sont discutés (dont l'intérêt du NAT, dont le traçage des utilisateurs).

corrector

  • Invité
Faille ou pas?
« Réponse #37 le: 04 février 2015 à 22:07:21 »
Le débat si c'est une faille de sécurité ou juste un probleme de privacy/entreprise n'est bien sur pas tranché et ne le sera peut-être jamais
Tu peux me dire ce qui te permet de discerner une faille de sécu d'un "problème de privacy"?

Au fait, c'est quoi un "problème de privacy"?

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 349
  • Malissard (26)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #38 le: 04 février 2015 à 22:17:37 »
En tout cas, l'utilisation (contournement ?) du NAT est décrit dans plusieurs RFC :
[RFC4787]  Audet, F., Ed., and C. Jennings, "Network Address
              Translation (NAT) Behavioral Requirements for Unicast
              UDP", BCP 127, RFC 4787, January 2007.

[RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

[RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

[RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

[RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.


BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 349
  • Malissard (26)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #39 le: 04 février 2015 à 22:21:52 »
Ah pardon, j'avais oublié celle-là : https://tools.ietf.org/html/rfc2663

RFC2663: IP Network Address Translator (NAT) Terminology and Considerations

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #40 le: 04 février 2015 à 22:33:16 »
() Firefox respectent les specs de la norme WebRTC et se doivent donc de fonctionner comme cela. Ils ont donc décider , par défaut, d'autoriser ce comportement plutôt que de le bloquer (opt-in par défaut).
Non, au contraire, Firefox n'a pas "décidé" ça.

Les dév Firefox ont décidé que les fonctionnalités de communication A/V exigent une confirmation et que donc l'accès à l'API WebRTC et au protocole STUN était contrôlée ainsi.

Ils se sont plantés.

Pas de chance, hein...

Citation :

Firefox attempts to prevent internal IP address leakage via the SDP offer description by requiring streams to be added to a RTC peer connection before createOffer() can be called. This is usually done through calling getUserMedia(), which requires user authorisation. Firefox also prevents MediaStream constructors from being called directly. However, a RTC data channel bypasses this requirement by creating a stream without any user prompts, as no access to camera or microphone is requested.

Please see the attached fftest.html file for an example. It will write out the SDP description into the page, which contains all identified IP addresses for the endpoint so that a P2P connection can be established. The peer.localDescription object can also be inspected in the console.


Actual results:

Internal IP addresses can be leaked to the web page without any user notification.


Expected results:

The root question here is whether the browser should be able to initiate and establish P2P connections without notifying the user. Based on other WebRTC behaviour implemented in Firefox, it appears that this was to be prevented so that internal IP addresses cannot be leaked to a web page without calling getUserMedia() and causing a user prompt. In any case, the WebRTC implementation should be made consistent with whatever is decided.


Source : https://bugzilla.mozilla.org/show_bug.cgi?id=959893
« Modifié: 05 février 2015 à 15:49:58 par corrector »

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #41 le: 04 février 2015 à 22:45:54 »
Franchement, je ne sais pas ce qu'est une "rustine" : si tu penses pouvoir me faire gober que tu considères la majorité des utilisations du NAT comme étant légitime et fait "comme il se doit, pour une bonne raison", tu surestimes tes capacités :)
Nous savons tout les deux que la majorité du NAT est nefaste, et également que le NAT est utile dans certains cas.
Cette faille du navigateur crée justement une utilité pour le NAT : cette "fonctionnalité" expose l'adresse IP telle que vue par le navigateur; il faut donc cacher au navigateur l'adresse IP.

Pour faire cela, le plus simple est de mettre le navigateur sur une machine en IP privée et éventuellement d'utiliser le NAT pour la connectivité.

Les tentatives du navigateur de découvrir l'adresse IP publique via UDP seront aisèment bloquées avec un pare-feu.

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #42 le: 05 février 2015 à 15:28:33 »
Ce qui est drôle, c'est que WebRTC est tellement une usine à gaz, qu'il a fallu attendre plusieurs années après le début du développement et de l'implèmentation de cette technologie dans les principaux navigateurs, pour qu'un journaliste se rende finalement compte d'un de ses aspects de fonctionnement les plus basiques. Pour un développeur qui cherche à jouer ne serait-ce qu'un peu avec cette technologie, il est très difficile de passer à côté du fait que l'adresse IP locale est transmise dans les données SDP, vu que le développeur doit manipuler directement la variable qui contient ces informations pour la faire transiter via son serveur (la signaling channel).
Exact.

XMLHttpRequest,
oui mais uniquement vers la même "origine" (donc pas de CSRF possible).

les WebSockets, voire même les frames et les formulaires HTML basiques,
Oui : formulaire + JS = GET/POST vers n'importe quel domaine et CSRF possible (sauf à utiliser un plugin comme NoScript qui anonymise ("sandbox") certaines requêtes).

il existe déjà dans les faits un bon nombre de manières d'envoyer du trafic vers le réseau local de l'utilisateur, d'en obtenir quelques informations en retour (via la gestion d'erreurs), peut-être même d'identifier l'adresse IP locale de l'utilisateur d'une de ces autres manières,
Oui cette page utilise d'abord WebRTC et ensuite des liens HTTPS pour découvrir les machines locales :

https://dl.dropboxusercontent.com/u/1878671/enumhosts.html

sans pour autant qu'il n'y ait la possibilité d'envoyer des paquets qui soient complètement arbitraires au niveau TCP/UDP.
Oui, le navigateur est potentiellement un véritable espion.

L'exploitation d'une faille CSRF ou XSS vers l'interface administration du routeur de l'utilisateur, via l'adresse locale de celle-ci, depuis une page web totalement quelconque, est quelque chose de déjà fait et déjà vu (je peux dire qu'il y a déjà eu des vulnérabilités connues de ce type pour au moins les box de tous les principaux FAI français).
Sur Freebox pre-ution, il n'y pas d'interface d'admin locale, donc zéro surface d'attaque!

Sur l'interface de gestion en free.fr, l'authentification n'est pas ambiante (la session est dans l'URL) donc aucun CSRF possible.
« Modifié: 05 février 2015 à 16:03:52 par corrector »

kgersen

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 715
  • FTTH 1Gb/s sur Paris (75)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #43 le: 05 février 2015 à 16:08:50 »
Ca n'est pas WebRTC lui-même qui est une usine a gaz mais plutot tout les mécanismes utilisés autour pour le faire fonctionner dans le 'monde réel' ou le NAT est omni-présent.
Une tres bonne intro a ce sujet: http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/

On pense tous que le protocole IP est la base d'Internet mais on oublie qu'en l'état actuel, des qu'on sort du LAN on n'a plus vraiment de lien 100% IP entre 2 machines. On se retrouve avec un 'truc tordu' qui ne laisse passer que UDP et TCP et avec des restrictions assez fortes (port ouvert, adresse partagée, etc). On est tellement confronter a cela que pour beaucoup de gens ca devient la 'norme' et l'IP 'normale' du début d'Internet devient l'exception...un comble !

Franchement et je rejoint le dev de Chrome qui parlais de ca: vivement qu'IPv6 prenne la relève qu'on se débarrasse de cet ersatz d'IP actuel qui complique toute innovation, promeut un modèle centralisé et donne un faux sentiment de sécurité (au point que des gens s'affolent qu'on communique leur IP locale sans leur dire).

Si ce 'bug/faille/whatever' de WebRTC peut être une pierre de plus pour promouvoir IPv6, j’espère qu'ils ne le corrigeront jamais ;D

Le 2eme comble dans cette histoire est que WebRTC permet un fonctionnement non centralisé des navigateurs: un lien peer to peer directe entre eux. Un truc qui devrait combler les paranos et les anti-NSA/Google/QueSaisJeEncore mais c'est pourtant eux qui se plaignent le plus de ce 'bug/faille/whatever' .... :P

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #44 le: 05 février 2015 à 17:39:36 »
N'importe quoi, encore.

Snickerss

  • Expert Free + Client Bbox fibre FTTH
  • Modérateur
  • *
  • Messages: 4 012
  • Mes paroles n'engagent que moi :)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #45 le: 05 février 2015 à 18:41:04 »
Corrector me fatigue mais je reconnais qu'il arrive à provoquer des réponses intéressantes donc merci quand même au final ;)

corrector

  • Invité
Client léger vs. client lourd
« Réponse #46 le: 05 février 2015 à 19:56:20 »
Le 2eme comble dans cette histoire est que WebRTC permet un fonctionnement non centralisé des navigateurs: un lien peer to peer directe entre eux. Un truc qui devrait combler les paranos et les anti-NSA/Google/QueSaisJeEncore mais c'est pourtant eux qui se plaignent le plus de ce 'bug/faille/whatever' .... :P
N'importe quoi, une fois de plus.

On ne se protège pas de la NSA avec des sites en WebRTC, il faut un client lourd - qui peut être du JS exécuté dans un navigateur avec l'API WebRTC, évidemment.

kgersen

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 715
  • FTTH 1Gb/s sur Paris (75)
Client léger vs. client lourd
« Réponse #47 le: 05 février 2015 à 20:49:28 »
Au bout d'un moment c'est lassant cette lourdeur. Je remet mon filtre.

 

Mobile View