Un error de una década en XRP Ledger habría permitido crear XRP sin respaldo

XRP Ledger (XRPL) publicó el 9 de octubre un informe de divulgación sobre un error en el motor de pagos de xrpld que, según el documento, permitía crear XRP sin respaldo. La falla fue reportada el 22 de septiembre mediante el programa de recompensas por errores y corregida en la versión 3.4.1, lanzada el 25 de septiembre.

XRPL sostiene que el problema era un desbordamiento de enteros. Cuando un solo pago consumía cientos de ofertas del libro de órdenes, la suma superaba el máximo de un entero de 64 bits y se reiniciaba a un valor pequeño.

Según el informe, el motor pagaba a cada dueño de oferta su monto completo, pero cobraba al comprador solo el total reducido. La diferencia era XRP nuevo que podía gastarse como cualquier otro.

De acuerdo con XRPL, el ataque exigía crear unos cientos de cuentas, cada una con una oferta que vendía una cantidad mínima de un token a cambio de un monto muy alto de XRP. Luego, otra cuenta enviaba un pago que las consumía todas. Cada oferta era válida por separado, y el costo estimado eran unos cientos de XRP en reservas recuperables, más comisiones.

Por qué los controles no lo detectaron

El informe explica que el invariante que verifica que ninguna transacción cree XRP sumaba los cambios con el mismo tipo de contador. Se desbordaba de la misma forma, de modo que el cambio neto parecía solo la comisión, como en una transacción normal.

El control por cuenta tampoco actuó. Según XRPL, solo falla si una cuenta supera el suministro total de XRP, y repartir el monto entre cientos de cuentas mantenía cada saldo bajo ese límite.

La organización indica que el error existiría desde que se escribió el motor de pagos actual, en 2015, y que el invariante se añadió dos años después sobre la misma aritmética. Ningún pago normal se acerca a ese desbordamiento, según el documento, por lo que pasó inadvertido cerca de una década.

Un parche sin votación de validadores

XRPL señala que la corrección se desplegó sin pasar por el proceso de enmiendas, en el que los validadores votan y la regla se activa tras dos semanas con más del 80 % de apoyo. Según la organización, es la primera vez que un cambio de procesamiento de transacciones se publica así desde que existe ese sistema.

El informe argumenta que publicar el código con semanas de antelación habría dejado el error visible y explotable en Mainnet. Añade que más del 80 % de los validadores de la lista de nodos única por defecto ya usaba la versión 3.4.1 el día del lanzamiento, aunque el código del parche aún no era público.

XRPL es la red de código abierto en la que circula XRP. Su software lo mantienen RippleX y la XRPL Foundation, entidades que, según el informe, participaron junto con validadores en la decisión. Su posición importa porque la medida alteró el procedimiento habitual de cambios del protocolo.

Un segundo error, en Batch

El mismo documento describe una falla en la validación de transacciones internas de Batch (XLS-56), reportada el 18 de septiembre. Afectaba a la enmienda BatchV1_1, que no estaba activa en Mainnet, por lo que XRPL afirma que no hubo impacto en fondos.

Según el informe, el riesgo era una detención de la validación de ledgers en una red con versiones mezcladas. Ripple y otros validadores retiraron sus votos para reiniciar el plazo de activación, y la corrección, fixBatchV1_2, se activó el 9 de octubre junto con BatchV1_1.

XRPL advierte que omitir las enmiendas solo se justifica en fallas cuyo efecto sea peor que una detención de la red, y que este caso no cambia cómo se modifica el protocolo. La organización agregará a su proceso de lanzamiento una prueba que reproduzca cada hallazgo marcado como corregido antes de cerrarlo.