Escolar Documentos
Profissional Documentos
Cultura Documentos
Vulnerabilidades e Exploits Técnicas PDF
Vulnerabilidades e Exploits Técnicas PDF
INSTITUTO DE INFORMTICA
CINCIA DA COMPUTAO
CSAR MALERBA
No poderia, em hiptese alguma, deixar de agradecer minha famlia por tudo que
alcancei em meus estudos. Sobretudo o apoio de meus pais. Neles sempre tive o incentivo
e a estrutura necessrias para o meu desenvolvimento.
Agradeo tambm a todos que contribuem para o excelente funcionamento do
Instituto de Informtica da UFRGS. Notvel pelo interesse de seus professores e
funcionrios. Provando que o ensino pblico de qualidade alcanvel e oferece a
nossa sociedade enormes benefcios. Em especial ao meu orientador Raul Fernando
Weber; professor de enorme qualidade que muito contribuiu pelo meu interesse na rea
de segurana da computao e que me auxiliou no desenvolvimento desse trabalho.
Deixo tambm um agradecimento especial a uma pessoa que nunca deixou de
me lembrar do meu potencial e me auxiliou durante perodos difceis. Ela que me
acompanhou durante parte da minha jornada no curso: minha namorada Luciana.
SUMRIO
4 EXPLOITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Definio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 Buffer Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.2 Heap Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.3 Injeo de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.4 XSS (Cross Site Scripting) . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Preveno de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Validao de dados de entrada . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2 Ferramentas de anlise esttica e auditoria de cdigo . . . . . . . . . . . 40
4.4 Protees e contra-protees . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.1 Pilha no executvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.2 W X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.3 Canrio para a pilha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4.4 Reordenamento de variveis na pilha . . . . . . . . . . . . . . . . . . . . 43
4.4.5 ASLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 3.1: Vulnerabilidades registradas no CVE a cada ano entre 1999 e 2008.
Fonte: (FLORIAN, 2009) . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 3.2: Aplicao das mtricas e equaes do CVSS. Fonte: (MELL, 2007) . 34
ABSTRACT
Software becomes more important in our society everyday . However, it still suffers
from many security problems - most of them related to its development. To help
developers in understanding the subject, this paper addresses key points in software
security: vulnerabilities and exploits.
Two main issues related to vulnerabilities are presented: classification methods and
detection through fuzzing technique. Both aim at offering the reader basic concepts to
achieve safer and more conscious software development. Given the great value of fuzzing
technique in vulnerabilities discovery, it is proposed as a new tool to developers so that
they can apply it before the attackers.
Considering the knowledge of exploit techniques indispensable in the pursuit of
building safer software, this paper also tries to offer a view from the attackers perspective.
To achieve it, an overview of exploits is presented. After giving a broad idea on the
attackers methods, one of them is detailed: the NULL pointer exploit.
1 INTRODUO
1
Extratos de (COMMITTEE, 2005) foram traduzidos livremente pelo autor do presente trabalho.
13
2 CONCEITOS INICIAIS
2.1 Vulnerabilidade/Exploit
O primeiro termo que devemos definir neste trabalho exploit. Mas antes dele,
trataremos de vulnerabilidade - pois eles tm uma ligao estreita. Podemos definir
vulnerabilidade como uma falha em um sistema que permite a um atacante us-lo de uma
forma no prevista pelo projetista (ANLEY, 2007). Ou seja, uma vulnerabilidade implica
a possibilidade de uso indevido de um sistema. Os passos necessrios para explorar essa
fraqueza, ou mesmo o cdigo (programa) que pode tirar proveito da vulnerabilidade
descrito como exploit. Um exploit surge apenas quando h uma vulnerabilidade - mas
podem existir vulnerabilidades para as quais no exista exploit.
De maneira simplificada, podemos dizer que vulnerabilidades surgem devido a 3
causas bsicas:
Erros de implementao
Falhas de design
Erros de configurao ou de infra-estrutura do sistema
Na sequncia desse trabalho, sero aprofundados melhor esses dois conceitos.
Tambm sero examinadas com mais detalhe as causas dos problemas no software.
Um processo pode ser executado com apenas parte de seu cdigo carregado em
memria fsica
De forma geral, podemos que dizer que h um melhor uso dos recursos disponveis e a
abstrao criada pela virtualizao pode diminuir a preocupao dos programadores sobre
como o processo organizado na memria fsica.
A figura 2.1 apresenta uma viso global do funcionamento da memria virtual. Nela,
mostrado como um processo pode possuir regies diferentes de memria mapeadas
arbitrariamente para memria fsica; nesse caso composta de memria RAM e de um
disco de armazenamento.
Chamamos de endereo lgico aquele acessado pela aplicao - que seria, portanto o
nvel mais alto na virtualizao. J o endereo linear, resultado do processamento da
segmentao quando fornecido um endereo lgico. Para produzir o endereo fsico,
ainda necessrio que a unidade de paginao processe o endereo linear. A figura 2.2
ilustra esse processo.
Assim, mquinas x86 possuem 2 nveis, segmentao e paginao na ordem, a serem
tratados para que um endereo fsico possa ser encontrado a partir de um endereo lgico.
Cada um dos processos possui suas particularidades e implementa suas prprias protees
conforme passamos mais detalhes a seguir.
2.3.2 Segmentao
Para a segmentao, a memria organizada em segmentos e cada um deles possui
diferentes atributos. Os principais segmentos so: o de cdigo(mantido no registrador cs),
o de dados(no registrador ds) e o da pilha(no registrador ss). Para os fins desse trabalho,
cabe destacar os seguintes atributos de segmentos:
DPL Descriptor Privelege Level. Define o privilgio mnimo da CPU para que ele
possa ser acessado. O mximo privilgio identificado pelo valor 0; o menor em
3. Normalmente o sistema operacional se reserva o DPL 0, enquanto os demais
processos ficam com 3.
2.3.3 Paginao
Separando a memria em pginas de um tamanho fixo (normalmente 4Kb), a
paginao opera criando um mapeamento entre aquelas existentes na memria fsica e
aquelas do espao de endereamento das aplicaes. Assim, endereos contguos dentro
do endereo linear so mapeados para endereos contnuos dentro da pgina fsica.
Atravs das tabelas de pginas, realizado esse mapeamento. So estruturas de dados
mantidas pelo sistema operacional com o suporte do hardware. Elas mantm os dados
referentes s pginas. Devemos destacar as seguintes propriedades:
text A parte que contm as instrues do programa - seu cdigo propriamente dito. Seu
tamanho fixo durante a execuo e ela no deve possibilitar escrita.
data Contm variveis globais j inicializadas. Seu tamanho fixo durante a execuo.
bss Nome de origem histria significando Block Started by Symbol. rea da memria
18
0x0
Text
Alocao esttica
Alocao dinmica
Stack
0xffffffff
enviroment A ltima poro de memria do processo guarda uma cpia das variveis de
ambiente do sistema. Essa seo possui permisso de escrita, mas como bss, data e
text, possui tamanho fixo.
19
Figura 2.4: Organizao do frame na pilha. Fonte: (FURLAN, 2005) pg. 17.
parmetros
variveis locais
2.9 Shellcode
Outra parte fundamental de muitos exploits o chamado shellcode. Podemos
defin-lo, segundo (ANLEY, 2007), como um conjunto de instrues que so injetados
e executados por um programa atravs de um exploit. Normalmente, escrito em
linguagem assembly por manipular diretamente os registradores e depois transformado
em opcodes em hexadecimal.
A palavra shell contida em seu nome tem origem no fato de, normalmente, ele ser
usado para abrir um shell na mquina atacada. Sendo aberto com permisses de root,
o atacante assume controle absoluto do sistema. Ainda que isso seja o mais comum, o
shellcode no se restringe a isso. Como qualquer outro programa, ele, em muitos casos,
21
s limitado pela imaginao do seu construtor. Sua criao envolve certas dificuldades,
como a ausncia de bytes em zero; j que normalmente, ele armazenado na memria
como uma string na linguagem C - que termina com um zero.
Atualmente, existem diversos tipos de shellcode disponveis para os mais variados
sistemas e arquiteturas. Dificilmente um atacante ter a necessidade de produzir seu
prprio dada a abundncia de alternativas prontas. Alguns, por exemplo, possuem at
estratgias para enganar sistemas de deteco de invaso. Para as necessidades desse
trabalho, no iremos nos aprofundar nesse tema, mas no captulo 2 de (ANLEY, 2007),
h informaes muito teis para um aprendizado de shellcode.
22
3 CLASSIFICAO DE VULNERABILIDADES
Vemos, portanto, que a taxonomia1 das vulnerabilidades pode trazer uma srie de
benefcios para seu entendimento, tratamento e preveno. Nesse captulo, nosso intuito
abordar a dificuldade nesse processo e apresentar os avanos j obtidos nesse sentido.
3.1.1 Classificar
Como podemos encontrar em (HOLANDA FERREIRA, 1975), classificar implica
"distribuir em classes e/ou grupos segundo um sistema". Logo, para a classificao,
preciso haver uma metodologia que possa separar os itens em estudo em diferentes
grupos. A cincia que estuda esse processo chamada taxonomia. Ela guiada, conforme
(GRGIO, 2005a), pelos princpios taxonmicos. So eles:
Aceitabilidade Os critrios devem ser lgicos e intuitivos para serem aceitos pela
comunidade.
3.1.2 Enumerar
A enumerao um processo semelhante a "indicar por nmeros; relacionar
metodicamente"; como encontramos em (HOLANDA FERREIRA, 1975). Trata-se,
portanto, de algo muito mais simples que a classificao. Mesmo sendo mais simples,
extremamente importante pois permite que os itens enumerados sejam facilmente
apontados e diferenciados entre si.
Sem um procedimento de enumerao dos objetos de estudo, adotado de comum
acordo, no possvel que duas partes se comuniquem sem risco de cometerem enganos.
Quem garante que esto tratando exatamente da mesma coisa naquele momento? Logo a
enumerao essencial para o devido entendimento sobre os objetos de estudo.
3.2 CVE
3.2.1 Surgimento e objetivos
Para deixar mais ntida a dificuldade de interoperabilidade das organizaes no que se
refere a ameaas de segurana na poca que antecede o CVE, temos a tabela 3.1, extrada
de (MARTIN, 2001). Ela mostra como diferentes organizaes se referiam mesma
vulnerabilidade em 1998. Trata-se de um verdadeira Torre de Babel.
O CVE, como dito anteriormente, surge em 1999 e seu maior objetivo, como podemos
ler em sua FAQ, (CVE, 2010), tornar mais fcil o compartilhamento de informaes
sobre vulnerabilidades utilizando uma enumerao comum. Essa enumerao
realizada atravs da manuteno de uma lista na qual, conforme encontramos em
(SANTOS BRANDO, 2004), valem os seguintes princpios:
3.2.2 Funcionamento
O CVE formado por uma junta de especialistas em segurana dos meios acadmico,
comercial e governamental. Eles so responsveis por analisar e definir o que ser feito
dos reports passados pela comunidade - se eles devem ou no se integrar queles j
pertencentes lista. Cabe a eles definir nome, descrio e referncias para cada nova
ameaa.
25
Figura 3.1: Vulnerabilidades registradas no CVE a cada ano entre 1999 e 2008. Fonte:
(FLORIAN, 2009)
Esse processo inicia quando uma vulnerabilidade reportada. Ela assume um CAN
(Candidate Number), nmero de candidata. At que ela seja adicionada lista, ele
permanece com um CAN que a identificar. Apenas aps o devido estudo e aprovao do
caso pela junta responsvel, que ela assume um identificador CVE.
Os identificadores CVE so definidos conforme o padro: CVE-2010-0021. Onde,
separados por -, h 3 partes. A primeira fixa: CVE. A segunda refere-se ao ano de
surgimento; enquanto a terceira indica o nmero sequencial daquela vulnerabilidade entre
todas aquelas que foram adicionadas naquele ano. Logo, no exemplo fornecido, essa seria
a vigsima primeira de 2010.
Uma vez integrada, a vulnerabilidade passa a estar publicamente disponvel. Essa
abertura pode servir de auxlio aos atacantes - pois informaes sobre possveis furos de
segurana so sempre bem vindas a eles. Porm, conforme podemos verificar na FAQ do
CVE, (CVE, 2010), h uma srie de motivos pelos quais a disponibilidade desses dados
supera o risco oferecido pela exposio. So eles:
muito mais custo a uma organizao proteger toda sua rede contra as ameas que
a um atacante descobrir e explorar uma delas para comprometer alguma das redes.
Esse estudo teve importncia pelo pioneirismo, mas se limitava a problemas de sistemas
operacionais bem como no atendia a todos os princpios taxonmicos.
Dois anos aps o projeto RISOS, em 1978, seria criado o Protection Analysis(PA).
Seu objetivo principal era permitir que qualquer pessoa, mesmo sem conhecimento
especfico sobre falhas de segurana, utilizando um padro dirigido, pudesse encontrar
vulnerabilidades nos sistemas - (TSIPENYUK, 2005), pg. 2. O PA, separava as falhas
em 4 grandes classes - (GRGIO, 2005b), pg. 329:
Sincronizao imprpria;
1. Falhas de codificao;
Erros de sincronizao;
Erros na validao de condio;
2. Falhas emergentes;
Erros de configurao;
Falhas no ambiente;
Embora seja uma taxonomia precisa, conforme ressaltado anteriormente, ela sofre por
estar focada excessivamente em sistemais UNIX - como indicado em (TSIPENYUK,
2005).
Conforme ser abordado a seguir, o PLOVER serviu de base para a criao do projeto
CWE.
Do trabalho de John Viega e outros colaboradores, temos o CLASP. um conjunto
de atividades que busca melhorar a segurana dos sistemas. Embora trate tambm da
classificao das falhas, ele vai muito alm. Possui uma formalizao de boas prticas
para a construo de software seguro atravs de ciclos de desenvolvimento estruturados,
repetveis e mensurveis - (SECURE SOFTWARE, 2006).
No que se refere classificao, sua contribuio tem origem no trabalho proposto
por Landwher(que utiliza os critrios de gnese, tempo de introduo e localizao). O
CLASP adiciona outro eixo classificatrio: a consequncia. As classes mais bsicas, tipo
do problema, so:
Problemas no ambiente;
Erros de protocolo;
Erros de lgica;
Malware;
Para exemplificar, consideremos uma falha que permita um Buffer overflow. Segundo
o CLASP, trata-se de um erro de tipo e de range - j que permitida a escrita alm do
permitido no buffer. A injeo de SQL tambm cai na mesma categoria, pois os dados
passados pelo usurio so utilizados incorretamente; permitindo que assumam um tipo
inesperado. J um erro no qual ignorado o valor de retorno de uma funo considerado
como erro de lgica - como, por exemplo, uma chamada funo malloc que no avalia
se a alocao de memria foi bem sucedida.
O Seven Pernicious Kingdoms, de autoria de Katrina Tsipenyuk et alem, conforme
(MCGRAW, 2006), captulo 12, uma taxonomia que, mesmo sendo imperfeita
possibilita um bom entendimento por parte dos desenvolvedores; auxiliando na preveno
de problemas. estruturada em dois conjuntos emprestados da Biologia: Filo e Reino. O
Reino a classificao mais ampla - enquanto o Filo uma subdiviso do Reino. Possui
29
8 reinos; procurando respeitar a famosa regra de George Miller do "sete mais ou menos
dois"6 . So eles:
Erro de validao e de representao Resultam da confiana indevida nos dados de
entrada. Caso do Buffer Overflow, injeo de SQL, XSS.
Abuso de API Sendo a API um contrato entre quem chama a rotina e aquela que
chamada, uma quebra das regras pode resultar em problemas de segurana. Quando
quem chama uma funo assume certas condies que no esto garantidas pela
rotina chamada, temos um caso de abuso de API.
Mesmo tendo sido criado recentemente, tendo menos de 5 anos completos, o projeto
do CWE certamente j est trazendo contribuies para a padronizao na rea de
classificao de vulnerabilidades. A esperana que ele se fortalece e possibilite uma
referncia de grande valor assim como foi estabelecido com o CVE.
Framework aberto A abertura permite que os usurios tenham livre acesso para
compreenderem as razes das vulnerabilidades assumirem esse ou aquele escore.
7
http://cwe.mitre.org/
31
CERT/CC
Cisco
DHS/MITRE
eBay
Microsoft
Qualys
Symantec
Sua primeira verso data de 2005. Desde 2007, j se encontra na segunda verso; tratada
em (MELL, 2007). Nesse trabalho, abordaremos apenas a verso atual do CVSS.
Na tabela 3.2, so mostradas as mtricas usadas subdivididas nos seus respectivos grupos.
A seguir, faremos breve explicao de cada uma das mtricas dos trs grupos - vide
tabela 3.2. Para o grupo bsico, existem seis critrios. So eles:
CVSS
Mtricas bsicas Mtricas Temporais Mtricas Ambientais
Vetor de acesso Facilidade de explorao Dano colateral potencial
Complexidade de acesso Confiabilidade no report Abundncia de alvos
Necessidade de autenticao Nvel de remediao Importncia da confidencialidade
Impacto na confidencialidade Importncia da integridade
Impacto na integridade Importncia da disponibilidade
Impacto na disponibilidade
Tabela 3.2: Mtricas CVSS por grupo
Nvel de remediao Determina o quo longe se est de uma medida definitiva para
estancamento da vulnerabilidade. Logo que o problema surge, assume o valor
indisponvel. Se houver alguma forma, no oficial, de mitigar a vulnerabilidade,
dito que a remediao est no estgio de workaround . Se existe alguma medida
oficial, mas ainda no definitiva, seu valor conserto temporrio. O nvel
mximo, portanto assumindo o escore mnimo, conserto definitivo, caso exista
uma remediao de carter oficial definitiva.
Dano colateral potencial Mede o potencial do estrago que a vulnerabilidade pode causar
organizao. Podem ser danos patrimoniais, pessoais ou relativos a ganhos
financeiros. Assume os valores(do menor para o maior dano potencial): nenhum,
baixo, baixo-mdio, mdio-alto e alto.
1. Para cada um dos critrios descritos na Seo 3.4.2, atribuir um valor vlido.
34
Figura 3.2: Aplicao das mtricas e equaes do CVSS. Fonte: (MELL, 2007)
3. Fazer o clculo do escore bsico usando a equao A.1. Para isso, necessrio
resolver antes as equaes A.3 e A.2 antes.
4. Fazer o clculo do escore temporal usando sua respectiva equao - A.4 - e o escore
bsico. Passo opcional. possvel manter apenas o escore bsico como o final.
4 EXPLOITS
No presente captulo, ser feita uma breve anlise sobre exploits. importante
salientar que, apenas conhecendo as tcnicas usadas pelos atacantes torna-se possvel
criar defesas efetivas contra elas. Portanto, o estudo dessa matria no constitui, de
forma alguma, uma apologia ao ataque. Essa questo muito bem abordada na parte
I de (HARRIS, 2008); deixando claro que o conhecimento uma arma importantssima
para aqueles que buscam uma melhoria na segurana do software.
Como ponto de partida, ser aprofundado o conceito de exploit. De forma a mostrar
sua amplitude e sua intrnseca relao com as vulnerabilidades. A seguir, sero explicadas
algumas tcnicas que so representativas para uma viso ampla do assunto. Na sequncia,
sero abordados princpios bsicos de programao que visam prevenir a aplicao de
exploits no software - combatem as falhas na origem e pontos de apoio usados pelas
tcnicas dos atacantes. Por fim, sero apresentadas algumas das protees j existentes
para barrar os ataques; em certos casos, tambm sero mostradas as formas de escape que
os atacantes j desenvolveram como reao.
Como no ser detalhada nenhuma tcnica em particular nesse captulo, para se
obter um exemplo mais aprofundado de exploit, o NULL pointer exploit ser o tema do
captulo seguinte. Assim, aps um acompanhamento mais amplo do tema, ser possvel
compreender melhor um caso especfico.
4.1 Definio
Conforme foi tratado na Seo 2.1, o exploit um conjunto de passos, muitas vezes
materializado em um programa, capaz de tirar proveito de uma vulnerabilidade. Para
muitos, entretanto, exploit sinnimo de um cdigo em C escrito por um hacker que tem
o potencial de atacar um sistema. Essa viso, todavia, muito limitada. Assim como
existem diversos tipos de vulnerabilidades, h muitos meios de tirar vantagem delas. Por
vezes, basta conhecer uma srie de passos, como cliques na interface da aplicao alvo,
para para explorar uma falha.
Em (HOGLUND, 2004), encontramos a seguinte lista de possveis consequncias para
um exploit bem sucedido:
Escalada de privilgios;
4.2 Tipos
Nessa Seo, ser feita uma breve explicao sobre alguns tipos de exploits existentes.
Isso para que o leitor possa ter uma noo geral sobre as tcnicas usadas pelos atacantes
para explorar as vulnerabilidades no software. No , de forma alguma, uma lista
exaustiva, mas contm muitos exemplos significativos.
Abaixo, lista dos tipos abordados:
Buffer overflow;
Heap overflow;
Injeo de SQL;
XSS(Cross Site Scripting);
Essa tcnica tira proveito desse fato. Caso a aplicao possua alguma falha que
permita que o usurio fornea dados maiores que o espao alocado na pilha para
armazen-los, o excedente acaba sobrescrevendo o endereo de retorno da funo.
o exemplo claro de ataque control-data. A mudana em um dado de controle do
stack frame permite a colocao de um endereo forjado pelo atacante para mudar o
fluxo de execuo do programa atacado.
Na verso "clssica"desse exploit, o atacante fornece cdigo executvel, shellcode,
que vai alm do buffer criado para armazen-lo. No final dos dados enviados, tambm
inserido o endereo de incio do buffer, que agora contm o cdigo do atacante, para
substituir no stack frame o valor de retorno da funo. Assim, no retorno o fluxo
desviado para o buffer com o shellcode. A figura 4.1 mostra uma viso simplificada
da pilha antes e depois do ataque.
A execuo bem sucedida desse ataque depende de uma srie de acertos. Um deles
a descoberta do endereo do shellcode inserido no buffer. Isso porque a execuo deve
ser desviada para l; por isso esse valor deve substituir o endereo de retorno da funo.
Esses e outros desafios so pontos cruciais para a tcnica. Como nessa seo desejamos
fornecer apenas um viso geral, aconselhamos a busca de boas abordagens para o assunto
em (ANLEY, 2007) e (FURLAN, 2005).
que no verifique devidamente os dados que lhe so fornecidos sria candidata a ser
explorada. No possvel confiar em nada que advm de qualquer ponto externo ao
sistema. Conforme visto anteriormente, ataques como o de buffer overflow ou de heap
overflow esto diretamente ligados a uma validao incorreta(ou mesmo ausente) de
dados de entrada. O mesmo ocorrendo para injeo de SQL ou XSS.
Para que essa prtica seja bem aplicada, essencial que sejam levantados todos os
vetores de entrada de uma aplicao. Por vezes, alguns deles podem ser esquecidos. No
ambiente UNIX, por exemplo, variveis de ambiente tambm devem ser consideradas
dados de entrada. Entretanto, nem sempre so devidamente validadas. Nesse aspecto,
toda uma preocupao com a entrada do sistema pode ser perdida se restar apenas um
ponto no verificado. Por isso a exigncia de uma avaliao dos pontos que devem ser
protegidos.
Para ilustrar ainda melhor, podemos tomar como exemplo um sistema que faa uso de
DNS reverso2 . Se, para um dado IP, no for validado o nome retornado pelo DNS reverso,
um atacante pode, uma vez que tenha comprometido parte da rede, forar a aplicao a
utilizar dados imprprios. Se a aplicao do exemplo usar diretamente o resultado, ela
corre srios riscos de sofrer algum tipo de explorao - como um buffer overflow.
, fundamental, portanto, que os pontos de entrada sejam identificados e sejam
definidas formas de validao. Em (SECURE SOFTWARE, 2006), anexo B, h detalhes
sobre esse tpico - definindo diretivas para a validao.
1. Pilha no executvel;
4.4.2 W X
Impedir que memria com proteo de escrita seja executvel e, bloquear a escrita
para aquela que executvel uma das melhores formas de proteo. Ataca justamente
42
Figura 4.2: Stack frame protegido por canrio. Fonte: (FURLAN, 2005).
Figura 4.3: Modelo de pilha ideal para o SSP. Fonte: (MARTINS, 2009).
4.4.5 ASLR
O Address Space Layout Randomization implementa uma randomizao dos
endereos de forma a dificultar enormemente a vida dos atacantes. Bibliotecas e rotinas
passam a ter endereos aleatrios e os saltos necessrios para esses endereos ficam muito
mais complexos de serem realizados.
Conforme explicado anteriormente, vrios exploits dependem de um conhecimento
prvio dos endereos. Portanto, essa aleatoriedade muito interessante como forma de
proteo genrica. Sua fraqueza, porm, conforme (ANLEY, 2007), est no fato de bastar
algum endereo fixo para que ela no tenha efeito algum. Mas nem sempre necessrio
que haja algo fixo; h uma tcnica chamada heap spraying que capaz de driblar o
ASLR. Ela injeta vrias pores de cdigo executvel na aplicao alvo para que, mesmo
desconhecendo um endereo preciso, a chance de que ele seja encontrado venha a ser
muito maior.
H mais detalhes sobre heap spraying em (RATANAWORABHAN, 2008). No
referido trabalho, inclusive, sugerido um verificador de heap que procura impedir que
esse tipo de ataque seja aplicado. Isso feito atravs da deteco do padro imposto pela
44
tcnica de spraying, j que ela cria objetos na memria contendo cdigo executvel.
45
Dentre as vrias tcnicas de exploits existentes, uma que certamente merece destaque,
o NULL pointer exploit. Sua disseminao recente, sendo fruto da crescente
dificuldade em aplicar tcnicas que exploram vulnerabilidades de corrupo de memria.
Um marco para esse tipo de exploit certamente foi o artigo de Mark Dowd (DOWD,
2008). A forma como ele trouxe luz uma falha na mquina virtual do ActionScript
chamou a ateno de diversos especialistas na rea. Isso porque, para muitos, o NULL
pointer era apenas sinnimo de um bug que resultaria, no mximo, em uma negao de
servio. Por isso, o raciocnio empregado por ele serviria de base para encontrar muitos
outros problemas.
O ano de 2009 chegou a ser considerado o ano do "kernel NULL pointer deference"em
virtude da grande quantidade de falhas desse gnero encontradas no kernel do Linux.
Como podemos encontrar em, (COX, 2010), a lista de problemas causados por esse
tipo de vulnerabilidade foi extensa. Para sistemas Linux Red Hat, por exemplo, ainda
conforme (COX, 2010), o NULL pointer foi considerado o grande vilo de 2009 com 6
vulnerabilidades.
Nesse captulo, nossa inteno apresentar esse tipo de vulnerabilidade e seu
correspondente exploit. Assim como identificar os meios de deteco e preveno.
Os dados a serem gravados podem ser controlados de alguma forma pelo usurio
Abaixo, ilustrando o que foi exposto, um pequeno trecho de cdigo em linguagem C.
Nele, o usurio fornece dados, mas como o endereo base de destino de uma cpia
est zerado, possvel influenciar diretamente na escolha de onde so gravados. Essa
vulnerabilidade implica a condio do atacante de gravar em um endereo arbitrrio dados
que ele pode controlar - que pode ser um shellcode.
Listing 5.2: Ponteiro em C
1 / user input at user_data /
2 write_address = null_pointer + offset_influenced_by_user ;
3 / t h e a d d r e s s h a s b e e n c h o s e n by t h e u s e r /
4
5 memcpy ( w r i t e _ a d d r e s s , u s e r _ d a t a , c e r t a i n _ s i z e ) ;
6 / d a t a i s c o p i e d f r o m one p o i n t t o
7 another according to user s w i l l /
possvel mapear para o endereo zero uma regio vlida de memria contendo
dados do usurio
Com esses pontos bsicos atendidos, h condies para o emprego da tcnica. Como
exemplo maior, mostraremos um bug no Kernel do Linux na seo 5.3.
Na linha 14, feito uma alocao de um bloco de memria iniciado no endereo zero;
nele posto o shellcode. J a operao que desencadeia o erro encontra-se na linha 31.
50
26 }
27
28 static int
29 pipe_write_open ( s t r u c t inode inode , s t r u c t f i l e f i l p )
30 {
31 + i n t r e t = ENOENT ;
32 +
33 m u t e x _ l o c k (& i n o d e >i _ m u t e x ) ;
34 i n o d e > i _ p i p e > w r i t e r s ++;
35 +
36 + i f ( i n o d e > i _ p i p e ) {
37 + r e t = 0;
38 + i n o d e > i _ p i p e > w r i t e r s ++;
39 + }
40 +
41 m u t e x _ u n l o c k (& i n o d e >i _ m u t e x ) ;
42
43 return 0;
44 + return r e t ;
45 }
46
47 static int
48 pipe_rdwr_open ( s t r u c t inode inode , s t r u c t f i l e f i l p )
49 {
50 + i n t r e t = ENOENT ;
51 +
52 m u t e x _ l o c k (& i n o d e >i _ m u t e x ) ;
53 i f ( f i l p >f_mode & FMODE_READ)
54 i n o d e > i _ p i p e > r e a d e r s ++;
55 i f ( f i l p >f_mode & FMODE_WRITE)
56 i n o d e > i _ p i p e > w r i t e r s ++;
57 +
58 + i f ( i n o d e > i _ p i p e ) {
59 + r e t = 0;
60 + i f ( f i l p >f_mode & FMODE_READ)
61 + i n o d e > i _ p i p e > r e a d e r s ++;
62 + i f ( f i l p >f_mode & FMODE_WRITE)
63 + i n o d e > i _ p i p e > w r i t e r s ++;
64 + }
65 +
66 m u t e x _ u n l o c k (& i n o d e >i _ m u t e x ) ;
67
68 return 0;
69 + return r e t ;
70 }
71
72 /
Vemos que nas linhas 16 a 21 temos a insero de uma verificao do ponteiro i_pipe.
52
Embora o foco do presente trabalho recaia sobre a arquitetura x86, vlido identificar
a repercusso de um acesso a posio zero de memria em outros casos. Existem
arquiteturas nas quais esse endereo j mapeado inicialmente. Podemos apontar o caso
da ARM e da XScale; ambas para sistemas embarcados. Nelas, o vetor de excees se
encontra nessa posio. Ele contm, por exemplo, o endereo que define o vetor para o
tratamento das interrupes de software.
Essa vulnerabilidade, tratada por Barnaby Jack, pesquisador de segurana da
Juniper, em (JACK, 2007). Conforme Jack, caso alguma aplicao nas arquiteturas
em questo possua alguma falha na qual o endereo de destino de uma escrita seja
um ponteiro nulo, o vetor de excees acaba sendo sobrescrito. Isso potencializa
enormemente um erro de NULL pointer.
Como exemplo, em (JACK, 2007), apresentada uma falha na biblioteca libpng.
Um tratamento inadequado da alocao de memria para imagens, que retornava NULL,
permitia que os dados de uma imagem fossem copiados via memcpy() para o endereo
zero. Por esse caminho, um atacante seria capaz de sobrescrever a tabela de endereos de
interrupes de software. Assim, bastaria uma chamada do sistema em virtude de uma
interrupo, para que o cdigo injetado pudesse ser executado.
Segundo avaliao de Jack, uma das formas de prevenir esse tipo de ataque no
permitir a escrita na rea do vetor de excees. Outra medida sugerida, e existente em
verses posteriores das arquiteturas, como ARM9, a possibilidade de mapeamento do
vetor de excees para endereos mais altos - como 0xFFFF00000. De qualquer forma,
no resta dvida que os projetistas cometeram srio equvoco nas escolhas envolvidas no
vetor de excees.
53
5.4.3 Testes
Toda e qualquer forma de teste contribui direta ou indiretamente para a deteco desse
tipo de falha. Mas essencial que a aplicao seja examinada sob a tica de testes
de requisitos negativos. No captulo 6, que trata de Fuzzing, so apresentadas diversas
formas de testes que podem auxiliar.
possvel, por exemplo, testar a aplicao simulando falhas na alocao de memria.
De tal forma que, certas requisies de memria propositalmente retornem NULL.
Com esse tipo de cenrio, situaes inusitadas podem ser criadas com facilidade.
Analogamente, outras bibliotecas tambm podem ser substitudas por verses de teste
que gerem contextos nos quais a aplicao forada a tratar ponteiros nulos.
No caso da vulnerabilidade CVE-2009-2692, analisada em 5.3.2, situaes que
simulassem uma falha no envio de um arquivo, como no exploit apresentado para
CVE-2009-2692, seriam suficientes para detectar o problema. Isto porque ocorreria a
falha na chamada a funo cujo ponteiro estaria nulo. Por isso a enorme necessidade de
testes, notoriamente aqueles que criem contextos em que falhas sejam inseridas.
55
6.3.1 Cobertura
Quais partes do cdigo da aplicao testado so testadas. Esse conceito retrata um dos
objetivos bsicos de qualquer tipo de teste. A necessidade de cobrir o mximo possvel o
cdigo da aplicao alvo.
Monitoramento do alvo
bugs que no implicam possibilidade de exploit. Por isso a necessidade de uma anlise
detalhada e qualificada para que as reais aberturas no sistema avaliado sejam encontradas.
a tcnica fuzzing sequer se apoiava no cdigo fonte para busca de qualquer tipo de
auxlio no aumento de sua efetividade. Com o tempo, porm, foi possvel perceber
que, partindo de certas informaes do funcionamento interno da aplicao, os resultados
obtidos poderiam ser melhores. Vindo do outro extremo, o White Fuzz Testing no apenas
faz uso do cdigo fonte, mas o executa simbolicamente - sendo totalmente caixa branca.
6.7.3 Limitaes
Teoricamente, com a aplicao do Whitebox Fuzz, possvel alcanar O alcance de
uma cobertura completa fica limitado, segundo os autores, por dois fatores:
7 CONCLUSO
REFERNCIAS
HARRIS, S. Gray Hat Hacking: the ethical hackers handbook. [S.l.]: McGraw, 2008.
JACK, B. Vector Rewrite Attack: exploitable null pointer vulnerabilities on arm and
xscale architectures. Juniper, [S.l.], 2007.
LOVE, R. Linux System Programming. 1a .ed. [S.l.]: OReilly Media, Inc., 2007.
MELL, P. CVSS: a complete guide to the common vulnerability scoring system version
2.0. Disponvel em: http://www.first.org/cvss/cvss-guide.pdf. Acessado em: Junho 2010.
65
TAKANEM, A. Fuzzing for Software Security Testing and Quality Assurance. [S.l.]:
Artech House, INC., 2008.
Mtricas bsicas
Mtrica Valor nominal Valor numrico
local 0.395
Vetor de acesso rede adjacente 0.646
rede 1.0
alta 0.35
Complexidade de acesso mdia 0.61
baixa 0.71
vrias 0.45
Necessidade de autenticao uma 0.56
nenhuma 0.704
nenhum 0.0
Impacto na confidencialidade parcial 0.275
completo 0.660
nenhum 0.0
Impacto na integridade parcial 0.275
completo 0.660
nenhum 0.0
Impacto na disponibilidade parcial 0.275
completo 0.660
Mtricas temporais
Mtrica Valor nominal Valor numrico
no comprovada 0.85
prova de conceito 0.9
Facilidade de explorao funcional 0.95
alta 1.0
no definida 1.0
conserto definitivo 0.87
conserto temporrio 0.90
Nvel de remediao workaround 0.95
indisponvel 1.0
no definido 1.0
no confirmada 0.9
no corroborada 0.95
Confiabilidade no report
confirmada 1.0
no disponvel 1.0
68
Mtricas ambientais
Mtrica Valor nominal Valor numrico
nenhum 0.0
baixo 0.1
baixo-mdio 0.3
Dano colateral potencial
mdio-alto 0.4
alto 0.5
no definido 0
nenhuma 0
baixa 0.25
Abundncia de alvos
mdia 0.75
alta 1.0
no definida 1.0
baixa 0.5
mdia 1.0
Importncia da confiabilidade
alta 1.51
no definida 1.0
baixa 0.5
mdia 1.0
Importncia da integridade
alta 1.51
no definida 1.0
baixa 0.5
mdia 1.0
Importncia da disponibilidade
alta 1.51
no definida 1.0