[Important] Report de la mise à jour Constantinople (article réactualisé)

Rebondissement de dernière minute sur la mise à jour Constantinople : la société Chain Security a publié le 15 janvier 2018, moins de 48 heures avant l’heure prévue pour l’activation de la mise à jour, un article sur une potentielle nouvelle attaque rendue possible par celle-ci dans des smart-contracts déjà déployés. Après un call urgent entre développeurs du protocole et membres importants de la communauté, les premiers ont décidé par sécurité de publier un patch permettant de reporter le fork, le temps d’examiner le sérieux de cette découverte tardive.

(dernière mise à jour de l’article : 16/01/2019 à 17h55)

Quelle conséquences ?

A priori, aucune conséquence matérielle directe – sinon ledit report de la mise à jour Constantinople. En effet, le vecteur d’attaque potentiel ne sera finalement pas été déployé.

De plus, le report sera quasiment invisible pour la grande majorité du public. La mise à jour Constatinople contient essentiellement des améliorations pour développeurs de smart-contracts et de solution de second niveau pour Ethereum (plus d’infos dans cet article). Son report n’est pas critique et ne change rien pour les utilisateurs d’Ethereum et les détenteurs d’ether.

La principale conséquence, visible dès à présent, est en matière de mauvaise presse pour Ethereum Ce n’est pas le premier report de cette mise à jour et même si la faille était complexe à identifier, nul doute que l’événement sera interprété négativement par les observateurs extérieurs.

Que faut-il faire ?

Une mise à jour des clients principaux est maintenant disponible :

• Geth, version 1.8.21 : https://github.com/ethereum/go-ethereum/releases/tag/v1.8.21
• Parity, version 2.2.7 (stable) : https://github.com/paritytech/parity-ethereum/releases/tag/v2.2.7
• Parity, version 2.3.0 (beta) : https://github.com/paritytech/parity-ethereum/releases/tag/v2.3.0
• Pantheon, version 0.8.5 : https://github.com/PegaSysEng/pantheon/releases/tag/0.8.5

La mise à jour doit être appliquée par les personnes qui maintiennent un node Ethereum, et ce avant l’heure initialement prévue du fork (soit approximativement 3-4 heures du matin le 17 janvier 2019).

Attention : si vous avez des ethers mais ne faites pas fonctionner de noeud Ethereum, vous n’avez toujours rien à faire. 

Quel est la faille potentielle identifiée ?

L’EIP1283 (https://eips.ethereum.org/EIPS/eip-1283) en cause a pour objet de baisser le coût en gas de certaines opérations relatives à l’écriture de données sur Ethereum (plus de détails dans l’article dédié), pour rendre l’exécution de certains smart-contracts moins coûteuse et plus efficiente.

Cependant, en changeant ce paramètre, il est possible que certains contrats ayant été auparavant déployés, avec comme postulat le coût en gas plus élevé d’avant la mise à jour, se voient vulnérables à une attaque spécifique dite de type « re-entrancy attack ». Sans entrer dans les détails, il s’agit d’attaques visant à utiliser des appels entre smart-contracts pour exécuter des fractions de smart-contract spécifiques dans un but non originalement prévu par l’auteur. C’est une attaque de type « re-entrancy » qui avait permis à un pirate de drainer The DAO en juin 2016.

Qui est vulnérable ?

Les contrats qui pourraient être vulnérables sont ceux qui utilisent une fonction transfer() ou send() function suivi d’une opération de changement d’état. 

Il est cependant important de noter que la société Chain Security qui a effectué l’analyse a également vérifié l’ensemble des smart-contracts déployés dont le code source est public et n’a détecté aucun smart-contract pouvant être exploité. Il s’agit donc ici d’une attaque purement potentielle.

Le report de la mise à jour a tout de même été décidé par sécurité, mais il est probable que cette attaque n’aurait pas pu être concrètement exécutée de toute façon.

Pourquoi le problème n’a-t-il pas été identifié plus tôt ?

Il faut souligner que l’EIP n’est pas fautif, dans le sens ou il fonctionne absolument comme prévu. La fonction modifiée répond comme elle le devrait et le coût en gas est bien modifié.

Ce genre de problématique n’est en effet pas consubstantiel à la fonction modifiée elle même mais à certains cas d’usage et certaines logiques de programmation mises en place sur la base de ces fonctions par les développeurs de smart-contracts.

Il est donc extrêmement difficile d’anticiper ces problématiques, a fortiori par les développeurs du protocole qui n’ont pas vocation à programmer ou déployer des smart-contracts eux-mêmes.

Cette alerte va selon toute probabilité conduire la communauté à mettre en place des processus spécifiques pour détecter ce type de problématiques plus tôt, par exemple en faisant auditer les EIP par des sociétés spécialisées dans l’audit de smart-contract.

Que va-t-il se passer maintenant ?

Rien n’est écrit dans le marbre encore. La prochaine date de mise à jour sera décidée après consultation de la communauté lors de la prochaine conférence téléphonique hebdomadaire des développeurs du protocole, qui se tient tous les vendredis. A cette occasion la gravité réelle de cette problématique sera évaluée et il sera décidé ou non de maintenir l’EIP 1283 dans Constantinople. Dans le cas ou la décision serait négative, la mise à jour serait déployée sans cet EIP dès que possible.

Nous vous tiendrons informés des prochains rebondissements sur cette mise à jour dès que nous aurons plus d’information.