La publicación de la nueva versión del cliente Bitcoin Core ha solucionado una potencial falla crítica de la red. El bug implicaba una vulnerabilidad de denegación de servicio (DoS), introducida en la versión 0.14.0, que había permanecido sin ser detectada hasta ahora y que causaba la caída del cliente de Bitcoin Core al tratar de validarse un bloque para realizar un ataque de doble gasto.
Esto no es primera vez que ocurre, pues el protocolo Bitcoin se ha impuesto a otros errores similares, gracias a la labor de los desarrolladores y al propio funcionamiento del código. Bitcoin tiene casi diez años funcionando, pero para poder mantenerse ha tenido que atravesar momentos críticos, en donde vulnerabilidades DoS también han tenido lugar. De hecho, de acuerdo con el archivo de vulnerabilidades comunes de Bitcoin, el protocolo ha enfrentado y superado hasta 15 episodios de esta naturaleza hasta el día de hoy.
Otras vulnerabilidades DoS
La primera falla de este tipo se remonta al 28 de julio de 2010. Entonces la falla afectó el OP_LSHIFT y si bien no llegó a prosperar en la red principal, en la testnet provocó que varios mineros fallaran al procesar una transacción con este OP. Durante ese año también hubo otras dos fallas de este tipo, aunque fueron atendidas y resueltas sin mayores contratiempos.
No obstante, no siempre ha sido tan sencillo y en algunos momentos, errores similares se han traducido en momentos de tensión. Tal es el caso de una falla descubierta el 30 de enero de 2013 a través de la que un atacante podía generar una transacción con un nivel de dificultad tan alto que hiciera muy difícil su procesamiento en la red. El objetivo de este tipo de ataque es generar una transacción que necesite muchas firmas antes de poder ser ejecutada.
Uno puede lograr esto tratando de gastar muchas salidas sin utilizar anteriores de las que posee, con una única verificación de firma para cada uno. Pero resulta que ese ataque es bastante caro (…) si el atacante es un minero, puede crear una transacción que expone 10K salidas (TxPrep) y seguirla por la transacción que las consume (TxAttack). Pero TxPrep requeriría 340 kbytes adicionales, por lo que TxAttack sería más corto de lo esperado.
Anuncio sobre la falla de transacciones difíciles de verificar
La vulnerabilidad aún no se ha resuelto debido a que para eliminar la posibilidad de este tipo de transacciones extrapesadas habría que realizar modificaciones importantes al protocolo, lo que implica la aplicación de un hardfork. ¿Y por qué no se realiza la bifurcación? Pues el equipo de Bitcoin Core, desarrolladores y especialistas del protocolo, han expresado en varias oportunidades que el avance técnico de Bitcoin se realiza evitando este tipo de eventos, aplicando modificaciones sustanciales a la red a través de soft forks o reescrituras del script.
La falla más reciente de este tipo es de inicios de julio del presente año. Se trata de un vector de ataque asociado al sistema de alerta final. Discutida en principio por Bryan Bishop, el vector vulnerable se encontraba en el sistema de alertas de Bitcoin. La eliminación de este sistema del protocolo minimizó completamente la posibilidad de que esta falla fuera aprovechada por algún usuario malicioso en el futuro.
Sin embargo, dado que muchos proyectos criptográficos han utilizado la arquitectura de Bitcoin, al develar esta dificultad inherente al sistema de alarmas de la red, Bishop hizo pública una potencial falla en otras redes que habían utilizado el mismo diseño. En este caso, al exponer la forma en la que podría aprovecharse la falla y eliminar su incidencia de la red, expuso también las carencias de otros proyectos de criptoactivos.
¿Qué sugieren estos errores?
En primer lugar, queda claro que el código de Bitcoin no es perfecto y aún tiene margen de mejora. Luego, la velocidad con la que se atienden los problemas de la red, como en la reciente falla crítica encontrada, demuestra que los desarrolladores del proyecto están capacitados tanto para profundizar el funcionamiento actual de Bitcoin como para atender problemas inherentes a su propio funcionamiento.
El hecho de que aún no se tenga información sobre quién y cómo consiguió el error da cuenta de que el esquema de revelación responsable sobre las fallas o vulnerabilidades del protocolo de Bitcoin funciona plenamente. Si bien la falla podría haber comprometido el buen funcionamiento de la red, la falla y su solución han sido discutidos y concretados de manera confidencial, de forma que ningún potencial atacante ha podido aprovechar el vector antes de que se solucionara la vulnerabilidad.
Otro elemento destacable es que a pesar de las vulnerabilidades, el protocolo no ha sido completamente destruido y ha sido fortalecido. Así, los 37 errores o vulnerabilidades halladas hasta ahora han servido para aleccionar a los desarrolladores y mejorar el funcionamiento de la red, haciendo el protocolo cada vez más resistente. Las criptomonedas que comparten el código de Bitcoin en diversas proporciones deberían hacer lo mismo para conservar su integridad.
Imagen destacada por tiero / stock.adobe.com
