Auteur Sujet: Faille RTCPeerConnection (Lu 29840 fois)

corrector · « **le:** 03 février 2015 à 01:30:49 »

Google Chrome WebRTC IP Address Leakage

Vulnerability Details:
Chrome has a vulnerability whereby internal IP addresses of users can be leaked using Javascript alone without notifying the user.

Affected Versions:
Chrome Version: Version 31.0.1650.63 m + Version 32.0.1700.72 beta-m Stable + Version 34.0.1781.0 Canary
Operating System: Windows 7 Service Pack 1

Reproduction Case:
The following can be executed in the Chrome console to reproduce the test case. A self-contained HTML file has also been attached.

// create a new peer connection - dont need any stun servers for this attack to work
// adding a stun server provides the external ip address of the user as well (see HTML example)
var peer = new webkitRTCPeerConnection(null);

// create an offer object before any streams are added
// this is important because getUserMedia() requires explicit user permission
peer.createOffer(function(sdp) {
peer.setLocalDescription(sdp, function() {
// there seems to be a bug in the async call where the callback is called before the localDescription property has been set
// setTimeout provides some time for the async call to finish
setTimeout(function() {
var sdp = peer.localDescription.sdp;
console.log(sdp);
}, 100);
});
}, function(err) {
console.error(err);
}, {});

https://code.google.com/p/chromium/issues/detail?id=333752

COMMENTAIRE

Ce n'est pas une faille DANS l'implèmentation ou dans l'API... c'est l'API qui est en soit une faille quand l'adresse IP locale n'est pas l'adresse IP visible de l'extérieur, c'est à dire dès qu'on passe par un proxy ou un NAT.

Ce commentaire sous le bug est hallucinant :

#7 juberti@chromium.org
We considered this, but in the end I don't think that introducing user action makes sense. It's not a permission that is well understood ("do you want this application to enumerate your network interfaces?")

With the move to IPv6, the notion of NATed addresses goes away, so any concerns here around exposing internal addresses to applications are only significant in the short term.

If the main concern is the enumeration of all interfaces, one option could be to only return the interface that has the default route. This might complicate wwan/wlan handover scenarios though.

'tain, un dév de Chromium n'a absolument AUCUNE idée de ce qu'est le Monde réel!

J'y crois pas... je suis très déçu par Chromium, là.

corrector · « **Réponse #1 le:** 03 février 2015 à 02:07:43 »

Users can safely visit arbitrary web sites and execute scripts
provided by those sites.

It is important to realize that this includes sites hosting arbitrary
malicious scripts. The motivation for this requirement is simple:
it is trivial for attackers to divert users to sites of their choice.
For instance, an attacker can purchase display advertisements which
direct the user (either automatically or via user clicking) to their
site, at which point the browser will execute the attacker's scripts.
Thus, it is important that it be safe to view arbitrarily malicious
pages. Of course, browsers inevitably have bugs which cause them to
fall short of this goal, but any new WebRTC functionality must be
designed with the intent to meet this standard. The remainder of
this section provides more background on the existing Web security
model.

Source : http://tools.ietf.org/id/draft-ietf-rtcweb-security-05.txt

Cela devrait aller sans dire, mais ça va mieux en le disant.

Mais ça :

5.4. IP Location Privacy

A side effect of the default ICE behavior is that the peer learns
one's IP address, which leaks large amounts of location information.
This has negative privacy consequences in some circumstances. The
API requirements in this section are intended to mitigate this issue.
Note that these requirements are NOT intended to protect the user's
IP address from a malicious site.

Source : http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07#section-5.4

On croit rêver...

corrector · « **Réponse #2 le:** 03 février 2015 à 02:24:10 »

Citer

#21 jorg...@chromium.org
Removing from security queue, implemented as per the spec.

C'est conforme à la spec DONC c'est pas une faille.

Les dévs Chromium sont des très gros connards ou les dévs Chromium sont des énormes connards?

corrector · « **Réponse #3 le:** 03 février 2015 à 03:36:11 »

Exemple utilisant un service externe :

https://github.com/diafygi/webrtc-ips

kgersen · « **Réponse #4 le:** 03 février 2015 à 07:28:04 »

Citation de: corrector le 03 février 2015 à 02:24:10

C'est conforme à la spec DONC c'est pas une faille.

Les dévs Chromium sont des cons ou les dévs Chromium sont des bouffons?

essais de comprendre comment ils fonctionnent avant de les insulter?

