https://getmonero.org/2016/09/21/a-statement-on-the-mwr-labs-disclosure.htmlGoogle translate :
Une déclaration sur la divulgation MWR Labs
Publié par: Riccardo Spagni (fluffypony)
Déclaration
Il semble y avoir certaines idées fausses et même carrément fausses déclarations déployés autour de la RPC "bug" non authentifié qui a été «découvert» par MWR Labs, et nous aimerions faire certains faits de l'affaire claire.
Tout d'abord, il est important de se rappeler que Monero est un projet open-source non capitalisé, et le projet ne se déplace aussi vite que les bénévoles qui mettent leur temps et d'efforts. L'équipe fait Monero de base en tant que gardiens du projet, mais nous ne pouvons pas représenter chaque développeur possible ou contributeur, et nous ne pouvons certainement pas représenter tous les utilisateurs. Ainsi, cette déclaration est de notre position et nous seuls.
MWR Labs a bel et bien nous contacter et responsable divulguer l'attaque CSRF. Ce ne fut pas un problème inconnu de la communauté - voir, par exemple, cet StackExchange commentaire:
http://monero.stackexchange.com/a/777/47, et cela a également été mis en évidence par Juliano Rizzo de Coinspect en 2014.
En vérité, l'authentification RPC a pris quelque chose d'un siège arrière, comme nous avons travaillé sur le remplacement de la couche RPC avec 0MQ, qui a un support pour le chiffrement et l'authentification. L'interface RPC va vivre dans un stub indépendant, et gagnera l'authentification et le soutien TLS lorsque quelqu'un est disposé et apte à travailler. En outre, le Monero GUI officiel ne pas utiliser la couche RPC, et met en œuvre directement le libwallet_api pour toutes ses fonctions de porte-monnaie.
Le RPC unauthenticated est avéré utile, si, comme il est le seul moyen pour les échanges, les piscines minières et les intégrateurs pour intégrer Monero. Echanges, les piscines et les intégrateurs ne sont pas en danger avec cette attaque CSRF, car il est impensable qu'un service de garde serait l'hôte d'un portefeuille à chaud sur un ordinateur équipé d'un navigateur - ce sont des systèmes extrêmement sensibles et le porte-monnaie chaude seraient hébergés dans un extrêmement environnement bien défendu, avec la plupart des fonds dans un portefeuille hors site à froid, de peur que tous les fonds déposés volés.
Ainsi, les bibliothèques telles que MoneroNJS et Monero NodeJS ne peuvent pas être considérés comme «vulnérables» à cela, parce qu'ils sont des bibliothèques qui sont utilisés par les intégrateurs et non par un logiciel qui fonctionnerait sur une machine avec un navigateur en arrière-plan. Aucun système automatisé qui a un portefeuille chaud ne devrait jamais fonctionner dans un tel environnement précaire, et les développeurs sont très conscients de cela. Les déclarations de MWR Labs affirmant que ces bibliothèques sont vulnérables sont techniquement vrai, dans un sens, mais cette observation est comme dire que tous les portefeuilles Monero sont à risque si vous utilisez "password" comme mot de passe et publiez également votre fichier de portefeuille sur Dropbox et partager le lien sur Reddit - techniquement vrai, mais une observation en grande partie inutile.
De même, les allégations de MWR Lab de certains portefeuilles étant vulnérables est tout aussi inutile. MoneroGui.Net, par exemple, a une note énorme sur le README soulignant que le projet est arrêté. La même chose vaut pour bitmonero-qt et MiniNodo, qui sont tous deux unmaintained. Tous ces portefeuilles pourraient même ne pas fonctionner avec la version actuelle de Monero, ils sont donc techniquement vulnérables, mais il est même pas possible pour quiconque de les utiliser.
Les deux seuls portefeuilles dans la liste de MWR Lab qui sont réellement vulnérables, et sont effectivement utilisés, sont bigreddmachine est Google Chrome portefeuille et lightWallet2 de jwinterm. En réponse à la divulgation, nous avons ajouté un patch rapide pour fournir un moyen pour ces deux portefeuilles pour empêcher l'attaque. Ils ont, à leur tour, patchés leurs clients en conséquence.
Nous ne sommes pas activer la fonctionnalité par défaut pour plusieurs raisons:
1. Si nous avions fourni un drapeau pour désactiver la fonctionnalité, il créerait un faux sentiment de sécurité si l'un des portefeuilles développés activement décidé de passer tout ce drapeau comme une «solution» rapide.
2. Il aurait brisé toutes les piscines d'exploitation minière, et depuis le logiciel de la piscine de l'exploitation minière est largement fragmenté et non maintenu au centre il y a une grande chance que les opérateurs de la piscine aurait eu du mal à ajouter le support de leur propre gré (à moins que nous avons ajouté un indicateur d'invalidation, qui vient conduit au point numéro 1)
3. Il aurait battu tous les intégrateurs et les commerçants, et ils doivent coder dans un sous-système qui va tomber dans quelques mois une fois que nous avons eu la chance de ré-adresse la question de l'authentification RPC.
Il est important de souligner que ce ne sont pas un défaut dans Monero, ou dans la mise en œuvre ou dans les procédés de cryptographie. Cela ne veut pas même quelque chose que vous pourriez rencontrer en utilisant simplement monero-wallet-cli. Vous devez utiliser activement monero-wallet-cli en mode RPC, sur une machine particulièrement vulnérable, puis cliquez sur un lien malveillant sur un site Web en utilisant un navigateur sur le même ordinateur.
Non seulement ce patché, mais les deux clients activement développés qui ont été réellement affectés par ce ont été patché, et cela a été fait d'une manière qui ne perturbe pas le logiciel côté serveur existant.
Plus important encore, depuis monero-wallet-cli ne permet pas le mode RPC par défaut, il n'y a rien qui est vulnérable en elle à moins que l'utilisateur active activement un paramètre qui permet à quelqu'un de contrôler à distance le porte-monnaie.
Nous espérons que MWR Labs noter dans leur conseil, et l'ajuster en conséquence.
- L'équipe de base Monero
) pour que ça marche? Car je crois avoir compris qu'après ça je dois rentrer le seed. Mais simplewallet ou ligne de commande ne connaisse pas .... 
