Explotar el Lightning Bug fue la elección ética

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.

For the second time in roughly a month, btcd/LND have had a bug exploited which caused them to deviate in consensus from Bitcoin Core. Once again, Burak was the developer who triggered this vulnerability — this time it was clearly intentional — and once again, it was an issue with code for parsing Bitcoin transactions above the consensus layer. As I discussed in my pieza sobre el error anterior que Burak desencadenó, 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 transaccional 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.

This really drives home the point that any piece of code whose purpose is to parse and validate Bitcoin data must be heavily audited in order to ensure it is in line with what Bitcoin Core will do. It doesn’t matter if that code is the consensus engine for a node implementation or just a piece of code passing transactions around for a Lightning node. This second bug was 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.

Now, this is pretty standard procedure for a serious vulnerability, especially with a project like Bitcoin Core where such a vulnerability can actually cause serious damage to the base-layer network/protocol. But in this specific case, it presented a serious risk to LND users’ funds, and given the fact that it was literally right next to the prior bug that had the same risks, the chances that it would be found and exploited were very high, as demonstrated by Burak. This begs the question of whether the quiet-patch approach is the way to go when it comes to vulnerabilities like this that can leave users open to theft of funds (because their node is left unable to detect old channel states and properly penalize them).

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. Older versions of Rust Bitcoin were affected as well, which caused the stall to affect some block explorers and electrs instances (an implementation of the backend server for Electrum Wallet). Now, with the exception of Liquid’s peg eventually exposing funds to the emergency recovery keys held by Blockstream after a timelock expiry — and, realistically in the heist-style movie plot where Blockstream stole these funds, everyone knows exactly who to go after — these other issues never put anyone’s funds at risk at any point. Also, Rust Bitcoin had actually patched this specific bug in newer versions, which apparently didn’t lead to any communication with maintainers of other codebases to highlight the potential for such issues. It was only the active exploitation of the bug live on the network that widely exposed that the issue existed in multiple codebases.

This brings up some big issues when it comes to vulnerabilities like this in Layer 2 software on Bitcoin. First, the seriousness with which these codebases are audited for security bugs and how that is prioritized versus the integration of new features. I think it is very telling that security is not always prioritized given that this second bug was not even found by the maintainers of the codebase where it was present, even though it was literally right next to the initial bug discovered last month. After one major bug that put users’ funds at risk, was no internal audit of that codebase done? It took someone from outside the project to discover it? That does not demonstrate a priority to safeguard users’ funds over building new features to draw in more users. Second, the fact that this issue was already patched in Rust Bitcoin demonstrates a lack of communication across maintainers of different codebases in regards to bugs like this. This is pretty understandable, as being completely different codebases doesn’t make someone who found a bug in one immediately think, “I should contact other teams writing similar software in totally different programming languages to warn them about the potential for such a bug.” You don’t find a bug in Windows and then immediately think to go report the bug to Linux kernel maintainers. Bitcoin as a protocol for distributed consensus across a global network is a very different beast, however; maybe Bitcoin developers should start to think along those lines when it comes to vulnerabilities in Bitcoin software. Especially when it comes to parsing and interpreting data that is consensus related.

Lastly, maybe when it comes to protocols like Lightning, which depend on observing the blockchain at all times to be able to react to old channel states in order to maintain security, independent parsing and verification of data should be kept to an absolute minimum — if not removed entirely and delegated to Bitcoin Core or data directly derived from it. Core Lightning is architected in this way, connecting to an instance of Bitcoin Core and depending entirely on that for validation of blocks and transactions. If LND worked the same way, neither of these bugs in btcd would have affected LND users in a way that put their funds at risk.

Whichever way things are handled — either outsourcing validation entirely or simply minimizing internal validation and approaching it with much more care — this incident shows that something needs to change in approaching the issue of how Layer 2 software handles interacting with consensus-related data. Once again, everyone is very lucky that this was not exploited by a malicious actor, but instead by a developer proving a point. That being said, Bitcoin cannot count on getting lucky or hoping that malicious actors do not exist.

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.