deja tu cites un extrais , incomplet et hors contexte. relis le et cites le entier y compris quand ils enlevent/ajoutent des labels.

car il faut comprendre comment fonctionne le 'triage' et les labels (le but est de déterminer le type de bug et qui ensuite doit le traiter et avec quelle priorité). Ajouter un label particulier notifie les personnes en charge de ce domaine ce qui déclenchent leur interventions.

Suites aux différentes interventions dans le suivi du bug ils en sont arriver a décider que , pour le moment, ce n'est pas un probleme de sécurité mais un probleme de privacy/entreprise. Ce n'est pas tout a fait la même chose, la même importance/urgence et ensuite ce n'est pas pris en charge, suivi et superviser par les mêmes personnes.

Et ils n'ont pas tord car c'est avant tout un probleme de privacy/entreprise si on se donne 2 minutes pour réfléchir au probleme.
D'autant que les auteurs de WebRTC sont au courant du 'probleme'.

Franchement beaucoup d'excitation pour pas grand chose.

corrector · « **Réponse #5 le:** 03 février 2015 à 08:24:25 »

Citation de: kgersen le 03 février 2015 à 07:28:04

essais de comprendre comment ils fonctionnent avant de les insulter?

Non, je n'essaie pas de faire ça, je m'en tape. Comme tous les gens censés.

Citation de: kgersen le 03 février 2015 à 07:28:04

deja tu cites un extrais , incomplet et hors contexte.

Le coup du contexte, ça faisait longtemps...

Le contexte, c'est magique.

Une connerie dans un contexte ça devient une non-connerie.

Citation de: kgersen le 03 février 2015 à 07:28:04

Et ils n'ont pas tord car c'est avant tout un probleme de privacy/entreprise si on se donne 2 minutes pour réfléchir au probleme.
D'autant que les auteurs de WebRTC sont au courant du 'probleme'.

Alors si ils sont au courant de cette monstrueuse faille de sécurité, c'est bon.

Ce que j'ai indiqué concernant les dév Chromium ne s'applique pas qu'à eux, hein...

Citation de: kgersen le 03 février 2015 à 07:28:04

Franchement beaucoup d'excitation pour pas grand chose.

La charte m'interdit de caractériser ta réponse comme il faudrait.

Polynesia · « **Réponse #6 le:** 03 février 2015 à 11:48:51 »

Intéressant sauf encore aux non anglophones comme moi...

kgersen · « **Réponse #7 le:** 03 février 2015 à 14:51:03 »

en français:

La mise en oeuvre actuelle de WebRTC dans Chrome et Firefox permet avec du code javascript d'obtenir les @ IP privés (=LAN) du navigateur sans l'accord explicite de l'utilisateur.
exemple ici: http://net.ipcalf.com/ (chez moi ca affiche 192.168.1.42 et d'autres IP locales de mon poste).

C'est un souci pour certains et pas pour d'autres (dans mon cas rien a battre qu'un site puisse obtenir mon IP privée), donc certains caractérisent ça de 'faille de sécurité' alors que d'autre catégorisent ça comme étant un probleme de 'confidentialité/vie privée' (privacy) ou d' 'entreprise' (en gros = ça doit être laissé a l'appréciation de la politique de l'entreprise donc "réglable" par un administrateur). Ca peut être un souci avec certaines configurations de VPN et des IP publics LAN (= probleme d'entreprise et pas grand public).

Chrome et 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).

Ceux qui veulent empêcher ce fonctionnement peuvent, avec Chrome, installer cette extension pour bloquer. Dans Firefox ca se fait directement dans les flags (about:config) avec en désactivant "media.peerconnection.enabled".

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 mais ce débat n'a rien à faire dans le bugtracker de Chrome et n'a pas a le polluer (ca n'est pas non plus aux devs de Chrome de trancher la question mais plus a l'IETF et/ou ceux qui mettent au point les specs de WebRTC). C'est un peu le même débat qu'avec le "user-agent" qui communique l'OS, sa version, le nom du navigateur, sa version a tout les sites qu'on consulte. Personne ne parle de faille de sécurité la ... sauf les extrémistes parano

Et avec IPv6 la question ne se pose même plus (sauf cas tordus).

PacOrly · « **Réponse #8 le:** 03 février 2015 à 15:32:07 »

Merci pour la traduction...

corrector · « **Réponse #9 le:** 03 février 2015 à 15:43:42 »

Citation de: kgersen le 03 février 2015 à 14:51:03

