El director de ingeniería de Ripple, Vijay Khanna, 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 validadores el 31 de julio.
Resumen
- La inundación de manifiestos del 31 de julio provocó xrpld 3.2.1 mientras el XRP Ledger continuaba cerrando libros de contabilidad normalmente durante todo el incidente.
- Cuatro salvaguardas ahora limitan el tamaño de los manifiestos, los lotes de mensajes, el intercambio saliente y el crecimiento de la caché de claves desconocidas en toda la red.
- Los operadores deben actualizar, verificar que xrpld esté ejecutándose y luego reiniciar nuevamente para limpiar los manifiestos persistidos de manera segura.
El parche de emergencia limita cómo los nodos procesan, almacenan y comparten datos recibidos de identidades de validadores desconocidas.
El XRP Ledger continuó cerrando libros de contabilidad normalmente durante el evento, según XRP Ledger Operations. Por lo tanto, la evidencia disponible apunta a presión sobre los recursos de los nodos y las comunicaciones entre pares, más que a una pérdida confirmada de fondos, transacciones alteradas o fallo del consenso del libro de contabilidad. Los desarrolladores no han publicado un identificador CVE ni una estimación de pérdidas financieras relacionadas con el incidente.
XRPL 3.2.1 limita la ruta de inundación de manifiestos
Los manifiestos de validadores son registros firmados criptográficamente 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 con la clave maestra para que otros nodos puedan verificar el cambio.
Antes del parche de emergencia, los nodos podían aceptar, almacenar en caché y reenviar manifiestos con estructura válida asociados con claves de validadores que no reconocían. Un atacante podría explotar ese comportamiento produciendo muchas identidades desconocidas y forzando a los pares a gastar memoria, almacenamiento, ancho de banda y capacidad de procesamiento para manejar los datos. El registro público del código describe la falla como un problema con la propagación de manifiestos.
La versión oficial de xrpld 3.2.1 está fechada el 31 de julio y se publicó como la última versión firmada a principios del 1 de agosto. Contiene seis confirmaciones en 13 archivos modificados, incluidas cuatro confirmaciones que restringen directamente el manejo de manifiestos no confiables.
Cuatro salvaguardas reducen el riesgo de agotamiento de recursos
La primera salvaguarda rechaza un manifiesto de validador de tamaño excesivo antes de que el nodo lo decodifique por completo. Eso reduce el trabajo de procesamiento que un atacante puede desencadenar 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 validadores 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 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 validadores confiables permanecen disponibles porque las restricciones apuntan a los chismes de pares no listados en lugar de manifiestos de validadores configurados o aprobados. Esta distinción permite que la rotación normal de claves de validadores continúe mientras bloquea el crecimiento descontrolado de la caché.
Los operadores de nodos deben completar un segundo reinicio
Khanna aconsejó a los validadores y otros operadores de infraestructura que actualicen 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. Luego, los operadores deben reiniciar el servicio nuevamente.
El segundo reinicio es importante para los nodos que puedan 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 garantizar que los datos antiguos en memoria o retenidos previamente 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 los paquetes de 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, no a los tenedores ordinarios de XRP. Los usuarios no necesitan mover XRP, cambiar claves de billetera o crear nuevas cuentas debido al problema de manifiesto. Los intercambios, custodios, backends de billeteras, proveedores de datos y empresas que ejecutan sus propios servidores XRPL deben, en cambio, confirmar sus versiones de nodo y estado de reinicio.
El informe post-mortem determinará el alcance del incidente
XRP Ledger Operations dijo que un "post-mortem técnico seguirá pronto". Hasta el 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 siguen sin revelarse.
El informe también debería aclarar cuándo los desarrolladores detectaron por primera vez la actividad, si algún nodo se volvió no disponible y con qué rapidez los operadores adoptaron la versión 3.2.1. Aunque los libros de contabilidad continuaron cerrándose, la adopción lenta de parches podría dejar a servidores individuales expuestos a inundaciones renovadas incluso cuando el libro de contabilidad compartido sigue operativo.
La corrección llega poco después del lanzamiento de la versión más grande 3.2.0 de XRPL. Esa versión, emitida el 15 de junio, renombró el servidor de referencia de rippled a xrpld e introdujo cambios de infraestructura que requirieron que los operadores actualizaran el software y las configuraciones de servicio.
Como se informó anteriormente, la versión 3.2.0 inicialmente se extendió más rápido entre los validadores que en la red de nodos más amplia. La inundación de manifiestos agrega una nueva razón para que los operadores restantes vayan más allá de esa versión e instalen la corrección.
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 el nuevo nombre del servidor y las características del protocolo. Anteriormente, como informó crypto.news, los operadores de nodos también enfrentaron una fecha límite de la versión 3.1.3 vinculada a una activación de enmienda.
Las próximas actualizaciones verificadas serán el post-mortem prometido y los nuevos datos de adopción de software. Hasta entonces, la respuesta confirmada se limita a la versión 3.2.1, sus cuatro controles de manifiesto y la solicitud de que los operadores completen el proceso de actualización y reinicio.
