El cliente de consenso de Ethereum Lighthouse lanzó un parche de seguridad el 9 de noviembre y urgió a los operadores de todos sus nodos baliza a actualizar lo antes posible.
La versión v8.3.3 hace que este trabajo sea una alta prioridad para los usuarios que stakean y para los que no lo hacen, pero el aviso de lanzamiento clasifica las actualizaciones del cliente de validador como baja prioridad para los usuarios que stakean.
Como un cliente de consenso, Lighthouse se conecta con otros clientes en la red de prueba de participación de Ethereum. Su nodo de baliza trabaja con un motor de ejecución para validar transacciones en bloques, mientras que el cliente de validador se conecta al nodo de baliza y gestiona claves, según el Lighthouse Book.
Los operadores también pueden ejecutar un nodo de baliza sin un cliente de validador. La documentación de Lighthouse incluye análisis de datos y aplicaciones entre estos usos no de staking, y esos operadores reciben las mismas instrucciones de alto prioridad para el nodo de baliza que los usuarios de staking en la tabla de actualización v8.3.3.
Las definiciones de prioridad del proyecto colocan el trabajo de alta prioridad en una escala de horas o días, para completarlo lo antes posible. El trabajo de baja prioridad se incluye en el próximo ciclo de actualización rutinaria, con dos semanas como ejemplo.
Elige tu configuración de Faro
Actualice el nodo de baliza de inmediato. La actualización del cliente de validador tiene baja prioridad y pertenece al ciclo rutinario.
Los nodos baliza con y sin staking tienen alta prioridad; los clientes validadores con staking pueden utilizar el ciclo de actualización habitual.
Los mecanismos de vulnerabilidad y el impacto potencial permanecen sin revelar. Alta prioridad describe la urgencia de la actualización. Horas o días y dos semanas son orientaciones ilustrativas de categoría, no fechas límite fijas. No se proporciona una fecha de publicación del aviso.
Los mantenedores indican que la v8.3.3 no introduce cambios ruptivos, pero aún así recomiendan a los usuarios que actualicen desde la v8.2.x o versiones anteriores que lean las notas de la versión v8.3.0, una consideración adicional para los operadores que han omitido versiones intermedias.
Los detalles de la vulnerabilidad del cliente de ethereum seguirán
El lanzamiento indica que los detalles técnicos de las vulnerabilidades se divulgarán más adelante. Los enlaces a los avisos de seguridad se agregarán una vez que los operadores de red hayan tenido tiempo para actualizar.
Ese enfoque sigue la explicación de Sigma Prime del 5 de noviembre sobre su proceso de divulgación. El desarrollador de Lighthouse dice que inicialmente retiene la información sobre vulnerabilidades para dar a los usuarios tiempo para actualizar sus nodos, luego agrega detalles a las notas de lanzamiento y a los avisos de seguridad de GitHub.
El aviso v8.3.3 no informa sobre explotación activa ni identifica pérdidas, y los mecanismos de ataque y el impacto potencial permanecen sin divulgar. La etiqueta de alta prioridad no revela la gravedad técnica ni las consecuencias de un ataque.
La solicitud es específica para el software beacon-node de Lighthouse. Para los operadores que ejecutan ambos componentes de Lighthouse, completar solo la actualización del validator-client aún dejaría pendiente la instrucción del beacon-node.
Verificar qué componente se está actualizando es clave, ya que las dos entradas en la tabla de lanzamiento tienen horarios diferentes. Los detalles retenidos también desmienten las afirmaciones de robo o una interrupción inminente de la cadena en este aviso.