Los desarrolladores de XRP Ledger han divulgado y corregido una vulnerabilidad crítica que, de no haberse atendido, podría haber permitido a un atacante crear XRP de la nada, una falla que permaneció latente en el código de la red durante aproximadamente una década.

En una divulgación publicada el viernes, los encargados de mantener el ledger informaron que un investigador reportó el bug en septiembre a través del programa de bug bounty de XRPL. El problema era un desbordamiento de enteros en el motor de pagos, el componente del software responsable de procesar los pagos.

La falla aritmética se manifestaba solo bajo condiciones inusuales. Cuando un solo pago consumía cientos de ofertas especialmente manipuladas del libro de órdenes, la suma de lo que el comprador debía superaba el valor máximo que el sistema podía almacenar y "daba la vuelta" a un número minúsculo. El motor pagaba a cada vendedor en su totalidad, pero cobraba al comprador casi nada, y la diferencia equivalía a XRP recién acuñado que nunca debió existir.

Empeorando la situación, la verificación de seguridad integrada del ledger, diseñada para confirmar que ninguna transacción crea XRP, dependía de la misma aritmética defectuosa. Daba la vuelta de manera idéntica y no detectaba nada. Según los encargados del mantenimiento, un atacante podría haber creado XRP gastable muy por encima del suministro total del token en una sola transacción, para luego moverlo, comercializarlo o enviarlo a exchanges. Esa verificación es el mecanismo en el que confía el ledger para garantizar que ninguna transacción pueda acuñar nuevo XRP, y falló en silencio junto con el mismo código que debía supervisar.

Los ingenieros de RippleX confirmaron que el bug estaba presente desde que el motor de pagos actual fue escrito en 2015. Pasó desapercibido porque ningún pago ordinario se acerca siquiera a activar el desbordamiento, y no hay evidencia de que haya sido explotado, según el equipo.

La corrección se publicó en la versión 3.4.1 el 25 de septiembre, y más del 80% de los validadores de confianza de la red ya la estaban ejecutando ese mismo día. Cabe destacar que el parche omitió el proceso habitual de enmiendas del ledger, que exige que los validadores voten y esperen dos semanas antes de que un cambio entre en vigor. Fue la primera vez que un cambio en el procesamiento de transacciones se implementó deliberadamente de esa manera desde que el sistema se introdujo hace más de una década. Los encargados del mantenimiento indicaron que la gravedad justificaba la excepción, ya que publicar la corrección de código abierto habría revelado el bug dejándolo explotable durante semanas. Con la falla ahora pública, cualquier validador que aún use una versión anterior tiene tanto la razón como el remedio a mano: actualizar a la 3.4.1 elimina la aritmética defectuosa del procesamiento de pagos de ese nodo.

La divulgación recuerda al susto de falsificación que sacudió a Zcash a principios de este año, cuando la moneda de privacidad se apresuró a corregir un bug de solidez en su shielded pool que podría haber permitido acuñar monedas falsificadas. Ese episodio hizo desplomarse a ZEC antes de que la actualización Ironwood de la red lo resolviera. Ambos incidentes apuntaban al mismo tipo de garantía: que el activo de una blockchain pueda fabricarse de la nada, por más ingeniosamente que se construya una transacción.

XRP no escapó indemne de la semana. El token cotizaba a $1.38 el lunes, con una caída de 1.6% en 24 horas, el peor desempeño entre las principales criptomonedas, y una baja de 9.4% en los últimos siete días.