[FUGSPBR] [FUGSPBR:][Fwd: SEGURANÇA.Problemas de segurança nos controladores de dispositivos Ethernet]

[Ricardo A. Reis]

Caros amigos,

	Alguem poderia confirmar se ja existe algum remendo oficial para esse 
problema ou se realmente os drives ethernet dos BSD sofrem do mesmo 
problema?


Atenciosamente Soulofblack



-------- Original Message --------
Subject: SEGURANÇA: Re: Problemas de segurança nos controladores de 
dispositivos Ethernet
Date: Mon, 13 Jan 2003 20:42:54 +0000
From: Sérgio Araújo <sergio em projecto-oasis.cx>
Reply-To: <seguranca em projecto-oasis.cx>(Segurança informática)
To: <seguranca em projecto-oasis.cx>(Segurança informática)

Cumprimentos,

Xsecurity.ws wrote:

> Um grupo de investigadores descobriu a existência de um importante
> problema de segurança que afecta um grande número de controladores de
> dispositivos Ethernet.
> O standard IEEE define que os pacotes transmitidos numa rede Ethernet
> devem ter um tamanho mínimo de 46 bytes e um máximo de 1500 bytes.
> Quando se utilizam alguns protocolos de comunicações, como é o caso do
> protocolo IP, que requer um tamanho inferior ao mínimo estabelecido, é
> necessário completar um espaço livre com valores nulos (ver RFC/894).


"Padding the frame".

> Continuando....
>
> Foi descoberto que muitos controladores de dispositivos Ethernet não
> realizam esta operação sem que, no seu lugar, quando devem enviar um
> pacote com um tamanho inferior ao mínimo estabelecido por Standard, se
> reutilizam os bytes contidos nos pacotes anteriores.


Pior: em vez de completarem a trama Ethernet com informação inválida
utilizam informação proveniente da memória reservada ao "driver", ao
"kernel" do sistema operativo ou de "buffers" da própria placa de rede.

> O seguinte fragmento de código C mostra a vulnerabilidade:
>
> 01 void xmit_frame(char *frame_buf, int frame_len)
> 02 {
> 03 int length;
> 04
> 05
> 06 if (frame_len MIN_FRAME_SZ)
> 07 length = MIN_FRAME_SZ;
> 08 else
> 09 length = frame_len;
> 10
> 11 copy_to_tx_buf(frame_buf, length);
> 12
> 13 return;
> 14 }
>
> Isto, que à simples vista pode parecer de pouca importância, pode
> converter-se num problema de segurança muito grave em determinados
> contornos. Se utiliza um controlador de dispositivos Ethernet que não
> realiza a continuação dos valores nulos e dos bytes livres nos 
> pacotes, estes podem incluir informação sensível precedente de outros 
> pacotes.


Ofir Arkin e Josh Anderson, (que descobriram o problema), simplesmente
enviando pacotes ICMP à vítima, conseguiram obter palavras-chave, e
informação sobre sessões HTTP, analizando o "padding" das respostas.

A técnica garante, por exemplo, (com uma alta probabilidade de sucesso,
se utilizada durante várias semanas), a captura de palavras-chave, ou
contornar mecanismos para separação de tráfego, como VLAN's 802.1Q, etc...

> Utilizando o exemplo do código anterior, deveria efectuar a seguinte
> modificação para eliminar a vulnerabilidade:
>
> ...
> 06 if (frame_len MIN_FRAME_SZ) {
> 07 length = MIN_FRAME_SZ;
> 08 memset(frame_buf + frame_len, 0, length - frame_len);
> 09 } else
> ...
>
> Esta vulnerabilidade está presente num grande número de controladores 
> de dispositivos Ethernet, em diversos Sistemas Operativos, incluindo,
> Linux, *BSD e Windows.
>
> Mais informações em: http://www.kb.cert.org/vuls/id/412115


No documento original, "EtherLeak: Ethernet frame padding information
leakage", (em
http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf), 

são apontados mais de 40 controladores vulneráveis.

A Microsoft afirma que os "drivers" que publicou não possuem este
problema, mas não pode garantir o mesmo sobre especificações e exemplos
de código publicados, utilizados por terceiros para construir os seus
próprios controladores.

Uma vez serem tantos os vendedores afectados, (uns mais atentos a estes
problemas de segurança que outros, reparem que foram notificados sobre
isto há seis meses!), e ser difícil, na minha opinião, localizar os
autores de alguns dos "drivers" Open Source que por aí andam, creio ser
essencial a disponibilização imediata de uma ferramenta "amigável" que
permita testar a existência do problema, e alertar o utilizador "comum".

A Microsoft prometeu incluir código para esse fim na sua especificação
para a certificação de "drivers", que poderia servir como base.

Creio surgir aqui uma oportunidade para uma ferramenta útil,
disponibilizada por um subscritor desta lista. Algum candidato ?

Cordialmente,

Sérgio Araújo
------------------------------------------------------------------------

_______________________________________________________________________
Busca Yahoo!
O melhor lugar para encontrar tudo o que você procura na Internet
http://br.busca.yahoo.com/
_______________________________________________________________
Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/