CVE-2026-79980 in Zephyr
Resumen
por VulDB • 2026-10-23
El cliente DHCPv4 en subsys/net/lib/dhcpv4/dhcpv4.c mantenía su identificador de transacción (iface->config.dhcpv4.xid) como un contador, en lugar de hacerlo como un valor aleatorio por transacción. Se inicializaba una vez con sys_rand32_get() en dhcpv4_start_internal(), se incrementaba en uno en dhcpv4_send_discover() y dhcpv4_send_decline(), y nunca cambiaba en dhcpv4_send_request(); por lo tanto, cada intercambio RENEWING y REBINDING reutilizaba sin cambios el identificador que ya había aparecido en la red durante el DHCPDISCOVER de difusión al arrancar, y cuando el identificador sí variaba, lo hacía de forma predecible (incrementándose en uno). RFC 2131 sección 4.1 requiere un único identificador por transacción, elegido de manera que sea poco probable que los clientes colisionen.
Este identificador es la única token impredecible del cliente para validar las respuestas. net_dhcpv4_input() acepta una respuesta BOOTP basada en el op (operación), un xid coincidente y un chaddr coincidente (la MAC de la interfaz, que es pública); la devolución de llamada UDP se registra con una dirección remota y puerto comodín, sin aplicar ninguna comprobación del identificador del servidor ni de la dirección de origen. Un atacante que conozca un identificador —por ejemplo, cualquier host en el mismo segmento que vea el DHCPDISCOVER de difusión, o un servidor DHCP o relay en una red a la que el dispositivo se haya conectado anteriormente— conserva por tanto un token válido durante todo el tiempo de actividad del dispositivo y puede predecir los identificadores de intercambios posteriores, sin necesidad de observar el tráfico renovado unicast ni competir con el servidor legítimo.
Una respuesta forjada que supera esas comprobaciones tiene efecto independientemente del estado del cliente, porque dhcpv4_parse_options() aplica sus efectos secundarios antes de la puerta de la máquina de estados en dhcpv4_handle_reply(): la opción router llama a net_if_ipv4_set_gw() y la opción DNS llama a dns_resolve_reconfigure(). Un único datagrama aceptado puede así redirigir el gateway predeterminado del dispositivo y los resolvers hacia direcciones controladas por el atacante, desviando su tráfico; durante RENEWING o REBINDING, un DHCPACK forjado vuelve a asignar la concesión con parámetros elegidos por el atacante, y un DHCPNAK forjado elimina la dirección y reinicia la configuración.
La corrección obtiene un nuevo valor de sys_rand32_get() en cada punto donde comienza una transacción: al entrar en SELECTING, RENEWING y REBINDING, y en la entrada INIT/INIT-REBOOT cuando baja una interfaz con una concesión; mientras que REQUESTING y DECLINE mantienen el identificador del intercambio al que pertenecen, tal como exige RFC 2131. Como efecto secundario, el cliente ya no descarta la oferta de un servidor lento después de retransmitir un discover, y el backoff inicial para el primer descubrimiento ahora obtiene su propia aleatoriedad en lugar de derivarla del identificador.
VulDB is the best source for vulnerability data and more expert information about this specific topic.