C'est un souci pour certains et pas pour d'autres (dans mon cas rien a battre qu'un site puisse obtenir mon IP privée), donc certains caractérisent ça de 'faille de sécurité' alors que d'autre catégorisent ça comme étant un probleme de 'confidentialité/vie privée' (privacy) ou d' 'entreprise' (en gros = ça doit être laissé a l'appréciation de la politique de l'entreprise donc "réglable" par un administrateur).

Pour la plupart des gens c'est une faille de sécurité.

Pour moi c'est très clairement une faille, donc le débat est clos. Si même moi je dis que c'est une faille alors c'est une faille merci au revoir.

Citation de: kgersen le 03 février 2015 à 14:51:03

Chrome et Firefox respectent les specs de la norme WebRTC et se doivent donc

NON

Il doivent rien du tout à la norme et tout aux utilisateurs, et énormèment d'utilisateurs n'aiment pas ça.

Et l'IP privée ne servira que très très rarement en pratique.

Les normes, c'est des mecs qui s'autorisent à penser des trucs, hein. C'est souvent remplis de conneries, que les connards péteux croient devoir suivre (les très gros connards qui décident pour Firefox, ou pour GNU C). Cela me met hors de moi.

Ces mecs se branlottent avec la norme et crache à la gueule des utilisateurs.

Moi j'ai participé à des normalisations, je sais comment ça se passe, déjà la moitié des mecs ne bittent RIEN à ce qui se trament, souvent il y a 3 mecs qui comprennent les subtilités et les autres qui font confiance. C'est le principe même des comités, la plupart des mecs (et les nanas, hein) font de la figuration.

Citation de: kgersen le 03 février 2015 à 14:51:03

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).

Ceux qui veulent empêcher ce fonctionnement peuvent, avec Chrome, installer cette extension pour bloquer.

Installer une extension pour combler une faille n'est PAS une solution acceptable.

(Je cherche une solution en modifiant le binaire à la main, comme pour virer le support HSTS.)

Citation de: kgersen le 03 février 2015 à 14:51:03

Dans Firefox ca se fait directement dans les flags (about:config) avec en désactivant "media.peerconnection.enabled".

C'est déjà moins pire.

Citation de: kgersen le 03 février 2015 à 14:51:03

Le débat si c'est une faille de sécurité ou juste un probleme de privacy/entreprise n'est bien sur pas tranché

Si beaucoup de gens pensent que c'est une faille alors c'est une faille.

Citation de: kgersen le 03 février 2015 à 14:51:03

et ne le sera peut-être jamais mais ce débat n'a rien à faire dans le bugtracker de Chrome et n'a pas a le polluer (ca n'est pas non plus aux devs de Chrome de trancher la question mais plus a l'IETF et/ou ceux qui mettent au point les specs de WebRTC).

Non! Le débat est tout à fait à sa place dans le bugtracker. C'est fait pour ça un bugtracker. Dire que la norme est la merde est à sa place dans un bugtracker. C'est comme ça.

Citation de: kgersen le 03 février 2015 à 14:51:03

C'est un peu le même débat qu'avec le "user-agent" qui communique l'OS, sa version, le nom du navigateur, sa version a tout les sites qu'on consulte. Personne ne parle de faille de sécurité la ... sauf les extrémistes parano Et avec IPv6 la question ne se pose même plus (sauf cas tordus).

Je vois pas le rapport avec IPv6.

Marin · « **Réponse #10 le:** 03 février 2015 à 17:19:57 »

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).

Sinon, concernant les implications de sécurité de pouvoir connaître l'adresse IP locale du client web, cela doit être évalué sous au moins trois angles :

En tant que vecteur d'attaques réseau : je ne pense pas qu'il y ait grand chose à voir de ce côté là. Entre Image.src, XMLHttpRequest, les WebSockets, voire même les frames et les formulaires HTML basiques, 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, sans pour autant qu'il n'y ait la possibilité d'envoyer des paquets qui soient complètement arbitraires au niveau TCP/UDP. 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).
En tant que mécanisme de traçage persistent : honnêtement, entre les trois tonnes de façons de tracer un utilisateur avec du JavaScript (sessionStorage/localStorage/globalStorage/document.cookie..., le rendu <canvas>...), un plugin quelconque (Flash : les LSO, les divers moyens de communication réseau souvent peu maîtrisés..., également toutes les CVE et fonctionnalités peu maîtrisées de Java, Silverlight...), les en-têtes HTTP (les cookies, l'User-Agent, l'E-Tag...), la manipulation du cache navigateur, le test de nombreuses fonctionnalités spécifiques au navigateur (niveau JS, CSS...)... je ne pense pas que savoir que l'utilisateur est identifié comme 192.168.1.54 derrière le NAT de sa box représente, en tenant compte de l'existant, un vrai risque supplèmentaire en matière de traçage pour l'utilisateur lambda, et l'utilisateur avancé ayant un intérêt pour la protection de sa vie privée aura de toutes manières toujours un moyen de de passer outre.
En tant que mécanisme de contournement de proxy/VPN : c'est sûrement le point le plus fragile, cependant je n'ai encore vu passer d'article qui documente avec précision quels systèmes d'anonymisation, configurés à quel niveau du réseau, avec quels navigateurs et dans quels cas de figure peuvent poser problème dans le cadre de l'échange d'informations ICE. Et ça doit bien être ce qui manque pour pouvoir èmettre un jugement précis là-dessus...

