XRP Ledger corrige un fallo de hace una década que pudo haber roto su límite de 100.000 millones de tokens

Los desarrolladores del XRP Ledger revelaron el 9 de octubre que un fallo de desbordamiento de enteros en el motor de pagos de la red podría haber permitido a un atacante crear nuevos XRP de la nada y romper el límite de 100.000 millones de tokens fijado cuando el ledger se lanzó en 2012. La falla se corrigió en la versión de software xrpld 3.4.1, publicada el 25 de septiembre, y RippleX afirmó que no encontró evidencia de que el fallo se haya explotado en una red pública, según el informe oficial de divulgación de vulnerabilidades. El fallo fue reportado a través del programa de bug bounty de XRPL por el investigador Cayden Liao y Veria AI el 22 de septiembre. Los ingenieros de RippleX reprodujeron el ataque en un servidor independiente, confirmaron que los XRP recién creados podían gastarse en una transacción posterior y elevaron la gravedad del hallazgo de grave a crítica. Cómo el fallo podría haber acuñado XRP La vulnerabilidad residía en el manejo de desbordamientos del motor de pagos. Cuando un único pago consumía muchas ofertas en el exchange integrado del ledger, el software sumaba lo que el comprador debía usando suma de enteros de 64 bits sin comprobar desbordamientos. Unos cientos de ofertas, cada una pidiendo una cantidad muy grande de XRP, podían llevar ese total más allá de lo que puede contener un número de 64 bits y hacerlo desbordar hasta un valor minúsculo. Cada propietario de la oferta recibía el pago completo; al comprador solo se le cobraba el total desbordado, lo que dejaba XRP recién acuñado en las cuentas del atacante. Dos verificaciones de seguridad deberían haber detectado esto y no lo hicieron. El invariante del ledger de “no se creó XRP” suma los cambios netos de saldo de la misma manera, por lo que se desbordaba de forma idéntica y no detectaba nada anómalo. Una comprobación de saldo por cuenta solo falla cuando una única cuenta posee más que el suministro total; el ataque lo evitaba repartiendo los XRP acuñados entre cientos de cuentas. Por qué la corrección se saltó el proceso de enmiendas Los cambios en la forma en que el XRP Ledger procesa las transacciones se despliegan normalmente mediante un proceso de enmiendas, en el que una nueva regla permanece inactiva hasta que más del 80 % de los validadores de confianza la respalda durante dos semanas. RippleX omitió deliberadamente ese proceso por primera vez desde que se introdujo hace más de diez años, porque el exploit era barato, no requería acceso especial y podía acuñar XRP gastable. Como xrpld es de código abierto, una corrección publicada por la vía normal habría quedado visible pero aún explotable en la mainnet durante semanas. El atajo conllevaba su propio riesgo de una parada de la red por versiones mixtas, pero las transacciones normales nunca llegan al código vulnerable. Más del 80 % de los validadores de la UNL predeterminada ejecutaban la 3.4.1 el día de su lanzamiento, antes de que se publicara el código fuente. Qué implica para el suministro fijo de XRP El episodio subraya hasta qué punto la propuesta de valor de XRP depende de que su suministro sea demostrablemente finito. Los 100.000 millones de tokens se crearon en el lanzamiento, y las instituciones que construyen sobre el ledger consideran ese límite una garantía. El fallo existía desde que se escribió el actual motor de pagos en 2015; RippleX no encontró evidencia de que se haya explotado. La misma versión también corrigió un fallo de validación del envoltorio de transacciones Batch, que se activó en la mainnet el 9 de octubre. RippleX dijo que añadirá un paso de reverificación a su proceso de publicación para que cada hallazgo de seguridad marcado como corregido se vuelva a probar contra el candidato de versión. La divulgación se produce cuando el XRP Ledger sigue incorporando funciones institucionales, como la delegación de permisos para bancos y stablecoins, y la dinámica de suministro y escrow de XRP sigue en el foco de los tenedores.