Este es un editorial de opinión de Shinobi, un educador autodidacta en el espacio de Bitcoin y presentador de podcasts de Bitcoin orientado a la tecnología.
Por segunda vez en aproximadamente un mes, se explotó un error de btcd/LND que hizo que se desviaran del consenso de Bitcoin Core. Una vez más, Burak fue el desarrollador que desencadenó esta vulnerabilidad, esta vez fue claramente intencional, y una vez más, fue un problema con el código para analizar las transacciones de Bitcoin por encima de la capa de consenso. Como mencioné en mi artículo sobre el error anterior que desencadenó Burak, antes de Taproot había límites sobre el tamaño del script y los datos testigo en una transacción. Con la activación de Taproot, esos límites se eliminaron dejando solo las limitaciones en el límite de tamaño de bloque para limitar estas partes de transacciones individuales. El problema con el último error fue que, a pesar de que el código de consenso en btcd se actualizó correctamente para reflejar este cambio, el código que maneja la transmisión punto a punto, incluido el análisis de datos antes de enviar o recibir, no se actualizó correctamente. Por lo tanto, los bloques de procesamiento de código y las transacciones antes de que realmente pasaran para ser validados por consenso fallaron en los datos, nunca los pasaron a la lógica de validación de consenso y el bloque en cuestión nunca se validó.
Algo muy similar sucedió esta vez. Otro límite en la sección peer-to-peer de la base de código fue imponer una restricción en los datos testigo de forma incorrecta, limitándolos a un máximo de 1/8 del tamaño del bloque en lugar del tamaño completo del bloque. Burak elaboró un transacción con datos de testigos solo una unidad de peso por encima del límite estricto y una vez más se detuvieron los nodos btcd y LND en esa altura de bloque. Esta transacción fue una transacción no estándar, lo que significa que, aunque es perfectamente válida según las reglas de consenso, no es válida de acuerdo con la política de mempool predeterminada y, por lo tanto, los nodos no la transmitirán a través de la red. Es perfectamente posible minarlo en un bloque, pero la única forma de hacerlo es proporcionarlo directamente a un minero, que es lo que hizo Burak con la ayuda de F2Pool.
Esto realmente lleva a casa el punto de que cualquier pieza de código cuyo propósito sea analizar y validar los datos de Bitcoin debe ser fuertemente auditada para garantizar que esté en línea con lo que hará Bitcoin Core. No importa si ese código es el motor de consenso para la implementación de un nodo o simplemente un fragmento de código que pasa transacciones para un nodo Lightning. Este segundo error fue literalmente justo encima del del mes pasado en la base de código. Ni siquiera fue descubierto por nadie en Lightning Labs. AJ Towns lo informó el 11 de octubre, dos días después de que el error original fuera activado por la transacción multigrado 998 de 999 de Burak. Se publicó públicamente en Github durante 10 horas antes de eliminarse. Luego se realizó una solución, pero no se publicó, con la intención de solucionar el problema de forma silenciosa en la próxima versión de LND.
Ahora, este es un procedimiento bastante estándar para una vulnerabilidad grave, especialmente con un proyecto como Bitcoin Core, donde dicha vulnerabilidad puede causar daños graves a la red/protocolo de la capa base. Pero en este caso específico, presentaba un grave riesgo para los fondos de los usuarios de LND, y dado que estaba literalmente al lado del error anterior que tenía los mismos riesgos, las posibilidades de que se encontrara y explotara eran muy altas. como lo demuestra Burak. Esto plantea la pregunta de si el enfoque de parche silencioso es el camino a seguir cuando se trata de vulnerabilidades como esta que pueden dejar a los usuarios expuestos al robo de fondos (porque su nodo no puede detectar estados de canales antiguos y penalizarlos adecuadamente).
Como comenté en mi artículo sobre el último error, si un actor malintencionado hubiera encontrado los errores antes que un desarrollador bien intencionado, podría haber abierto tácticamente nuevos canales a los nodos vulnerables, enrutado todo el contenido de esos canales hacia ellos mismos y luego aprovechó el error. A partir de ahí, tendrían esos fondos bajo su control y además podrían cerrar el canal con el estado inicial, literalmente duplicando su dinero. Lo que hizo Burak al explotar activamente este problema de una manera irónica en realidad protegió a los usuarios de LND de tal ataque.
Una vez que se explotaba, los usuarios estaban abiertos a este tipo de ataques de pares preexistentes con los que ya tenían canales abiertos, pero ya no podían ser atacados específicamente con nuevos canales. Sus nodos estaban paralizados y nunca reconocerían ni procesarían pagos a través de canales que alguien intentó abrir después del bloqueo que paralizó su nodo. Entonces, si bien no eliminó por completo el riesgo de que los usuarios fueran explotados, limitó ese riesgo a las personas con las que ya tenían un canal. La acción de Burak lo mitigó. Personalmente, creo que este tipo de acción en respuesta al error tenía sentido; limitó el daño, hizo que los usuarios fueran conscientes del riesgo y condujo a que se reparara rápidamente.
LND tampoco fue lo único afectado. líquido el proceso de vinculación también se rompiórequiriendo actualizaciones a los funcionarios de la federación para solucionarlo. Versiones anteriores de Rust Bitcoin también se vieron afectados, lo que provocó que el bloqueo afectara a algunos exploradores de bloques e instancias de electrs (una implementación del servidor backend para Electrum Wallet). Ahora, con la excepción de la vinculación de Liquid que finalmente expone los fondos a las claves de recuperación de emergencia en poder de Blockstream después de la expiración de un bloqueo de tiempo y, de manera realista, en la trama de la película estilo atraco donde Blockstream robó estos fondos, todos saben exactamente a quién perseguir: estos otros los problemas nunca ponen en riesgo los fondos de nadie en ningún momento. Además, Rust Bitcoin en realidad corrigió este error específico en versiones más nuevas, lo que aparentemente no condujo a ninguna comunicación con los mantenedores de otras bases de código para resaltar el potencial de tales problemas. Fue solo la explotación activa del error en vivo en la red lo que expuso ampliamente que el problema existía en múltiples bases de código.
Esto plantea algunos problemas importantes cuando se trata de vulnerabilidades como esta en el software de Capa 2 en Bitcoin. En primer lugar, la seriedad con la que se auditan estas bases de código en busca de errores de seguridad y cómo se prioriza frente a la integración de nuevas funciones. Creo que es muy revelador que la seguridad no siempre se priorice dado que este segundo error ni siquiera fue encontrado por los mantenedores del código base donde estaba presente, a pesar de que estaba literalmente al lado del error inicial descubierto el mes pasado. Después de un error importante que puso en riesgo los fondos de los usuarios, ¿no se realizó una auditoría interna de ese código base? ¿Hizo falta alguien ajeno al proyecto para descubrirlo? Eso no demuestra una prioridad para salvaguardar los fondos de los usuarios sobre la creación de nuevas funciones para atraer a más usuarios. En segundo lugar, el hecho de que este problema ya se corrigió en Rust Bitcoin demuestra una falta de comunicación entre los mantenedores de diferentes bases de código con respecto a errores como este. Esto es bastante comprensible, ya que ser bases de código completamente diferentes no hace que alguien que encontró un error en uno piense de inmediato: “Debería contactar a otros equipos que escriben software similar en lenguajes de programación totalmente diferentes para advertirles sobre el potencial de tal error”. No encuentra un error en Windows e inmediatamente piensa en informar el error a los mantenedores del kernel de Linux. Sin embargo, Bitcoin como protocolo para el consenso distribuido en una red global es una bestia muy diferente; tal vez los desarrolladores de Bitcoin deberían comenzar a pensar de esa manera cuando se trata de vulnerabilidades en el software de Bitcoin. Especialmente cuando se trata de analizar e interpretar datos relacionados con el consenso.
Por último, tal vez cuando se trata de protocolos como Lightning, que dependen de la observación de la cadena de bloques en todo momento para poder reaccionar a los estados de los canales antiguos con el fin de mantener la seguridad, el análisis independiente y la verificación de los datos deben mantenerse al mínimo absoluto, si no eliminado por completo y delegado a Bitcoin Core o datos derivados directamente de él. Core Lightning está diseñado de esta manera, conectándose a una instancia de Bitcoin Core y dependiendo completamente de eso para la validación de bloques y transacciones. Si LND funcionara de la misma manera, ninguno de estos errores en btcd habría afectado a los usuarios de LND de una manera que pusiera en riesgo sus fondos.
Cualquiera que sea la forma en que se manejen las cosas, ya sea subcontratando la validación por completo o simplemente minimizando la validación interna y abordándola con mucho más cuidado, este incidente muestra que algo debe cambiar al abordar el problema de cómo el software de Capa 2 maneja la interacción con los datos relacionados con el consenso. Una vez más, todos tienen mucha suerte de que esto no haya sido explotado por un actor malicioso, sino por un desarrollador que demuestra un punto. Dicho esto, Bitcoin no puede contar con tener suerte o esperar que no existan actores maliciosos.
Los desarrolladores y usuarios deben centrarse en mejorar los procesos para evitar que vuelvan a ocurrir incidentes como este, y no jugar el juego de echarse la culpa como una patata caliente.
Esta es una publicación invitada de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.
