El XRP Ledger corrigió una falla de hace una década que permitía crear XRP por encima de su suministro fijo; no hay evidencia de que se haya explotado

Los desarrolladores publicaron el 9 de octubre el informe de un desbordamiento de enteros en el motor de pagos, presente probablemente desde 2015. Lo reportaron Cayden Liao y Veria AI el 22 de septiembre; la corrección llegó con xrpld 3.4.1 y los servidores sin actualizar quedaron bloqueados.

Los desarrolladores del XRP Ledger, la red de la criptomoneda XRP, publicaron el viernes 9 de octubre un informe de divulgación de vulnerabilidades que detalla una falla crítica en el motor de pagos que permitía crear XRP «muy por encima del suministro total» en una sola transacción validada. El error, presente probablemente desde que se escribió ese motor en 2015, fue corregido con la versión 3.4.1 del software de los servidores de la red (xrpld), lanzada el 25 de septiembre. Según la cuenta XRPL Operations, no hay evidencia de que haya sido explotado en ninguna red pública.

El XRP tiene un suministro fijo de 100.000 millones de unidades. La falla habría permitido generar XRP gastable por fuera de ese tope.

Cómo funcionaba la falla

De acuerdo con el informe, el problema estaba en la suma de las ofertas del libro de órdenes, que usaba una suma de enteros de 64 bits sin control de desbordamiento. Un pago que consumía muchas ofertas con precios preparados especialmente hacía que el total «diera la vuelta» y quedara convertido en un número chico: los dueños de las ofertas cobraban sus montos completos, pero al comprador sólo se le descontaba la cifra desbordada. La diferencia era XRP creado de la nada.

El control que debía impedirlo —un «invariante» que la red verifica en cada transacción para asegurar que no se cree XRP— usaba la misma aritmética sin control, así que tampoco lo detectaba; y el chequeo de saldos por cuenta no lo veía porque el XRP generado se repartía entre cientos de cuentas. El costo real para un atacante habría sido de unos cientos de XRP en reservas, que se recuperan al eliminar los objetos creados, más las comisiones habituales.

Quién la encontró y cómo se corrigió

La falla la reportaron Cayden Liao y Veria AI a través del programa de recompensas por errores (bug bounty) del XRP Ledger el 22 de septiembre, con una calificación inicial de «mayor». RippleX, el área de desarrollo de Ripple, la reprodujo al día siguiente y la elevó a «crítica». La corrección, desarrollada y revisada entre el 22 y el 23 de septiembre, agrega controles de desbordamiento en la suma de ofertas y en la combinación de resultados de distintos caminos de pago, y amplía el contador que usa el invariante.

Por su gravedad, el arreglo se distribuyó como un cambio directo de código, sin pasar por el mecanismo de enmiendas que votan los validadores, de modo que entró en vigor a medida que cada servidor se actualizaba. Según el informe, más del 80% de los validadores de la lista por defecto (UNL) ya corrían la versión 3.4.1 el día de su lanzamiento. Los desarrolladores pidieron a todos los operadores actualizar a 3.4.1 o posterior: los servidores más viejos quedaron bloqueados (amendment-blocked) y no pueden seguir sincronizados con la red.

Un segundo error, en las transacciones Batch

El mismo informe documenta un segundo fallo, de menor gravedad, en la validación de las transacciones internas de la función Batch, que agrupa varias operaciones en una. Fue detectado en un «Attackathon» de Sherlock y no implicó pérdida de fondos, pero si Batch se hubiera activado sin corregir, servidores con distintas versiones podían discrepar sobre la validez de una transacción y frenar la validación de la red. Ripple y otros validadores retiraron su voto a la enmienda BatchV1_1 hasta que la corrección (fixBatchV1_2) reunió apoyo; ambas se activaron en la red principal el 9 de octubre, el mismo día en que se publicó el informe.

Por qué importa

El tope fijo de suministro es una de las garantías básicas de una criptomoneda: una falla que permitiera emitir unidades sin control afectaría el valor de todas las tenencias y la confianza en una red que Ripple promueve para pagos transfronterizos y tokenización de activos, como el registro de cuotas de fondos que el depositario brasileño CSD BR lleva al XRP Ledger. Que el error haya sobrevivido una década en el código pone en valor los programas de recompensas: los desarrolladores anunciaron que agregarán a cada lanzamiento un paso para volver a probar cada hallazgo corregido sobre la versión candidata. Qué sigue: la actualización de los servidores que todavía no migraron y el funcionamiento de Batch en la red principal.

Fuentes: XRPL.org — Vulnerability Disclosure Report for xrpld 3.4.1, GitHub — xrpld 3.4.1, XRPL Operations en X, Bitcoin.com News, The Defiant.