Hub IoT do Windows Azure

Hub IoT do Windows Azure é uma iniciativa desenvolvida pela Microsoft que conecta, monitora e controla vários dispositivos de IoTpor meio do serviço da nuvem¹. A nuvem assume o papel de hub central que gerencia a comunicação dos dispositivos que compõem a rede IoT. Com a solução Azure será possível estabelecer conexão confiável e segura dos dispositivos numa rede resiliente a falhas. Hub IoT possui telemetria e relatórios de rastreamento de eventos, essenciais para gerenciar equipamentos industriais e monitorar instrumentos valiosos na área da saúde; a Figura 8 descreve as plataformas suportadas pelo Hub IoT².

Figura 8 – Plataformas suportadas pelo hub IoT Fonte: Microsoft².

O projeto Azure IoT C SDK está disponível no GitHub³ e tem o objetivo de facilitar o trabalho do desenvolvedor que quer conectar os dispositivos de IoT utilizando

1 <https://docs.microsoft.com/pt-br/azure/iot-hub/about-iot-hub>

2 <https://docs.microsoft.com/pt-br/azure/iot-hub/>

3 <https://github.com/Azure/azure-iot-sdk-c/tree/0ca9b92d4ff7f7a44fe1687e81f919bd7dcaa944>

Capítulo 5. Resultados 46

a linguagem C. A licença do repositório é a MIT⁴ garantindo a liberdade de: modificar, distribuir, vender e sublicenciar. O código foi desenvolvido seguindo as orientações da ANSI C revisão C99; com esta revisão será possível maximizar a portabilidade do código para diversas extensões de compiladores existentes ampliando a compatibilidade da plataforma.

5.2.1 Função getMbedParameter() vulnerável

Neste trabalho foi realizado uma análise do código fonte do Hub IoT e identificou uma vulnerabilidade de BOF no arquivo iothub_account.c⁵ na linha 227, dentro da função getMbedParameter(), descrito no Algoritmo12. A vulnerabilidade em específico é do tipoStack Overflow originada pela função scanf(), que de acordo comViega e McGraw (2001) é uma função de alto risco de ocasionar o BOF. A função scanf() não obriga o desenvolvedor limitar o buffer de entrada, e, isto poderá ocasionar falhas de execução ou até mesmo um exploit.

Algoritmo 12 – Função getMbedParameter() vulnerável

223 static const char* getMbedParameter(const char* name)

224 {

225 static char value[MBED_PARAM_MAX_LENGTH];

226 (void)printf("%s?\r\n", name);

227 (void)scanf("%s", &value);

228 (void)printf("Received ’%s’\r\n", value);

229

230 return value;

231 }

Fonte: Trecho do código extraído no repositório azure-iot-sdk-c⁵.

Com objetivo de ilustrar a vulnerabilidade do BOF, o dispositivo Raspberry Pi executou somente o módulo iothub_account.c e em específico a função getMbedPa- rameter(). A constante definida pelo MBED_PARAM_MAX_LENGTH recebe o valor 256, ou seja, se obuffer de entrada ultrapassar este valor haverá oBOF. Para testar a integridade da aplicação foi inserido 256 caracteres para alcançar o limite e posteriormente foi adicionado o seguimento ”BUFFER_OVERFLOW” para denotar a sobrecarga.

A Figura 9 ilustra o resultado da execução que constata a existência doBOF no código quando o conteúdo ”BUFFER_OVERFLOW” é armazenada na variável value.

Esta anomalia é capaz de: sobrescrever dados, alterar fluxo de execução, ocasionar falhas de execução, injeção de código malicioso e sobrescrever o endereço de retorno para acionar código malicioso (DU, 2017).

4 <https://mit-license.org/>

5 <https://github.com/Azure/azure-iot-sdk-c/blob/0ca9b92d4ff7f7a44fe1687e81f919bd7dcaa944/

testtools/iothub_test/src/iothub_account.c>

Capítulo 5. Resultados 47

Figura 9 – Execução da função getMbedParameter() vulnerável no Raspberry Pi

5.2.2 Função getMbedParameter() corrigido

A solução do problema está apresentada no Algoritmo 13, em que a função scanf() foi substituída pela fgets(). Apesar do fgets() continuar sendo uma função vulnerável, este apresenta risco menor de ocasionar o BOF (VIEGA; MCGRAW, 2001), pois diferente- mente do scanf(), fgets() torna obrigatório delimitação do buffer de entrada, mitigando assim a ameaça. Executando o mesmo teste de integridade e atribuindo a constante MBED_PARAM_MAX_LENGTH como limite do buffer, é possível observar na Figura 10que apenas os 256 primeiros caracteres foram armazenados, enquanto o restante que seria o BOFfoi descartado.

O caso de estudo foi um exemplo prático de como o BOF poderia afetar uma aplicação, mas ao mesmo tempo pode ser corrigida facilmente. Entretanto, a maior dificuldade da vulnerabilidade não é aplicar a correção, e sim identificar a sua existência, pois nem toda iteração resulta em falha e algumas ferramentas de detecção do BOF(por exemplo Valgrind) pode não encontrá-la.

Capítulo 5. Resultados 48

Algoritmo 13 – Função getMbedParameter() corrigido

223 static const char* getMbedParameter(const char* name)

224 {

225 static char value[MBED_PARAM_MAX_LENGTH];

226 (void)printf("%s?\r\n", name);

227 (void)fgets(value, MBED_PARAM_MAX_LENGTH, stdin);

228 (void)printf("Received ’%s’\r\n", value);

229

230 return value;

231 }

Figura 10 – Execução da função getMbedParameter() corrigido no Raspberry Pi

49

6 Considerações Finais

As linguagens de programação de alto nível são preparadas para prevenir situações de erro do Buffer Overflow (BOF), por exemplo, Java é capaz de realizar verificação de limite de memória tornando-o imune contra a vulnerabilidade. O uso destas linguagens facilitam o desenvolvimento de códigos confiáveis através da sua abstração, contudo, há um custo de processamento que exigirá hardwares potentes como desktops e notebooks.

Os dispositivos de IoT tem limitação de recursos e ao utilizar linguagens de alto nível haverá implicações de desempenho. Por este motivo a linguagem C é empregada, pois apesar de exigir mais do programador para implementar códigos confiáveis, C possibilita desenvolvimento de alta performance, graças a sua proximidade com o hardware.

A prevenção de erros elementares doBOF não é complexa, porém o desenvolvedor precisa estar atento com as falhas de implementação, pois existem funções comumente da linguagem C suscetíveis à vulnerabilidade. O trabalho analisou o software Hub IoT do Windows Azure sendo uma aplicação dos dispositivos IoT que pode ser inviabilizado pelo BOF por uma função que não verifica o tamanho do buffer de entrada. Também foi avaliado soluções de código que corrigem o problema, entretanto, foi notado uma sobrecarga que prejudica o desempenho. Em alguns projetos de IoT, a performance é vista como elemento crítico e com isso confiabilidade será tratada como elemento secundário. O BOFcontinua sendo uma ameaça computacional difícil de detectar e com grande potencial de ser explorada e resultar em falhas de execução. As propostas de confiabilidade dos dispositivos de IoT não se diferem dos computadores tradicionais.