manaswijaiswal/reproducing-connman-1.34CVE-2017-12865 exploit
Connection Manager
Copyright (C) 2007-2012 Intel Corporation. Todos los derechos reservados.
Las siguientes características están integradas en Connection Manager: - Infraestructura genérica de plugins - Abstracción de dispositivos y redes (con soporte básico de almacenamiento) - IPv4, IPv4-LL (enlace local) y DHCP - Detección de conflictos de direcciones IPv4 (ACD) según RFC 5227 - IPv6, DHCPv6 y túneles 6to4 - Enrutamiento avanzado y configuración de DNS - Proxy DNS integrado y caché inteligente - Inicios de sesión WISPr en hotspots y detección de portales integrados - Configuración de hora y zona horaria (manual y automática con NTP) - Manejo de proxy (manual y automático con WPAD) - Soporte de tethering (USB, Bluetooth y modo AP WiFi) - Manejo detallado de estadísticas (local y roaming)
Se pueden habilitar varios plugins para el soporte de redes: - Plugin Ethernet - Plugin WiFi con WEP40/WEP128 y WPA/WPA2 (personal y empresarial) - Plugin Bluetooth (usando BlueZ) - Plugin 2G/3G/4G (usando oFono)
También hay disponibles plugins con características adicionales: - Configuración de la interfaz de loopback - Manejo de proxy PACrunner - Soporte de autorización PolicyKit
Tenga en cuenta que cuando ConnMan se inicia, limpia todas las interfaces de red que se van a utilizar. Si esto no es deseado, las interfaces de red pueden ignorarse estableciendo NetworkInterfaceBlacklist en el archivo de configuración main.conf o usando la opción de línea de comandos -I.
Para compilar Connection Manager necesita los siguientes paquetes de software: - Compilador GCC - Biblioteca GLib - Biblioteca D-Bus - Biblioteca IP-Tables (para soporte de tethering) - Biblioteca GnuTLS (opcional) - PolicyKit (opcional) - readline (cliente de línea de comandos)
Para configurar ejecute: ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
Configure busca automáticamente todos los componentes y paquetes necesarios.
Para compilar e instalar ejecute: make && make install
Para un sistema funcional, deben habilitarse ciertas opciones de configuración:
--disable-ethernet
Deshabilitar el soporte para tarjetas de red Ethernet
Por defecto, el soporte de la tecnología Ethernet está integrado y
habilitado. Esta opción puede usarse para construir un daemon pequeño
para un sistema específico si no se requiere soporte Ethernet.
--disable-gadget
Deshabilitar el soporte para dispositivos USB Ethernet Gadget
Por defecto, el soporte de la tecnología USB Ethernet Gadget está integrado y
habilitado. Esta opción puede usarse para construir un daemon pequeño
para un sistema específico si no se requiere soporte USB Ethernet Gadget.
--disable-wifi
Deshabilitar el soporte para dispositivos WiFi
Por defecto, el soporte de la tecnología WiFi está integrado y
habilitado. Esta opción puede usarse para construir un daemon pequeño
para un sistema específico si no se requiere soporte WiFi.
Es seguro construir un daemon con soporte WiFi sin
wpa_supplicant en ejecución. El inicio de wpa_supplicant se
detecta automáticamente y es solo una dependencia de tiempo de ejecución. No
es necesario para compilar ConnMan.
--disable-bluetooth
Deshabilitar el soporte para dispositivos Bluetooth
Por defecto, el soporte de la tecnología Bluetooth está integrado y
habilitado. Esta opción puede usarse para construir un daemon pequeño
para un sistema específico si no se requiere soporte Bluetooth.
Es seguro construir un daemon con soporte Bluetooth sin
bluetoothd en ejecución. El inicio de bluetoothd se detecta automáticamente
y es solo una dependencia de tiempo de ejecución. No es necesario para
compilar ConnMan.
--disable-ofono
Deshabilitar el soporte para dispositivos celulares 2G/3G/4G
Por defecto, el soporte de la tecnología oFono está integrado y
habilitado. Esta opción puede usarse para construir un daemon pequeño
para un sistema específico donde no se usa oFono.
Es seguro construir un daemon con soporte oFono sin
ofonod en ejecución. El inicio de ofonod se detecta automáticamente
y es solo una dependencia de tiempo de ejecución. No es necesario para
compilar ConnMan.
--disable-dundee
Deshabilitar el soporte para dispositivos Bluetooth DUN
Por defecto, el soporte de la tecnología Bluetooth DUN (dundee) está
integrado y habilitado. Esta opción puede usarse para construir un
daemon pequeño para un sistema específico donde no se usa dundee.
Es seguro construir un daemon con soporte dundee y sin
dundee en ejecución. El inicio de dundee se detecta automáticamente
y es solo una dependencia de tiempo de ejecución. No es necesario para
compilar ConnMan.
--enable-iwd
Habilitar el soporte para Wireless daemon for Linux
El proyecto IWD no tiene un lanzamiento inicial hasta ahora,
por lo tanto, por defecto el soporte IWD no está habilitado.
Es seguro habilitar esta opción junto con el soporte WiFi.
--disable-pacrunner
Deshabilitar el soporte para el manejo de proxy PACrunner
Por defecto, el soporte PACrunner está integrado y habilitado. Esta
opción puede usarse para construir un daemon pequeño para un sistema
específico donde no se usa PACrunner.
Es seguro construir un daemon con soporte PACrunner y sin
daemon pacrunner. Detectará e iniciará un proceso PACrunner
si es necesario en tiempo de ejecución. Su presencia no es necesaria
para compilar ConnMan.
--disable-loopback
Deshabilitar la configuración del dispositivo de loopback
Para distribuciones con un sistema de inicio realmente mínimo y sin
scripts de red, esto puede encargarse de configurar el
dispositivo de loopback y habilitarlo.
Es seguro dejar esto seleccionado incluso si los scripts de red
están implementados. Detecta un dispositivo de loopback ya configurado
y lo deja tal como está.
--disable-wispr
Deshabilitar el soporte para inicios de sesión WISPr en hotspots
Para sistemas con requisitos de memoria realmente mínimos, esto
deshabilitará el soporte para inicios de sesión WISPr en hotspots. El código
para WISPr todavía se compilará en el daemon, pero su
requisito de GnuTLS para conexiones seguras se eliminará.
La falta de soporte GnuTLS reduce los requisitos de memoria
en aproximadamente un 30% y para sistemas que son más estacionarios y no
se conectan a hotspots, esto podría ser un mejor equilibrio.
Deshabilitar el soporte WISPr no deshabilita el soporte de detección
de portales. Un portal todavía se detectará, pero en lugar de
solicitar credenciales de inicio de sesión, la solicitud de una sesión de navegador
se realizará a través del agente.
--enable-polkit
Habilitar el soporte para autorización PolicyKit
Esto permite verificar cada acceso D-Bus contra una política
de seguridad y así restringir el acceso a ciertas funcionalidades.
--enable-nmcompat
Habilitar el soporte para interfaces de compatibilidad con NetworkManager
Esto permite exponer un conjunto mínimo de interfaces de
NetworkManager. Es útil para sistemas con aplicaciones
escritas para usar NetworkManager y detectar el estado
en línea/desconectado que aún no se han convertido para usar ConnMan.
--disable-client
Deshabilitar el soporte para el cliente de línea de comandos
Por defecto, el cliente de línea de comandos está habilitado y usa la
biblioteca readline. Para sistemas específicos donde ConnMan se
configura por otros medios, el cliente de línea de comandos puede
deshabilitarse y se elimina la dependencia de readline.
--enable-selinux
Habilitar el soporte para compilar reglas de aplicación de tipo SElinux
Las reglas TE son necesarias si el entorno del host está en modo
de aplicación (enforcing). Sin esta opción, el proceso del cliente VPN no puede
enviar notificaciones a connman-vpnd a través de la interfaz net.connman.Task.
El módulo compilado connman-task.pp también debe
instalarse usando este comando
# semodule -i connman-task.pp
para habilitar el acceso dbus.
--with-dns-backend=TYPE
Habilitar el soporte para un backend de resolución DNS
Seleccione un backend DNS a usar. Los valores admitidos son "internal"
y "systemd-resolved". Si se selecciona "internal", ConnMan
se construirá con un proxy DNS con caché. Si se selecciona "systemd-resolved",
ConnMan configura systemd-resolved para realizar la resolución
DNS. El valor predeterminado es "internal".
Se pueden activar las impresiones de depuración en ConnMan usando la opción de línea de comandos -d. Si la opción -d no tiene parámetros, la depuración se activa para todos los archivos de código fuente. Si la opción -d tiene parámetros, indican qué archivos de código fuente tienen la depuración activada. Se pueden usar comodines en los nombres de archivo. Ejemplo: -d Activar todas las impresiones de depuración normales -d src/service.c Esto imprime información de depuración solo del archivo src/service.c -d src/network.c:src/ipconfig.c Esto activa las impresiones de depuración en los archivos src/network.c y src/ipconfig.c. -d 'src/n*.c' Esto activaría la impresión de depuración de todos los archivos fuente C que comiencen con la letra 'n' en el directorio src. Observe las comillas alrededor de la opción, para evitar la expansión del shell. -d '/n.c:/i.c' Activa las impresiones de depuración para todos los archivos fuente C que comiencen con las letras 'n' o 'i' en cualquier subdirectorio.
Algunos componentes de ConnMan tienen impresiones de depuración activadas por variables de entorno. Si la variable de entorno está establecida, el componente correspondiente imprimirá alguna información de depuración adicional. Se pueden usar las siguientes variables de entorno: CONNMAN_DHCP_DEBUG Información de depuración relacionada con DHCPv4 CONNMAN_DHCPV6_DEBUG Información de depuración relacionada con DHCPv6 CONNMAN_IPTABLES_DEBUG Información adicional cuando se usa iptables CONNMAN_RESOLV_DEBUG Impresiones de depuración del resolutor de nombres. Estas impresiones de depuración se usan cuando ConnMan resuelve nombres de host para su propio uso. Tenga en cuenta que las impresiones de depuración del proxy DNS no usan esta variable de entorno. Para eso, se puede usar la opción de línea de comandos "-d src/dnsproxy.c". CONNMAN_SUPPLICANT_DEBUG Impresiones de depuración para la comunicación entre los procesos connmand y wpa_supplicant. CONNMAN_WEB_DEBUG Información de depuración cuando ConnMan realiza la verificación de conectividad a Internet en los componentes Wispr y 6to4.
Ejemplo: CONNMAN_WEB_DEBUG=1 src/connmand -n
Si las condiciones de tiempo son relevantes, se recomienda el comando para obtener trazas de registro de la siguiente manera: connmand -d 2>&1 | ts '[%H:%M:%.S]' | tee connman.log
El programa 'ts' normalmente está disponible en el paquete moreutils.
Para admitir tethering, las siguientes opciones de configuración del kernel deben habilitarse ya sea como módulos (m) o integradas (y):
CONFIG_BRIDGE CONFIG_IP_NF_TARGET_MASQUERADE
Para habilitar CONFIG_IP_NF_TARGET_MASQUERADE, las siguientes opciones también deben habilitarse como módulos (m) o integradas (y):
CONFIG_NETFILTER CONFIG_NF_CONNTRACK_IPV4 CONFIG_NF_NAT_IPV4
Para el soporte de enrutamiento y estadísticas en Sesiones, las siguientes opciones deben habilitarse como módulos (m) o integradas (y):
CONFIG_IP_NF_IPTABLES CONFIG_IP_MULTIPLE_TABLES CONFIG_NETFILTER_NETLINK_ACCT CONFIG_NETFILTER_XT_MATCH_NFACCT CONFIG_NETFILTER_XT_CONNMARK CONFIG_NETFILTER_XT_TARGET_CONNMARK CONFIG_NETFILTER_XT_MATCH_CONNMARK
Para admitir tethering por USB gadget, las siguientes opciones de configuración del kernel deben habilitarse:
CONFIG_USB_GADGET CONFIG_USB_ETH
Para que wpa_supplicant y Connection Manager funcionen correctamente juntos, debe editar el archivo .config de wpa_supplicant y establecer:
CONFIG_WPS=y CONFIG_AP=y CONFIG_CTRL_IFACE_DBUS_NEW=y
agregue:
CONFIG_BGSCAN_SIMPLE=y
Esta última opción habilitará el soporte de escaneo en segundo plano mientras se está conectado, lo cual es necesario al hacer roaming en wifi.
Se recomienda usar wpa_supplicant 2.x o posterior.
Si wpa_supplicant está configurado para el autoinicio de D-Bus, entonces ConnMan activará el autoinicio de wpa_supplicant. Sin embargo, tenga en cuenta que este disparador solo ocurre una vez. Si wpa_supplicant se detiene o falla, ConnMan no intenta reiniciarlo automáticamente periódicamente. Depende de systemd o una herramienta similar de gestión de servicios reiniciarlo automáticamente. En caso de que wpa_supplicant no sea iniciado por ConnMan, asegúrese de que se use la opción "-u" para habilitar su interfaz de control D-Bus y garantizar que ConnMan pueda comunicarse con él.
Para compilar los plugins VPN pptp y l2tp, necesita el paquete de desarrollo de ppp.
Para ejecutar l2tp necesitará - xl2tpd, http://www.xelerance.com/services/software/xl2tpd
Para ejecutar pptp necesitará - cliente pptp, http://pptpclient.sourceforge.net
Tanto l2tp como pptp también necesitan pppd.
Hasta la versión 2.2 de OpenVPN, el envío de rutas adicionales desde el servidor no siempre funcionará. Algunos de los síntomas son que las rutas adicionales no serán establecidas por ConnMan si el enlace ascendente es una red celular. Mientras que la misma configuración funciona bien para un enlace ascendente WiFi o ethernet.
Hasta (al menos) la versión 2.4.5 de OpenVPN, falta la obtención de información sobre fallos de descifrado de claves privadas a través del canal de administración. Esto resultará en intentos repetidos con la clave inválida una y otra vez, ya que la información sobre el descifrado fallido no se entrega al plugin OpenVPN. Se requiere el siguiente parche para OpenVPN para que se envíen los fallos de descifrado de la clave privada: https://git.sailfishos.org/mer-core/openvpn/blob/ 4f4b4af116292a207416c8a990392e35a6fc41af/rpm/privatekey-passphrase- handling.diff
Al usar GnuTLS, tenga en cuenta que dependiendo de la configuración de GnuTLS se realiza una inicialización perezosa o eager de un grupo de entropía interno usando /dev/urandom. En la inicialización eager, la carga de ConnMan será retrasada por el cargador de enlaces hasta que el grupo de entropía se llene. En sistemas más pequeños, esto puede fácilmente retrasar el inicio de ConnMan por varios segundos (hemos recibido informes de 25 segundos o más de retraso).
GnuTLS permite volver a la evaluación perezosa cuando la variable de entorno GNUTLS_NO_EXPLICIT_INIT. Para más detalles, lea la página del manual de gnutls_global_init(3).
ConnMan intenta detectar si tiene conexión a Internet o no cuando un servicio está conectado. Si la verificación en línea tiene éxito, el servicio pasa al estado En línea (Online); si no, permanece en el estado Listo (Ready). La verificación en línea también se usa para detectar si ConnMan está detrás de un portal cautivo, como cuando estás en un hotel y necesitas pagar por la conectividad.
La verificación en línea se realiza intentando obtener el documento status.html de ipv4.connman.net (para conectividad IPv4) e ipv6.connman.net (para conectividad IPv6). La URL utilizada se ve así http://ipv{4|6}.connman.net/online/status.html
La verificación en línea opera en uno de tres modos:
donde "one-shot" es el predeterminado y está gobernado por el ajuste "OnlineCheckMode".
En el modo "none", no hay verificaciones de accesibilidad a Internet "en línea" basadas en HTTP. Cualquier servicio conectado y el estado del administrador terminarán en el estado Ready y no progresarán a Online.
En "one-shot", el modo predeterminado, hay una única verificación de accesibilidad a Internet "en línea" basada en HTTP para el servicio predeterminado (es decir, el servicio con la ruta predeterminada de puerta de enlace de alta prioridad (métrica 0)). Cuando la verificación tiene éxito, el servicio asociado y el estado del administrador terminarán en el estado "online". Cuando la verificación falla, las verificaciones posteriores se reprogramarán según "OnlineCheckIntervalStyle", "OnlineCheckInitialInterval" y "OnlineCheckMaxInterval" y continuarán indefinidamente hasta que una tenga éxito o hasta que el servicio se desconecte.
En el modo "continuous", hay verificaciones continuas de accesibilidad a Internet "en línea" basadas en HTTP para el servicio predeterminado (es decir, el servicio con la ruta predeterminada de puerta de enlace de alta prioridad (métrica 0)). Al igual que con el modo "one-shot", cuando la primera verificación tiene éxito, el servicio asociado y el estado del administrador terminarán en el estado Online. A partir de entonces, las verificaciones posteriores se programarán según "OnlineCheckIntervalStyle" y "OnlineCheckMaxInterval". Cuando la verificación falla, las verificaciones posteriores se reprogramarán según "OnlineCheckIntervalStyle", "OnlineCheckInitialInterval" y "OnlineCheckMaxInterval". Cuando y si se alcanza "OnlineCheckFailuresThreshold", el estado del servicio y del administrador se degradará a Ready y el servicio tendrá su propiedad "Error" establecida en "online-check-failed" mientras las verificaciones posteriores continúan. Mientras tanto, si está disponible, otro servicio puede ser promovido a servicio predeterminado y se iniciarán verificaciones en línea para él. Cuando y si, para el servicio degradado, se alcanza "OnlineCheckSuccessesThreshold", la propiedad "Error" del servicio se limpiará y el estado del servicio se promoverá a Online, lo que potencialmente puede hacer que vuelva a convertirse en el servicio predeterminado.
Consulte connman.conf(5) para la opción "OnlineCheckMode", si necesita deshabilitar la función. También es posible especificar otras URL mediante las opciones "OnlineCheckIPv4URL" y "OnlineCheckIPv6URL". El rango de intervalos entre dos solicitudes de verificación en línea se puede ajustar finamente mediante las opciones "OnlineCheckInitialInterval" y "OnlineCheckMaxInterval", así como con la opción "OnlineCheckIntervalStyle".
Como se insinuó anteriormente, para los modos "one-shot" y "continuous", cuando una solicitud de verificación en línea falla (o, en el caso del modo "continuous", también tiene éxito), se activa otra después de un intervalo más largo. Los intervalos siguen una de dos secuencias matemáticas, dependiendo del ajuste "OnlineCheckIntervalStyle": "fibonacci" o "geometric", con un valor predeterminado de "geometric". El ajuste geométrico es la serie cuadrada de números en el rango especificado por "OnlineCheckInitialInterval" y "OnlineCheckMaxInterval". Los valores predeterminados para "OnlineCheckInitialInterval" y "OnlineCheckMaxInterval" son el rango [1, 12], que corresponden a los siguientes intervalos "geométricos", en segundos: 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121 y 144 en ese rango. Por el contrario, la secuencia "fibonacci" correspondiente en ese rango es 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 y 144. La serie y el estilo "fibonacci" son más agresivos en la tasa de verificación hasta 12 pasos (su punto de equivalencia con "geometric" en 144 segundos) que "geometric", pero retroceden mucho más agresivamente más allá de ese punto, alcanzando una hora en el intervalo 19, que "geometric" no alcanza hasta el intervalo 60.
Durante el procedimiento de verificación en línea, ConnMan instalará temporalmente una ruta de host tanto para ipv4.connman.net como para ipv6.connman.net para que la consulta de verificación en línea pueda dirigirse a través de la interfaz de red correcta que está utilizando el servicio conectado. Esta ruta de host se elimina automáticamente cuando termina la verificación en línea. Tenga en cuenta que el servidor explícitamente no registra ninguna información de conexión, incluidas las direcciones IPv4/6 de los clientes que se conectan. Los registros de tiempo de ejecución del servidor ciclan en la memoria RAM dependiendo de la cantidad de conexiones procesadas.
ConnMan envía esta información muy mínima en el encabezado http al hacer la solicitud de verificación en línea (ejemplo): Host: ipv4.connman.net User-Agent: ConnMan/1.23 wispr Connection: close
Actualmente, se devuelve la siguiente información desde connman.net si la conexión es exitosa (se devuelve el código de respuesta http 200 OK): Server: nginx Date: Mon, 09 Jun 2014 09:25:42 GMT Content-Type: text/html Connection: close X-ConnMan-Status: online
El campo X-ConnMan-Status se usa en la detección de portales; si falta, ConnMan llamará al método RequestBrowser en la interfaz dbus net.connman.Agent para manejar el inicio de sesión del portal si el portal no soporta WISPr. Consulte doc/agent-api.txt para más detalles.
Lista de correo: [email protected]
Si desea suscribirse para recibir correo en su bandeja de entrada, simplemente envíe un mensaje (vacío) desde su cuenta de correo a
Archivo de la lista de correo: https://lore.kernel.org/connman
IRC: ircs://irc.oftc.net:6697/#connman (para SSL) irc://irc.oftc.net:6667/#connman (para no SSL)