Em todos os sistemas que funcionam em rede, normalmente há um servidor que processa informações, permite o acesso e utilização de determinados serviços e responde a requisições.

Obviamente que, numa rede com um servidor, há mais de uma máquina cliente realizando requisições ao primeiro num mesmo período de tempo. Isso faz com que o servidor, em algum momento, tenha que realizar mais de uma operação simultaneamente, podendo em determinado ponto de seu processamento, ocorrer um conflito entre as operações simultâneas, já que para que tudo ocorra corretamente, as operações precisam ser processadas em determinada ordem.

Esse tipo de conflito não ocorre apenas em um sistema computacional, mas em todos os sistemas eletrônicos, onde uma operação para ocorrer depende de várias outras. Mas vamos nos ater ao escopo de TIC.

Em um computador, uma race condition pode ocorrer se requisições para ler ou alterar uma grande quantidade de dados são recebidas quase ao mesmo tempo, e o computador tenta sobrescrever parte ou todos os dados enquanto os dados antigos ainda estão sendo lidos. Os resultados podem ser os seguintes: travamento do sistema, “operação ilegal”, encerramento do programa, erros de leitura dos dados antigos ou erros na alteração dos novos dados.

Numa rede de computadores, uma race condition pode ocorrer se dois usuários tentam acessar a mesma linha de tráfego ao mesmo tempo e nenhum dos computadores recebe o sinal de que aquele canal está ocupado antes de o sistema permitir o acesso.

Um atacante pode tirar vantagem desse tipo de falha – vulnerabilidade de race condition – e ganhar acesso não autorizado ao sistema. Esse tipo de vulnerabilidade também permite um atacante explorar o ataque conhecido como ARP Poisoning (pharming ou ARP Spoofing), onde o mesmo infecta o cache DNS do servidor redirecionando as requisições de determinado IP para um IP especificado pelo primeiro.

Até um tempo atrás, para realizar esse tipo de ataque o atacante precisaria realizar muitas tentativas para vencer a race condition e fazer com que sua requisição fosse processada ao mesmo tempo que uma requisição feita para o IP que seria redirecionado.

No entanto, Dan Kaminsky, um conhecido expert em DNS, descobriu uma falha em 2008 que através de uma simples requisição, o atacante faria com que uma série de transações fossem realizadas pelo DNS para buscar o domínio requisitado, o que abriria uma janela de tempo que permitira que o atacante infectasse o cache DNS e redirecionasse o domínio requisitado para o IP de sua escolha. O atacante simplesmente venceu a corrida e infectou o servidor DNS.

Uma falha como essa é muito séria, razoavelmente fácil de explorar através da técnica de Man-In-The-Middle e só agora foi descoberta. Isso quer dizer que tem muito administrador por aí que ainda vai levar um tempo para instalar os devidos patches de segurança.

Resumindo, podemos dizer que uma race condition nada mais é do que uma corrida para ver qual requisição chega primeiro no servidor e é processada. Sendo assim, é uma condição que pode ser explorada de diversas formas por um atacante habilidoso.

Referências

DoxPara.com – http://www.doxpara.com/?p=1185

Kaminsky DNS Solution – www.ipam.nl/whitepapers/NitroSecuritys_Kaminsky_DNS_Solution.pdf

Kaminsky (finally) reveals gaping hole in internet – http://www.theregister.co.uk/2008/08/06/kaminsky_black_hat/