El equipo de desarrollo de XRP Ledger (XRPL) reveló el 9 de octubre una falla de desbordamiento de enteros que, bajo condiciones cuidadosamente construidas, pudo haber permitido crear XRP utilizable de la nada. La corrección se lanzó en la versión 3.4.1 de xrpld el 25 de septiembre, aproximadamente dos semanas antes de la revelación pública, y el equipo reportó no haber encontrado evidencia de que la vulnerabilidad hubiera sido explotada en una red pública.

Los detalles se presentaron en el informe de revelación de vulnerabilidad del 9 de octubre de XRPL.

Un cálculo de pago que pudo haber producido XRP de la nada

El informe describe una falla de desbordamiento de enteros en el motor de pagos del ledger. Bajo condiciones cuidadosamente construidas, un pago que consumía muchas ofertas del libro de órdenes pudo haber acreditado en cuentas XRP que el remitente nunca pagó realmente. Los libros de órdenes son una estructura nativa de XRPL, parte del exchange incorporado del ledger, por lo que la aritmética defectuosa se encuentra en el código que sustenta tanto el comercio como los pagos en el ledger.

Cada oferta individual en la transacción podía parecer válida por sí sola. La falla surgió cuando el motor sumó los montos de XRP de todas ellas. Una vez que el total superó el tamaño máximo del número utilizado para ese cálculo, podía dar la vuelta a un valor mucho más pequeño en lugar de generar un error.

En ese escenario, el motor seguía acreditando a los propietarios de las ofertas sus montos completos de XRP mientras cobraba al comprador solo el total desbordado. La diferencia representaba XRP recién creado, que luego podía moverse, negociarse o enviarse a un exchange como cualquier otro saldo.

Por qué la falla era grave

El ataque no requería un saldo grande de XRP. Un atacante pudo haber controlado las cuentas que colocaban las ofertas, pagado las reservas de cuenta y las tarifas de transacción necesarias, y luego distribuido el XRP creado entre esas cuentas.

La vulnerabilidad radicaba en la aritmética de pagos y no en el acceso a billeteras, por lo que las claves de cuenta no se vieron afectadas. Activarla requería cientos de ofertas con precios deliberados y una transacción diseñada para consumirlas juntas; un pago o intercambio ordinario de XRP no se acercaría a los valores necesarios para provocar el desbordamiento.

Para un ledger, pocos defectos son tan sensibles como uno que puede acuñar unidades utilizables, porque cada saldo depende de que el nuevo XRP entre en circulación solo a través de las reglas definidas por la red.

XRPL dijo que no encontró evidencia de explotación en una red pública, y no se reportaron compromisos de claves privadas, pérdidas de fondos ni fallos de consenso. La falla parece haber estado presente desde que el motor de pagos actual fue escrito en 2015, y permaneció sin descubrirse porque la actividad normal nunca alcanzó el límite aritmético.

La protección existente del ledger contra XRP recién creado también dependía del mismo tipo de suma. Podía desbordarse de la misma manera que el motor de pagos, permitiendo que la transacción pareciera normal en lugar de señalar el aumento inesperado de saldos.

Por qué los desarrolladores usaron una implementación de emergencia

Los desarrolladores lanzaron la corrección del desbordamiento antes de publicar sus detalles técnicos porque un cronograma normal de enmiendas habría dejado un exploit conocido disponible durante semanas. El parche se lanzó en la versión 3.4.1 de xrpld el 25 de septiembre, mientras que la revelación pública siguió el 9 de octubre.

XRPL normalmente cambia las reglas de las transacciones mediante enmiendas. Los validadores primero actualizan su software y luego mantienen el soporte requerido durante un período determinado antes de que la nueva regla se active en el mismo punto del ledger en toda la red. Ese proceso evita situaciones en las que diferentes servidores llegan a conclusiones distintas sobre la misma transacción.

Esperar ese proceso habría creado un problema difícil en este caso. Como xrpld es de código abierto, publicar la reparación podría haber mostrado a los atacantes dónde buscar mientras el software antiguo todavía aceptaba la ruta de transacción vulnerable. El equipo, por lo tanto, hizo que la nueva verificación de desbordamiento entrara en vigor cuando un servidor individual se actualizara.

Ese enfoque más rápido conllevaba un riesgo temporal de compatibilidad: un servidor sin parchear pudo haber aceptado una transacción de exploit que un servidor actualizado rechazaba. Los desarrolladores consideraron eso menos peligroso que permitir que el XRP creado entrara al mercado. Según el informe, más del 80% de los validadores en la UNL predeterminada se habían actualizado el día que se lanzó la versión 3.4.1.

La revelación cubrió una segunda falla independiente

El informe también detalló un problema de validación en la próxima función Batch de XRPL, que permite a los usuarios enviar varias transacciones como una sola unidad. La falla pudo haber causado que servidores que ejecutaban diferentes versiones del software discreparan sobre una transacción Batch malformada, interrumpiendo la validación del ledger o rompiendo aplicaciones que procesan datos de transacciones.

La falla de Batch se detectó antes de que la función llegara a la mainnet. El problema de desbordamiento, en cambio, afectaba el código existente del motor de pagos, razón por la cual su parche no podía esperar un ciclo de activación estándar. Con la función aún pendiente, su llegada a la mainnet con la corrección de validación ya en su lugar es la parte de esta revelación que queda por delante.

El informe llegó mientras XRPL también estaba activando nuevas herramientas de control de cuentas para empresas. Los cambios abordan diferentes partes del ledger, pero ambos dependen de que los operadores de nodos, proveedores de billeteras y desarrolladores sigan las mismas reglas actuales.

Qué deben hacer los usuarios y operadores

Los poseedores regulares de XRP no necesitan mover fondos, reemplazar una billetera ni intercambiar sus tokens. La actualización concierne al software que valida las transacciones, no a los saldos de cuenta, las claves de las billeteras ni al suministro de XRP en poder de los usuarios.

• Poseedores de XRP: No se requiere ninguna acción.
• Usuarios de exchanges: Sigan los avisos de la plataforma si un exchange realiza mantenimiento en su propia infraestructura de XRPL.
• Operadores de nodos: Actualicen a xrpld 3.4.1 o posterior para mantenerse sincronizados con la red. Los servidores antiguos ahora están bloqueados por enmiendas tras la activación de la corrección de Batch, lo que significa que no pueden seguir las reglas actuales del ledger hasta que se actualicen.

La corrección protegió las reglas de suministro de XRP antes de que fueran probadas

La revelación muestra qué tan cerca estuvo el ledger de una falla en la integridad del suministro y por qué los validadores actuaron con rapidez. La falla se corrigió antes de que sus detalles se hicieran públicos, no se encontró ningún exploit, y el motor de pagos ahora utiliza verificaciones diseñadas para detener esta clase de error aritmético antes de que llegue a un ledger validado. Lo que queda por ver desde afuera es qué tan rápido el resto de la red converge en xrpld 3.4.1 o posterior, dado que los servidores sin parchear ya están bloqueados por enmiendas para seguir el ledger actual.

Este artículo tiene fines informativos únicamente y no constituye asesoramiento de inversión ni técnico. Los operadores de nodos deben revisar la documentación actual de versiones de XRPL antes de actualizar la infraestructura de producción.

Este artículo se basa en una publicación original de Coindoo.