Vijay Khanna, Director de Ingeniería de Ripple, instó a los operadores de nodos del XRP Ledger el 2 de agosto a instalar la versión 3.2.1 de xrpld después de que los desarrolladores observaran una inundación de manifiestos de validador el 31 de julio.
El parche urgente limita la forma en que los nodos procesan, almacenan y comparten los datos recibidos de identidades de validador desconocidas.
El XRP Ledger continuó cerrando libros contables normalmente durante el evento, según XRP Ledger Operations. La evidencia disponible, por lo tanto, apunta a una presión sobre los recursos de los nodos y las comunicaciones entre pares, en lugar de una pérdida confirmada de fondos, transacciones alteradas o un fallo en el consenso del libro contable. Los desarrolladores no han publicado un identificador CVE ni una estimación de pérdidas financieras relacionadas con el incidente.
Los manifiestos de validador son registros criptográficamente firmados que conectan la identidad maestra estable de un validador con la clave temporal que utiliza para los mensajes de validación diarios. Cuando los operadores rotan esas claves temporales, publican un nuevo manifiesto firmado por la clave maestra para que otros nodos puedan verificar el cambio.
Antes del parche urgente, los nodos podían aceptar, almacenar en caché y retransmitir manifiestos con una estructura válida asociados con claves de validador que no reconocían. Un atacante podría explotar ese comportamiento produciendo muchas identidades desconocidas y forzando a los pares a consumir memoria, almacenamiento, ancho de banda y capacidad de procesamiento para manejar los datos. El registro de código público describe la falla como un problema con la propagación de manifiestos.
El lanzamiento oficial de xrpld 3.2.1 está fechado el 31 de julio y fue publicado como la última versión firmada a principios del 1 de agosto. Contiene seis commits en 13 archivos modificados, incluyendo cuatro commits que restringen directamente el manejo de manifiestos no confiables.
La primera salvaguardia rechaza un manifiesto de validador de tamaño excesivo antes de que el nodo lo decodifique completamente. Esto reduce el trabajo de procesamiento que un atacante puede activar enviando objetos individuales más grandes de lo que el software espera.
La segunda limita el número de manifiestos no confiables transportados en un solo mensaje de red. El límite se aplica cuando los nodos reciben los datos y cuando preparan mensajes de manifiesto para los pares. Los lotes de tamaño excesivo se descartan sin desconectar automáticamente a un par sin parchear, lo que ayuda a que los nodos actualizados y los más antiguos permanezcan conectados durante el despliegue.
Un tercer cambio limita el número de identidades de validador desconocidas mantenidas en la caché de manifiestos de un nodo. El código final establece el máximo en 100. Una vez que se alcanza esa capacidad, el software rechaza los manifiestos vinculados a nuevas claves no listadas mientras continúa procesando validadores confiables o previamente reconocidos.
El parche también cambia cómo se retiene y propaga la información de manifiestos no confiables. Los datos de validador confiables permanecen disponibles porque las restricciones se dirigen al chismorreo de pares no listados en lugar de a los manifiestos de validadores configurados o aprobados. Esta distinción permite que la rotación normal de claves de validador continúe mientras se bloquea el crecimiento descontrolado de la caché.
Khanna aconsejó a los validadores y otros operadores de infraestructura que actualizaran a la versión 3.2.1 "lo antes posible". Sus instrucciones requieren una actualización de software normal, seguida de una espera de uno a dos minutos y una verificación de que xrpld esté ejecutándose. Los operadores deben reiniciar el servicio de nuevo.
El segundo reinicio es importante para los nodos que pueden haber retenido manifiestos desconocidos antes de instalar la corrección. La actualización cambia el manejo futuro, mientras que reiniciar el servidor corregido ayuda a asegurar que los datos antiguos en memoria o previamente retenidos no sigan afectando las operaciones.
Los operadores también pueden necesitar confirmar que sus sistemas confían en la clave de firma de paquetes actual de Ripple. Las notas de la versión indican que Ripple rotó la clave GPG utilizada para firmar paquetes xrpld el 18 de febrero. Las instalaciones existentes que no hayan confiado en la clave de reemplazo pueden no recibir actualizaciones automáticas con éxito.
La actualización se aplica a los proveedores de infraestructura en lugar de a los poseedores ordinarios de XRP. Los usuarios no necesitan mover XRP, cambiar claves de monedero o crear nuevas cuentas debido al problema del manifiesto. Las casas de cambio, los custodios, los sistemas de monederos, los proveedores de datos y las empresas que ejecutan sus propios servidores XRPL deben, en cambio, confirmar sus versiones de nodo y el estado de reinicio.
XRP Ledger Operations dijo que un "post-mortem" técnico "seguirá pronto". A partir del 2 de agosto, el proyecto no había publicado ese informe, por lo que la identidad del remitente, el volumen de manifiestos transmitidos y el uso exacto de recursos en los nodos afectados permanecen sin ser revelados.
El informe también debería aclarar cuándo los desarrolladores detectaron la actividad por primera vez, si algún nodo dejó de estar disponible y con qué rapidez los operadores adoptaron la versión 3.2.1. Aunque los libros contables continuaron cerrándose, una lenta adopción del parche podría dejar servidores individuales expuestos a nuevas inundaciones, incluso cuando el libro mayor compartido siga operativo.
El parche urgente llega poco después del despliegue de la versión 3.2.0, más grande, de XRPL. Ese lanzamiento, emitido el 15 de junio, renombró el servidor de referencia de rippled a xrpld e introdujo cambios de infraestructura que requerían que los operadores actualizaran el software y las configuraciones del servicio.
Como se informó anteriormente, la versión 3.2.0 inicialmente se propagó más rápido entre los validadores que en la red de nodos más amplia. La inundación de manifiestos añade una nueva razón para que los operadores restantes avancen más allá de ese lanzamiento e instalen la solución rápida.
Mientras tanto, en cobertura relacionada, David Schwartz movió su infraestructura XRPL a la versión 3.2.0 mientras los desarrolladores preparaban la red para las nuevas características de nombres de servidor y protocolo. Anteriormente, como informó crypto.news, los operadores de nodos también se enfrentaron a una fecha límite para la versión 3.1.3 vinculada a la activación de una enmienda.
Las próximas actualizaciones verificadas serán el post-mortem prometido y nuevos datos de adopción de software. Hasta entonces, la respuesta confirmada sigue limitada al lanzamiento 3.2.1, sus cuatro controles de manifiesto y la solicitud a los operadores para que completen el proceso de actualización y reinicio.
