manaswijaiswal/reproducing-connman-1.34CVE-2017-12865 exploit
Connection Manager
Copyright (C) 2007-2012 Intel Corporation. Todos os direitos reservados.
As seguintes funcionalidades estão integradas no Connection Manager: - Infraestrutura genérica de plugins - Abstração de dispositivos e redes (com suporte básico de armazenamento) - IPv4, IPv4-LL (link-local) e DHCP - Deteção de conflito de endereços IPv4 (ACD) conforme RFC 5227 - IPv6, DHCPv6 e túneis 6to4 - Roteamento avançado e configuração de DNS - Proxy DNS integrado e cache inteligente - Logins integrados em hotspots WISPr e deteção de portal - Configuração de hora e fuso horário (manual e automática com NTP) - Gestão de proxy (manual e automática com WPAD) - Suporte a tethering (USB, Bluetooth e modo AP WiFi) - Estatísticas detalhadas (casa e roaming)
Vários plugins podem ser ativados para suporte de rede: - Plugin Ethernet - Plugin WiFi com WEP40/WEP128 e WPA/WPA2 (pessoal e empresarial) - Plugin Bluetooth (usando BlueZ) - Plugin 2G/3G/4G (usando oFono)
Também estão disponíveis plugins com funcionalidades adicionais: - Configuração da interface loopback - Gestão de proxy PACrunner - Suporte de autorização PolicyKit
Note que quando o ConnMan é iniciado, ele limpa todas as interfaces de rede que serão utilizadas. Se isso não for desejado, as interfaces de rede podem ser ignoradas definindo NetworkInterfaceBlacklist no ficheiro de configuração main.conf ou usando a opção de linha de comando -I.
Para compilar o Connection Manager, precisa dos seguintes pacotes de software: - Compilador GCC - Biblioteca GLib - Biblioteca D-Bus - Biblioteca IP-Tables (para suporte de tethering) - Biblioteca GnuTLS (opcional) - PolicyKit (opcional) - readline (cliente de linha de comando)
Para configurar execute: ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
O configure procura automaticamente todos os componentes e pacotes necessários.
Para compilar e instalar execute: make && make install
Para um sistema funcional, certas opções de configuração precisam ser ativadas:
--disable-ethernet
Desativa o suporte para placas de rede Ethernet
Por predefinição, o suporte à tecnologia Ethernet está integrado e
ativado. Esta opção pode ser usada para construir um daemon pequeno
para um sistema específico se o suporte Ethernet não for necessário.
--disable-gadget
Desativa o suporte para dispositivos USB Ethernet Gadget
Por predefinição, o suporte à tecnologia USB Ethernet Gadget está integrado e
ativado. Esta opção pode ser usada para construir um daemon pequeno
para um sistema específico se o suporte USB Ethernet Gadget não for necessário.
--disable-wifi
Desativa o suporte para dispositivos WiFi
Por predefinição, o suporte à tecnologia WiFi está integrado e
ativado. Esta opção pode ser usada para construir um daemon pequeno
para um sistema específico se o suporte WiFi não for necessário.
É seguro construir um daemon com suporte WiFi e sem
wpa_supplicant em execução. O início do wpa_supplicant é
detetado automaticamente e é apenas uma dependência em tempo de execução.
Não é necessário para compilar o ConnMan.
--disable-bluetooth
Desativa o suporte para dispositivos Bluetooth
Por predefinição, o suporte à tecnologia Bluetooth está integrado e
ativado. Esta opção pode ser usada para construir um daemon pequeno
para um sistema específico se o suporte Bluetooth não for necessário.
É seguro construir um daemon com suporte Bluetooth e sem
bluetoothd em execução. O início do bluetoothd é automaticamente
detetado e é apenas uma dependência em tempo de execução. Não é necessário para
compilar o ConnMan.
--disable-ofono
Desativa o suporte para dispositivos celulares 2G/3G/4G
Por predefinição, o suporte à tecnologia oFono está integrado e
ativado. Esta opção pode ser usada para construir um daemon pequeno
para um sistema específico onde o oFono não é utilizado.
É seguro construir um daemon com suporte oFono e sem
ofonod em execução. O início do ofonod é automaticamente
detetado e é apenas uma dependência em tempo de execução. Não é necessário para
compilar o ConnMan.
--disable-dundee
Desativa o suporte para dispositivos Bluetooth DUN
Por predefinição, o suporte à tecnologia Bluetooth DUN (dundee) está
integrado e ativado. Esta opção pode ser usada para construir um
daemon pequeno para um sistema específico onde o dundee não é utilizado.
É seguro construir um daemon com suporte dundee e sem
dundee em execução. O início do dundee é automaticamente
detetado e é apenas uma dependência em tempo de execução. Não é necessário para
compilar o ConnMan.
--enable-iwd
Ativa o suporte para Wireless daemon for Linux
O projeto IWD ainda não tem um lançamento inicial,
portanto, por predefinição, o suporte IWD não está ativado.
É seguro ativar esta opção juntamente com o suporte WiFi.
--disable-pacrunner
Desativa o suporte para gestão de proxy PACrunner
Por predefinição, o suporte PACrunner está integrado e ativado. Esta
opção pode ser usada para construir um daemon pequeno para um sistema
específico onde o PACrunner não é utilizado.
É seguro construir um daemon com suporte PACrunner e sem o
daemon pacrunner. Este detetará e iniciará um processo PACrunner
se necessário em tempo de execução. A presença não é necessária
para compilar o ConnMan.
--disable-loopback
Desativa a configuração do dispositivo loopback
Para distribuições com um sistema init realmente mínimo e sem
scripts de rede, isto pode cuidar da configuração do
dispositivo loopback e da sua ativação.
É seguro manter esta opção selecionada mesmo que os scripts
de rede estejam em vigor. Deteta um dispositivo loopback já
configurado e deixa-o como está.
--disable-wispr
Desativa o suporte para logins em hotspots WISPr
Para sistemas com requisitos de memória realmente mínimos, isto
desativará o suporte para logins em hotspots WISPr. O código
para WISPr ainda será compilado no daemon, mas a sua
dependência do GnuTLS para conexões seguras será removida.
A falta de suporte GnuTLS reduz os requisitos de memória
em cerca de 30% e, para sistemas mais estáticos que não
iniciam sessão em hotspots, isto pode ser um melhor compromisso.
Desativar o suporte WISPr não desativa o suporte de deteção
de portal. Um portal ainda será detetado, mas em vez de ser
solicitado o login, o pedido de uma sessão de navegador
será feito através do agente.
--enable-polkit
Ativa o suporte para autorização PolicyKit
Isto permite verificar cada acesso D-Bus contra uma política
de segurança e, assim, restringir o acesso a determinadas funcionalidades.
--enable-nmcompat
Ativa o suporte para interfaces de compatibilidade NetworkManager
Isto permite expor um conjunto mínimo de interfaces NetworkManager.
É útil para sistemas com aplicações escritas para usar o NetworkManager
para detetar o estado online/offline e que ainda não foram convertidas
para usar o ConnMan.
--disable-client
Desativa o suporte para o cliente de linha de comando
Por predefinição, o cliente de linha de comando está ativado e usa a
biblioteca readline. Para sistemas específicos onde o ConnMan é
configurado por outros meios, o cliente de linha de comando pode ser
desativado e a dependência do readline é removida.
--enable-selinux
Ativa o suporte para compilar regras de imposição de tipo SElinux
As regras TE são necessárias se o ambiente do hospedeiro estiver em modo
de imposição. Sem esta opção, o processo cliente VPN não pode
enviar notificação para o connman-vpnd através da interface
net.connman.Task. O módulo compilado connman-task.pp precisa
também ser instalado usando este comando
# semodule -i connman-task.pp
para ativar o acesso ao dbus.
--with-dns-backend=TYPE
Ativa o suporte para um backend de resolução de DNS
Seleciona um backend DNS a usar. Os valores suportados são "internal"
e "systemd-resolved". Se "internal" for selecionado, o ConnMan
será construído com um proxy DNS com cache. Se "systemd-resolved"
for selecionado, o ConnMan configura o systemd-resolved para fazer resolução
de DNS. O valor predefinido é "internal".
Pode ativar impressões de depuração no ConnMan usando a opção de linha de comando -d. Se a opção -d não tiver parâmetros, a depuração é ativada para todos os ficheiros de código-fonte. Se a opção -d tiver parâmetros, eles indicam quais ficheiros de código-fonte têm a depuração ativada. Podem ser usados caracteres curinga nos nomes dos ficheiros. Exemplo: -d Ativa todas as impressões de depuração normais -d src/service.c Imprime informações de depuração apenas do ficheiro src/service.c -d src/network.c:src/ipconfig.c Ativa impressões de depuração nos ficheiros src/network.c e src/ipconfig.c. -d 'src/n*.c' Ativaria impressões de depuração de todos os ficheiros fonte C começando com a letra 'n' no diretório src. Note as aspas em torno da opção, para evitar expansão pelo shell. -d '/n.c:/i.c' Ativa impressões de depuração para todos os ficheiros fonte C começando com as letras 'n' ou 'i' em qualquer subdiretório.
Alguns componentes do ConnMan têm impressões de depuração ativadas por variáveis de ambiente. Se a variável de ambiente estiver definida, o componente correspondente imprimirá algumas informações de depuração extra. As seguintes variáveis de ambiente podem ser usadas: CONNMAN_DHCP_DEBUG Informações de depuração relacionadas ao DHCPv4 CONNMAN_DHCPV6_DEBUG Informações de depuração relacionadas ao DHCPv6 CONNMAN_IPTABLES_DEBUG Informações extra quando o iptables é usado CONNMAN_RESOLV_DEBUG Impressões de depuração do resolvedor de nomes. Estas impressões de depuração são usadas quando o ConnMan resolve nomes de anfitrião para uso próprio. Note que as impressões de depuração do proxy DNS não usam esta variável de ambiente. Para isso, pode usar a opção de linha de comando "-d src/dnsproxy.c". CONNMAN_SUPPLICANT_DEBUG Impressões de depuração para comunicação entre os processos connmand e wpa_supplicant. CONNMAN_WEB_DEBUG Informações de depuração quando o ConnMan faz verificação de conectividade à Internet nos componentes Wispr e 6to4.
Exemplo: CONNMAN_WEB_DEBUG=1 src/connmand -n
Se as condições de temporização forem relevantes, recomenda-se o comando para obter rastreios de log da seguinte forma: connmand -d 2>&1 | ts '[%H:%M:%.S]' | tee connman.log
O programa 'ts' normalmente está disponível no pacote moreutils.
Para suportar tethering, as seguintes opções de configuração do kernel precisam ser ativadas como módulos (m) ou incorporadas (y):
CONFIG_BRIDGE CONFIG_IP_NF_TARGET_MASQUERADE
Para ativar CONFIG_IP_NF_TARGET_MASQUERADE, as seguintes opções precisam ser ativadas também como módulos (m) ou incorporadas (y):
CONFIG_NETFILTER CONFIG_NF_CONNTRACK_IPV4 CONFIG_NF_NAT_IPV4
Para suporte de roteamento e estatísticas em Sessões, as seguintes opções precisam ser ativadas como módulos (m) ou incorporadas (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 suportar tethering USB gadget, as seguintes opções de configuração do kernel precisam ser ativadas:
CONFIG_USB_GADGET CONFIG_USB_ETH
Para que o wpa_supplicant e o Connection Manager funcionem corretamente juntos, deve editar o ficheiro .config do wpa_supplicant e definir:
CONFIG_WPS=y CONFIG_AP=y CONFIG_CTRL_IFACE_DBUS_NEW=y
adicione:
CONFIG_BGSCAN_SIMPLE=y
Esta última opção ativará o suporte de verificação de fundo enquanto estiver conectado, o que é necessário para roaming em wifi.
Recomenda-se usar wpa_supplicant 2.x ou posterior.
Se o wpa_supplicant estiver configurado para arranque automático via D-Bus, então o ConnMan acionará o arranque automático do wpa_supplicant. No entanto, tenha em mente que este acionamento ocorre apenas uma vez. Se o wpa_supplicant parar ou falhar, o ConnMan não tenta periodicamente reiniciá-lo automaticamente. Cabe ao systemd ou ferramenta de gestão de serviços semelhante reiniciá-lo automaticamente. Caso o wpa_supplicant não seja iniciado pelo ConnMan, certifique-se de que a opção "-u" é usada para ativar a sua interface de controlo D-Bus e garantir que o ConnMan pode comunicar com ele.
Para compilar os plugins VPN pptp e l2tp, precisa do pacote de desenvolvimento ppp.
Para executar l2tp precisará de - xl2tpd, http://www.xelerance.com/services/software/xl2tpd
Para executar pptp precisará de - Cliente pptp, http://pptpclient.sourceforge.net
Tanto l2tp como pptp também precisam do pppd.
Até à versão 2.2 do OpenVPN, empurrar rotas adicionais do servidor nem sempre funcionará. Alguns dos sintomas são que as rotas adicionais não serão definidas pelo ConnMan se a ligação ascendente for uma rede celular. Enquanto a mesma configuração funciona bem para uma ligação ascendente WiFi ou ethernet.
Até à (pelo menos) versão 2.4.5 do OpenVPN, obter informações sobre falhas de desencriptação de chave privada através do canal de gestão está em falta. Isto resultará em tentativas repetidas com a chave inválida, pois a informação sobre a falha de desencriptação não é entregue ao plugin OpenVPN. O seguinte patch para o OpenVPN é necessário para que as falhas de desencriptação de chave privada sejam enviadas: https://git.sailfishos.org/mer-core/openvpn/blob/ 4f4b4af116292a207416c8a990392e35a6fc41af/rpm/privatekey-passphrase- handling.diff
Ao usar GnuTLS, esteja ciente que, dependendo da configuração do GnuTLS, é feita uma inicialização preguiçosa (lazy) ou imediata (eager) de um conjunto interno de entropia usando /dev/urandom. Na inicialização imediata, o carregamento do ConnMan será atrasado pelo linker até que o conjunto de entropia esteja preenchido. Em sistemas mais pequenos, isto pode facilmente atrasar o arranque do ConnMan por vários segundos (tivemos relatos de 25 segundos ou mais de atraso).
O GnuTLS permite voltar à avaliação preguiçosa quando a variável de ambiente GNUTLS_NO_EXPLICIT_INIT está definida. Para mais detalhes, leia a página de manual do gnutls_global_init(3).
O ConnMan tenta detetar se tem conexão à Internet ou não quando um serviço está conectado. Se a verificação online for bem-sucedida, o serviço entra no estado Online; caso contrário, permanece no estado Ready. A verificação online também é usada para detetar se o ConnMan está atrás de um portal cativo, como quando está num hotel e precisa pagar pela conectividade.
A verificação online é feita tentando obter o documento status.html de ipv4.connman.net (para conectividade IPv4) e ipv6.connman.net (para conectividade IPv6). O URL usado tem este aspeto http://ipv{4|6}.connman.net/online/status.html
A verificação online opera num de três modos:
onde "one-shot" é o predefinido e é governado pela definição "OnlineCheckMode".
No modo "none", não há verificações "online" de alcance à Internet baseadas em HTTP. Qualquer serviço conectado e o estado do gestor terminarão no estado Ready e não progredirão para Online.
No modo "one-shot", o modo predefinido, há uma única verificação "online" de alcance à Internet baseada em HTTP para o serviço predefinido (isto é, o serviço com a rota predefinida de gateway de alta prioridade (métrica 0)). Quando a verificação é bem-sucedida, o serviço associado e o estado do gestor terminarão no estado "online". Quando a verificação falha, as verificações subsequentes serão reagendadas de acordo com "OnlineCheckIntervalStyle", "OnlineCheckInitialInterval" e "OnlineCheckMaxInterval" e continuarão indefinidamente até que uma seja bem-sucedida ou até que o serviço seja desconectado.
No modo "continuous", há verificações "online" contínuas de alcance à Internet baseadas em HTTP para o serviço predefinido (isto é, o serviço com a rota predefinida de gateway de alta prioridade (métrica 0)). Tal como no modo "one-shot", quando a primeira verificação é bem-sucedida, o serviço associado e o estado do gestor terminarão no estado Online. A partir daí, as verificações subsequentes serão agendadas de acordo com "OnlineCheckIntervalStyle" e "OnlineCheckMaxInterval". Quando a verificação falha, as verificações subsequentes serão reagendadas de acordo com "OnlineCheckIntervalStyle", "OnlineCheckInitialInterval" e "OnlineCheckMaxInterval". Quando e se "OnlineCheckFailuresThreshold" for atingido, o serviço e o estado do gestor serão rebaixados para Ready e o serviço terá a sua propriedade "Error" definida como "online-check-failed" enquanto as verificações subsequentes continuam. Entretanto, se disponível, outro serviço pode ser promovido a serviço predefinido e as verificações online serão iniciadas para ele. Quando e se, para o serviço rebaixado, "OnlineCheckSuccessesThreshold" for atingido, a propriedade "Error" do serviço será limpa e o estado do serviço promovido para Online, potencialmente fazendo com que se torne novamente o serviço predefinido.
Consulte connman.conf(5) para a opção "OnlineCheckMode", se precisar desativar a funcionalidade. Também é possível especificar outros URLs através das opções "OnlineCheckIPv4URL" e "OnlineCheckIPv6URL". O intervalo de intervalos entre dois pedidos de verificação online pode ser ajustado através das opções "OnlineCheckInitialInterval" e "OnlineCheckMaxInterval", bem como com a opção "OnlineCheckIntervalStyle".
Como sugerido acima, para os modos "one-shot" e "continuous", quando um pedido de verificação online falha (ou, no caso do modo "continuous", também quando é bem-sucedido), outro é acionado após um intervalo maior. Os intervalos seguem uma de duas sequências matemáticas, dependendo da definição "OnlineCheckIntervalStyle": "fibonacci" ou "geometric", com um predefinido de "geometric". A definição geométrica é a série quadrada de números no intervalo especificado por "OnlineCheckInitialInterval" e "OnlineCheckMaxInterval". Os valores predefinidos para "OnlineCheckInitialInterval" e "OnlineCheckMaxInterval" são o intervalo [1, 12], que correspondem aos seguintes intervalos "geometric", em segundos: 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121 e 144 nesse intervalo. Em contraste, a sequência "fibonacci" correspondente nesse intervalo é 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 e 144. A série e estilo "fibonacci" é mais agressiva na taxa de verificação até 12 passos (o seu ponto de equivalência com "geometric" aos 144 segundos) do que "geometric", mas reduz a taxa muito mais agressivamente após esse ponto, atingindo uma hora no intervalo 19 que "geometric" não atinge até ao intervalo 60.
Durante o procedimento de verificação online, o ConnMan instalará temporariamente uma rota de anfitrião para ipv4.connman.net e ipv6.connman.net para que a consulta de verificação online possa ser direcionada através da interface de rede correta que o serviço conectado está a usar. Esta rota de anfitrião é automaticamente removida quando a verificação online termina. Note que o servidor expressamente não regista qualquer informação de conexão, incluindo endereços IPv4/6 dos clientes que se conectam. Os registos de tempo de execução do servidor circulam na memória RAM dependendo da quantidade de conexões processadas.
O ConnMan envia esta informação muito mínima no cabeçalho http ao fazer o pedido de verificação online (exemplo): Host: ipv4.connman.net User-Agent: ConnMan/1.23 wispr Connection: close
Atualmente, a seguinte informação é retornada do connman.net se a conexão for bem-sucedida (código de resposta http 200 OK é retornado): Server: nginx Date: Mon, 09 Jun 2014 09:25:42 GMT Content-Type: text/html Connection: close X-ConnMan-Status: online
O campo X-ConnMan-Status é usado na deteção de portal; se estiver ausente, o ConnMan chamará o método RequestBrowser na interface dbus net.connman.Agent para lidar com o login do portal, se o portal não suportar WISPr. Consulte doc/agent-api.txt para mais detalhes.
Lista de correio: [email protected]
Se desejar subscrever para receber correio na sua caixa de entrada, basta enviar uma mensagem (vazia) a partir da sua conta de email para
Arquivo da lista de correio: https://lore.kernel.org/connman
IRC: ircs://irc.oftc.net:6697/#connman (para SSL) irc://irc.oftc.net:6667/#connman (para não SSL)