Dans tous les cas, se limiter à "débattre" des heures sur « non c'est une fonctionnalité », « si c'est une vulnérabilité » est stérile et manichéen, il s'agit comme beaucoup de choses une implication technique complexe qui peut être vue sur beaucoup d'angles. Je pense qu'essayer d'être un peu plus précis et factuels dans nos propos et dans notre façon de s'exprimer serait une bonne chose pour tout le monde...

corrector · « **Réponse #11 le:** 03 février 2015 à 18:10:26 »

Pas DU TOUT d'accord.

"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" mais pas de contourner le proxy SOCKS : j'ai un proxy SOCKS mais Chrome a décidé de parler UDP en contournant la config de proxy, c'est une violation de sécurité. Le proxy n'est pas là pour faire joli, ce n'est proxy SOCKS sauf pour UDP, c'est proxy SOCKS point.

- Je peux examiner les cookies, la présence d'autres données stockées dans le navigateur; et d'effacer ces données.

- Le mode navigation privée marche. Effacer les données de navigation marche. Tout cela doit suffit (merci de préciser si ce n'est pas le cas) pour "les trois tonnes de façons de tracer un utilisateur avec du JavaScript", "la manipulation du cache navigateur", etc.

Et si ça ne suffit pas, il y a la solution de changer de profil ou de compte utilisateur ou de navigateur!

- Java est en voie de disparition. Il est utilisé par très peu de sites et certainement pas un moyen discret pour la surveillance à grande échelle.

- "le test de nombreuses fonctionnalités spécifiques au navigateur" permet de distinguer les versions de navigateurs (c'est pour ça que le User-Agent HTTP n'est pas vraiment LE problème) pas les utilisateurs; ou les plugins installés, ou les fonts disponibles, ou les caractéristiques de ces fonts (taille). C'est inévitable vu qu'on peut mesurer le rendu d'une page HTML et les positions des retours à la ligne. Mais on peut avoir de nombreuses configs identiques.

Et si ça ne suffit pas, il y a la solution de navigateur pour changer de signature!

"cependant je n'ai encore vu passer d'article qui documente avec précision quels systèmes d'anonymisation, configurés à quel niveau du réseau, avec quels navigateurs et dans quels cas de figure peuvent poser problème dans le cadre de l'échange d'informations ICE."

Allo la Terre?

N'importe quel système NAT ou proxy HTTP ou proxy SOCKS qui cache l'adresse IP de l'utilisateur est neutralisé. En particulier les VPN "hide my ass".

"en tenant compte de l'existant, un vrai risque supplèmentaire" revient à dire qu'on passe d'une situation problématique à une situation encore plus merdique!

L'idée est qu'on se retrouve avec une merde qui casse complètement une propriété de sécurité.

Auteur Sujet: Faille RTCPeerConnection (Lu 29840 fois)

corrector

Faille RTCPeerConnection

corrector

La faille est une "feature" : webkitRTCPeerConnection

corrector

La faille est une "feature" : webkitRTCPeerConnection

corrector

La faille est une "feature" : webkitRTCPeerConnection

kgersen

La faille est une "feature" : webkitRTCPeerConnection

corrector

La faille est une "feature" : webkitRTCPeerConnection

Polynesia

La faille est une "feature" : webkitRTCPeerConnection

kgersen

La faille est une "feature" : webkitRTCPeerConnection

PacOrly

La faille est une "feature" : webkitRTCPeerConnection

corrector

La faille est une "feature" : webkitRTCPeerConnection

Marin

La faille est une "feature" : webkitRTCPeerConnection

corrector

La faille est une "feature" : webkitRTCPeerConnection