A AMD
acaba de integrar em seu chip Athlon 64 (e a Intel promete que brevemente
integrará nos dela) uma tecnologia que impede indivíduos
mal intencionados de explorar a vulnerabilidade conhecida como “buffer
overflow”.
E daí? Ficou feliz? Aplaudiu? Não tá nem aí?
Não decidiu ainda porque não sabe o que é “buffer
overflow”? Então vamos dar um jeito, pois a coisa é
mais simples do que parece.
Comecemos pela palavra mais fácil de explicar: “overflow”,
que significa “entornar”, “extravasar”, “verter
para fora algo que excedeu a capacidade de um vaso ou similar”.
Já “buffer” é mais complicado. Significa “amortecedor”,
no sentido de algo que reduz os efeitos de choques bruscos, mas em informática
tem um sentido especial: designa um trecho de memória para armazenamento
temporário de dados. Começou a ser usado nas interfaces
entre componentes lentos e rápidos. Por exemplo: se comparado
à CPU, um modem é muito lento. Se a CPU enviasse dados
diretamente para o modem para serem transferidos para outro computador
através da linha telefônica, ao longo do tempo o modem
receberia muito mais dados (no ritmo que a CPU os produz) do que poderia
transmitir (no ritmo que a linha telefônica os aceita). Inevitavelmente
alguns dados seriam perdidos. A solução é instalar,
na placa controladora do modem, uma pequena quantidade de memória
que recebe os dados no ritmo que a CPU os envia e os armazena por um
breve período enquanto os encaminha paulatinamente ao modem em
um ritmo mais lento. Essa memória funcionaria como um reservatório
de nível variável, “enchendo” quando a CPU
envia dados rapidamente e o modem não os pode receber no mesmo
ritmo, “esvaziando” quando a CPU pára de mandar dados
para o modem e vai tratar de outras tarefas e o modem tem tempo para
remover os dados da memória temporária e enviá-los
pela linha telefônica. Essa memória, então, “amortece”
o fluxo de dados enviado pela CPU ao modem. Por isso recebeu o nome
de “buffer”.
E o que acontece quando a CPU envia dados depressa demais ao “buffer”,
excedendo sua capacidade? Ora, a mesma coisa que aconteceria se o buffer
fosse, digamos, uma caixa d’água: os dados excedentes “entornam”,
“extravasam”. Ou seja: ocorre um “buffer overflow”.
Como eu disse, o conceito é mais simples do que parece.
Mas que tipo de vulnerabilidade isso pode acarretar? Nesse buffer, nenhuma.
Mas acontece que “buffer” é um nome genérico
para designar qualquer trecho de memória destinado ao armazenamento
de informações temporárias. Inclusive os localizados
na própria memória principal e usados como estruturas
de dados temporárias pelos programas e sistemas operacionais.
E é aí que mora o perigo.
Eu não vou descer a detalhes técnicos maçantes,
vou apenas dar uma idéia de como a coisa funciona. Um programa
nada mais é que um conjunto de instruções lidas
na memória principal e executadas em uma dada seqüência.
Tudo isso é coordenado pelo sistema operacional. Quando a execução
de um programa é interrompida por alguma razão (seja por
solicitação de outro programa, seja pelo usuário
via mouse ou teclado), a CPU pára o que está fazendo e
atende o pedido (“serve” ou “trata” a interrupção,
para os puristas). Porém, mais tarde, é preciso retomar
o programa exatamente no ponto onde ele foi interrompido. Então,
antes de tratar a interrupção, o sistema operacional armazena
em um trecho de memória de uso temporário (uma estrutura
chamada “pilha”) o “endereço de retorno”,
ou seja, o endereço da próxima instrução
que seria executada caso não houvesse a interrupção.
Quando tudo está resolvido, o sistema operacional volta à
“pilha”, lê o conteúdo do “endereço
de retorno”, presume que seja a próxima instrução
do programa e a executa. O problema todo está nesse “presume”
aí de cima...
Isso porque, sempre que encontram oportunidade, programadores mal intencionados
criam código que armazena na “pilha” uma rotina (conjunto
de instruções) potencialmente destrutiva, propagadora
de vírus ou cavalos de Tróia, e continuam a introduzir
dados até exceder a capacidade da pilha. Que “entorna”,
extravasando dados para áreas adjacentes. Inclusive a que contém
o endereço de retorno, onde o biltre escreve o endereço
da primeira instrução da rotina que ele acabou de “plantar”
na memória. Resultado: “presumindo” que se trata
da continuação do programa, o sistema operacional continua
a execução a partir daquele ponto. E, em vez do programa,
executa o código daninho armazenado no interior da pilha.
Veja o início do parágrafo anterior e note que eu afirmei
que isso só é possível quando os pilantras encontram
oportunidade. Ou seja, quando o programador deixou um “furo”
em seu código. Vocês lembram que, lá pelos idos
de julho de 2000, começaram a aparecer vírus e vermes
que contaminavam a máquina através de mensagens de correio
eletrônico que nem sequer precisavam ser abertas para exercer
sua ação nefanda? Pois aquilo foi fruto de uma falha tipo
“buffer overflow” na rotina de manipulação
dos cabeçalhos das mensagens pelo Outlook (inclusive o Express).
Como o cabeçalho era processado tão logo a mensagem era
recebida, nem era preciso abrir a mensagem para contaminar a máquina.
A MS prontamente corrigiu a falha e, se você instalou a correção,
já não corre risco. Mas o incidente dá bem a idéia
do prejuízo que a exploração de um buffer overflow
pode causar.
Pois bem, agora que sabemos o que é um “buffer overflow”
podemos avaliar melhor a atitude da AMD, que acaba de incluir em seus
Athlon 64 uma tecnologia denominada “Execution Protection”,
que impede que programas executem código contido no interior
de estruturas de memória de uso temporário (todo tipo
de “buffer”, inclusive as pilhas). Assim, mesmo que o programador
mal intencionado tenha armazenado seu código no buffer e alterado
o endereço de retorno, ao tentar executar o código o sistema
gerará um erro, impedindo quaisquer ações prejudiciais.
Os circuitos correspondentes à Execution Protection já
integram o Athlon 64 mas, como ela depende da colaboração
do sistema operacional, somente serão eficazes depois que a MS
liberar o SP2 (Service Pack 2) para Windows XP, esperada para o próximo
trimestre. A Intel, por sua vez, já anunciou que uma tecnologia
similar será integrada a seu novo Prescott (veja dados sobre
o Prescott no artigo “O
que a Intel nos reserva para 2004”, publicado em primeiro
de janeiro e disponível na seção “Escritos
/ Artigos no Estado de Minas” de meu sítio, em <www.bpiropo.com.br>).
É claro que os mequetrefes que criam vírus e cavalos de
Tróia encontrarão novos meios de nos atazanar. Mas pelo
menos não mais com o buffer overflow. A nova tecnologia representa
um gigantesco passo no sentido de aumentar a segurança de nossos
micros. Para que se tenha uma idéia: segundo Michael Kanellos
em <http://zdnet.com.com/2100-1105_2-5137832.html>,
mais da metade dos “patches” emitidos pela MS nos últimos
dois anos seriam desnecessários se ela já existisse.
B.
Piropo
