UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMTICA
CINCIA DA COMPUTAO

CSAR MALERBA

Vulnerabilidades e Exploits: tcnicas,

deteco e preveno

Prof. Dr. Raul Fernando Weber

Orientador

Porto Alegre, Junho de 2010

If I have seen farther than others,

it is because I stood on the shoulders of giants.
S IR I SAAC N EWTON

AGRADECIMENTOS

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

LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . .

LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

ABSTRACT

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
Organizao do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . .

12
13

2 CONCEITOS INICIAIS . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
Vulnerabilidade/Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Pressupostos bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Memria Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1
Como usada na arquitetura x86 . . . . . . . . . . . . . . . . . . . . . .
2.3.2
Segmentao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3
Paginao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4
Caso abordado: memria virtual no sistema Linux x86 . . . . . . . . . .
2.4
Gerncia de memria . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5
Funcionamento mais detalhado do Stack . . . . . . . . . . . . . . . . . .
2.5.1
Chamada de funes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6
Funcionamento mais detalhado do heap . . . . . . . . . . . . . . . . . .
2.7
Mapemamento de memria annimo . . . . . . . . . . . . . . . . . . . .
2.8
Registradores de controle . . . . . . . . . . . . . . . . . . . . . . . . . .
2.9
Shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14
14
14
14
15
16
16
17
17
19
19
19
20
20
20

3 CLASSIFICAO DE VULNERABILIDADES . . . . . . . . . . . . . .
3.1
A dificuldade em classificar; estgio j alcanado: enumerao . . . . .
3.1.1
Classificar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2
Enumerar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3
Da enumerao classificao . . . . . . . . . . . . . . . . . . . . . . .
3.2
CVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1
Surgimento e objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2
Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Propostas taxonmicas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1
Histrico das propostas . . . . . . . . . . . . . . . . . . . . . . . . . . .

22
22
22
23
23
24
24
24
25
26

3.3.2
Taxonomias e classificaes mais recentes
3.3.3
O projeto CWE . . . . . . . . . . . . . .
3.4
Mtricas para vulnerabilidades: CVSS . .
3.4.1
Surgimento do CVSS . . . . . . . . . . .
3.4.2
As mtricas usadas . . . . . . . . . . . .
3.4.3
Clculo do escore . . . . . . . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

27
29
30
30
31
33

4 EXPLOITS . . . . . . . . . . . . . . . . . . . . . . . .
4.1
Definio . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1
Buffer Overflow . . . . . . . . . . . . . . . . . . . .
4.2.2
Heap Overflow . . . . . . . . . . . . . . . . . . . .
4.2.3
Injeo de SQL . . . . . . . . . . . . . . . . . . . .
4.2.4
XSS (Cross Site Scripting) . . . . . . . . . . . . . .
4.3
Preveno de ataques . . . . . . . . . . . . . . . . . .
4.3.1
Validao de dados de entrada . . . . . . . . . . . .
4.3.2
Ferramentas de anlise esttica e auditoria de cdigo
4.4
Protees e contra-protees . . . . . . . . . . . . . .
4.4.1
Pilha no executvel . . . . . . . . . . . . . . . . . .
4.4.2
W X . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3
Canrio para a pilha . . . . . . . . . . . . . . . . . .
4.4.4
Reordenamento de variveis na pilha . . . . . . . . .
4.4.5
ASLR . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .

35
35
36
36
37
38
39
39
39
40
41
41
41
42
43
43

5 NULL POINTER EXPLOIT . . . . . . . . .

5.1
O que um NULL pointer . . . . . . . . .
5.2
Como funciona a tcnica . . . . . . . . . .
5.2.1
Ponteiro nulo de escrita . . . . . . . . . .
5.2.2
Ponteiro nulo de funo . . . . . . . . . .
5.3
Exemplos reais de NULL pointer exploit .
5.3.1
Falha na mquina virtual do ActionScript
5.3.2
Falhas no kernel do Linux . . . . . . . . .
5.3.3
NULL pointer em ARM e XScale . . . .
5.4
Como evitar o problema . . . . . . . . . .
5.4.1
Decises estruturais . . . . . . . . . . . .
5.4.2
Programao consciente . . . . . . . . . .
5.4.3
Testes . . . . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .

45
45
46
46
47
47
48
48
52
53
53
53
54

6 FUZZING: DETECO DE VULNERABILIDADES

6.1
O que fuzzing? . . . . . . . . . . . . . . . . . . .
6.2
Origens e breve histrico . . . . . . . . . . . . . . .
6.2.1
Uso do conceito antes do surgimento oficial . . . .
6.2.2
O surgimento oficial . . . . . . . . . . . . . . . . .
6.2.3
O desenvolvimento da tcnica . . . . . . . . . . . .
6.3
Conceitos importantes . . . . . . . . . . . . . . . .
6.3.1
Cobertura . . . . . . . . . . . . . . . . . . . . . .
6.3.2
Superfcie de ataque . . . . . . . . . . . . . . . . .
6.4
Etapas Fuzzing . . . . . . . . . . . . . . . . . . . .
6.4.1
Identificao das entradas . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.

. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .

55
55
56
56
56
56
56
56
56
57
57

6.4.2
Gerao das entradas . . . . . . . . . . . . . . .
6.4.3
Envio das entradas . . . . . . . . . . . . . . . . .
6.4.4
Monitoramento do alvo . . . . . . . . . . . . . .
6.4.5
Anlise dos resultados . . . . . . . . . . . . . . .
6.5
Tipos de fuzzers . . . . . . . . . . . . . . . . . . .
6.5.1
Tipos por vetor de ataque . . . . . . . . . . . . .
6.5.2
Tipos por complexidade de casos de teste . . . .
6.6
Monitoramento da aplicao . . . . . . . . . . .
6.6.1
Meios intrusivos . . . . . . . . . . . . . . . . . .
6.7
White Fuzz Testing: execuo simblica e fuzzing
6.7.1
Deficincias do mtodo caixa preta . . . . . . . .
6.7.2
Funcionamento bsico . . . . . . . . . . . . . . .
6.7.3
Limitaes . . . . . . . . . . . . . . . . . . . . .
6.7.4
SAGE: implementao da tcnica . . . . . . . . .
7

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

57
57
57
57
58
58
58
59
59
59
60
60
61
61

CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

APNDICE A EQUAES CVSS 2.0

A.1 Equaes do escore bsico . . . . .
A.2 Equaes do escore temporal . . .
A.3 Equaes do escore ambiental . . .

66
66
66
66

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .

LISTA DE ABREVIATURAS E SIGLAS

ASLR

Address Space Layout Randomization

EBP

Extended Base Pointer

ESP

Extended Stack Pointer

CVE

Common Vulnerabilities and Exposures

CVSS

Common Vulnerability Scoring System

CPU

Central Processing Unit

CWE

Common Weakness Enumeration

DNS

Domain Name Service

DoS

Denial of Service

DPL

Descriptor Privelege Level

NUMA Non-Uniform Memory Access

RAM

Random Access Memory

RPC

Remote Procedure Call

SQL

Structered Query Language

SSP

Stack-Smashing Protector

SWF

Shockwave Flash

LISTA DE FIGURAS

Figura 2.1:
Figura 2.2:
Figura 2.3:
Figura 2.4:

Esquema de memria virtual. Fonte: Wikepedia - Junho 2010. . . . .

Processamento de endereo na arquitetura x86. Fonte: (BOVET, 2005)
Regies de memria em um processo. . . . . . . . . . . . . . . . . .
Organizao do frame na pilha. Fonte: (FURLAN, 2005) pg. 17. . .

15
16
18
19

Figura 3.1:
Figura 3.2:

Vulnerabilidades registradas no CVE a cada ano entre 1999 e 2008.

Fonte: (FLORIAN, 2009) . . . . . . . . . . . . . . . . . . . . . . .
Aplicao das mtricas e equaes do CVSS. Fonte: (MELL, 2007) .

25
34

Figura 4.1:
Figura 4.2:
Figura 4.3:

Esquema da pilha no buffer overflow. Fonte: (MARTINS, 2009). . .

Stack frame protegido por canrio. Fonte: (FURLAN, 2005). . . . .
Modelo de pilha ideal para o SSP. Fonte: (MARTINS, 2009). . . . . .

37
42
43

LISTA DE TABELAS

Tabela 2.1:

Quatro segmentos principais no Linux com seus descritores . . . . .

17

Tabela 3.1:
Tabela 3.2:

Uma vulnerabilidade: diversos nomes e nenhum entendimento . . . .

Mtricas CVSS por grupo . . . . . . . . . . . . . . . . . . . . . . .

24
32

RESUMO

A importncia do software em nossa sociedade aumenta a cada dia. Entretanto, ele

ainda sofre com vrios problemas de segurana - a maioria deles relacionados ao seu
desenvolvimento. Para auxiliar os desenvolvedores no entendimento dessa matria, esse
trabalho trata de pontos chave na segurana do software: vulnerabilidades e exploits.
Dois temas principais relacionados a vulnerabilidades so apresentados: mtodos de
classificao e deteco atravs da tcnica fuzzing. Ambos objetivando fornecer ao leitor
conceitos bsicos para o alcance de um desenvolvimento mais seguro e consciente do
software. Dado o enorme valor da tcnica fuzzing na descoberta de vulnerabilidades, ela
proposta como nova ferramenta aos desenvolvedores para que eles a apliquem antes dos
atacantes.
Considerando que o conhecimento de tcnicas de exploits indispensvel na busca
por software mais seguro, esse trabalho tambm tenta oferecer ao leitor uma viso a partir
da perspectiva dos atacantes. Para isso, uma viso geral dos exploits apresentada. Aps
uma ideia mais ampla nos mtodos dos atacantes, um deles detalhado: o NULL pointer
exploit.

Palavras-chave: Segurana, teste de software, exploits.

Exploits: tcnicas, deteco e preveno

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.

Keywords: security, exploits, testing.

12

INTRODUO

A Internet...foi projetada no esprito da confiana. Nem os protocolos de rede

de comunicaes nem o software que comanda os sistemas computacionais(nodos)
conectados a rede foram arquitetados para operao num ambiente no qual esto sob
ataque.(COMMITTEE, 2005). Esse trecho1 foi extrado de um report criado pelo comit
consultivo sobre tecnologia da informao do presidente dos Estados Unidos. Sua
inteno chamar ateno para um problema que amea todos os pases do mundo e
que, sem o devido tratamento, pode trazer graves consequncias s naes.
Esse mesmo documento vai alm e adverte para as consequncias da insegurana:
Apesar dos recentes esforos para adicionar componentes de segurana aos sistemas
computacionais, s redes e ao software, os atos hostis se propagam largamente causando
danos em escala nacional e internacional. Conforme os consultores, o elo mais fraco da
cadeia o software. Os mtodos de desenvolvimento de software...falham em prover a
alta qualidade, a confiabilidade e a segurana das quais os ambientes de tecnologia da
informao necessitam.
Logo, de acordo com os estudos estratgicos de defesa da nao mais poderosa do
mundo, um dos seus pontos mais vulnerveis o software que compe seus sistemas.
E mais, o processo de desenvolvimento considerado como fator predominante para
a existncia dessa ameaa. E, claro, diante da crescente ubiquidade dos sistemas de
computao e, por consequncia, do software, aumenta ainda mais a responsabilidade
dos projetistas e dos desenvolvedores em garantir que seu trabalho no ser utilizado em
prejuzo dos usurios.
Por isso fundamental que todos aqueles envolvidos no processo de produo do
software tenham o devido conhecimento das implicaes relativas segurana. Conhecer
as vulnerabilidades e saber como detect-las acabam sendo habilidades necessrias para
garantir projetos seguros.
Outra forma de contribuir para atenuao dessa ameaa, conhecer as tticas
aplicadas pelos atacantes. Pois: quanto mais se sabe sobre o que o seu inimigo capaz de
fazer, maior a sua condio de discernir sobre quais mecanismos so necessrios para
sua prpria defesa - (HARRIS, 2008). O conhecimento das tcnicas de ataque constitui,
portanto, mais uma das dimenses que compem uma estratgia de defesa.
O foco do presente trabalho gira em torno de dois conceitos abordados anteriormente:
vulnerabilidade e exploits. Ambos so apresentados e sob a tica do desenvolvedor de
sistemas e do atacante num esforo para contextualizar o leitor sobre os caminhos para
tornar o software mais seguro.
1

Extratos de (COMMITTEE, 2005) foram traduzidos livremente pelo autor do presente trabalho.

13

1.1

Organizao do trabalho

Para alcanar o objetivo proposto, esse trabalho est organizado da seguinte forma.
Inicia com conceitos bsicos que servem de suporte aos captulos seguintes. So
definies de termos usados e informaes bsicas sobre o funcionamento do software
- como organizao da memria dos processos, virtualizao da memria, entre outros.
No terceiro captulo, abordado o tpico de classificao de vulnerabilidades. Nele,
o leitor ter contato com propostas e projetos que auxiliam o estudo dessa matria.
O quarto captulo traz uma viso geral sobre tcnicas de explorao de
vulnerabilidades: os exploits. So trazidos tipos que possuem boa representatividade.
Para ilustrar com maior preciso os conceitos de vulnerabilidade e de exploit na
prtica, apresentado em maior detalhes o NULL pointer exploit. Tpico que assume
bastante relevncia uma vez que uma srie de falhas desse gnero foram recentemente
descobertas - muitas delas no Kernel do Linux, onde permaneceram por mais de 8 anos.
O ltimo captulo aborda uma tcnica para deteco de vulnerabilidades: Fuzzing.
Foi escolhida entre as demais para constar nesse trabalho pois possui excelente relao
custo benefcio. destacada com o intuito de mostrar aos desenvolvedores os eficientes
mtodos empregados pelos atacantes para encontrar problemas no software.

14

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.

2.2

Pressupostos bsicos

Neste trabalho iremos tratar principalmente de exploits na arquitetura x86 de 32 bits.

Trata-se da arquitetura de computadores pessoais mais difundida nos dias de hoje. Mas
boa parte do estudo realizado pode ser aplicada a praticamente qualquer outra arquitetura.
Dessa forma, principalmente quando tratarmos de erros de corrupo de memria,
lembramos que as discusses sero feitas com a arquitetura x86 de 32 bits em mente.
Sendo devidamente sinalizado quando forem examinados aspectos de outros casos.

2.3

Memria Virtual

Para facilitar o entendimento de questes discutidas nesse trabalho, importante

esclarecer pontos bsicos sobre uso do esquema de memria virtual na arquitetura x86.
Isso nos permitir entender melhor as alternativas existentes para a implementaes do
sistemas bem como as relaes com as vulnerabilidades e exploits. Primeiro repassamos
as motivaes e o funcionamento bsico da memria virtual. Entre suas vantagens,
conforme (BOVET, 2005), encontramos:

15

Figura 2.1: Esquema de memria virtual. Fonte: Wikepedia - Junho 2010.

possvel executar aplicaes que necessitam mais memria que a disponvel

fisicamente
Processos podem compartilhar uma nica imagem na memria de uma biblioteca
As aplicaes podem ser realocadas na memria fsica em qualquer lugar
Um processo pode ser executado com apenas parte de seu cdigo carregado em
memria fsica
Cada processo tem a disposio seu prprio espao de endereamento como se
fosse a nica aplicao no sistema
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.
2.3.1

Como usada na arquitetura x86

Na arquitetura x86, a virtualizao da memria implementada com segmentao e

paginao. Na segmentao, a memria dividida em segmentos de tamanho varivel;
sendo o endereo virtual um identificador de segmento e um offset. No caso da paginao,
a diviso da memria feita em pginas de tamanho fixo e, analogamente, o endereo
virtual composto de um identificador para a pgina e um offset. Os dois modelos no
so excludentes bem como podem ser usados independentemente. Nesse caso, foi optado
pela presena de ambos. Assim, possvel dividir a memria em segmentos que por sua
vez podem ser particionados em diferentes pginas.

16

Figura 2.2: Processamento de endereo na arquitetura x86. Fonte: (BOVET, 2005)

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:
Base Endereo linear inicial do segmento.
Limite Endereo linear final do segmento.
Tipo Os tipos definem as propriedades de acesso como leitura, escrita e execuo.
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.
Naturalmente, podem existir segmentos distintos para o sistema operacional e para as
aplicaes do usurio. Assim, aqueles pertencentes ao sistema ficam com DPL em zero,
enquanto os demais ficam marcados como 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:
Leitura/Escrita Indica se a pgina possui permisso de leitra e/ou escrita.
User/Supervisor flag De forma anloga ao DPL na segmentao, define o privilgio
mnimo exigido para o acesso.

17

Segmento
Cdigo do usurio
Dados do usurio
Cdigo do kernel
Dados do kernel

Base
Limite
Tipo
DPL
0x00000000 0xfffff
Leitura
3
0x00000000 0xfffff Escrita/Leitura
3
0x00000000 0xfffff
Leitura
0
0x00000000 0xfffff Escrita/Leitura
0

Tabela 2.1: Quatro segmentos principais no Linux com seus descritores

Ao ocorrer algum problema no acesso a alguma pgina, como falta de privilgios
ou mesmo porque uma pgina no est mapeada fisicamente, o sistema operacional
chamado atravs de uma interrupo de hardware. Dessa forma, ele pode tomar as
medidas necessrias como: cancelar a aplicao que realizou um acesso ilegtimo ou
buscar fazer o mapeamento da pgina que falta aplicao. Com a cooperao do
hardware e do sistema, fica possvel implantar a memria virtual com paginao.
2.3.4

Caso abordado: memria virtual no sistema Linux x86

Conforme veremos na seo 5.3.2, a escolha no uso da memria virtual no sistema

Linux trouxe impactos sobre sua segurana. Nesse sistema, o uso da segmentao
extremamente limitado. A paginao foi escolhida em detrimento segmentao - sendo
a ltima usada apenas por obrigatoriedade da arquitetura. Os segmentos de dados e cdigo
para o sistema operacional e para as aplicaes do usurio so praticamente os mesmos.
A tabela 2.1 apresenta os principais segmentos.
Embora isso tenha vantagens em termos de desempenho, pois facilita a troca de
contexto entre modo usurio e modo do sistema bem como a troca de dados entre ambos,
h uma desvantagem de segurana. Tanto o kernel as aplicaes do usurio podem usar
os mesmos endereos lgicos. Certas restries de segurana acabam recaindo, portanto,
apenas para a paginao.

2.4

Gerncia de memria

O controle da memria um ponto crtico. Falhas nele acabam resultando em

vulnerabilidades gravssimas. Faremos uma breve abordagem sobre o gerenciamento de
memria sobre o ponto de vista dos exploits.
Um primeiro ponto a destacar sobre a memria um princpio bsico que norteia
quase todas as arquiteturas modernas. Dados e instrues no so diferenciados na
memria. Ou seja, no h uma separao rgida entre instrues que compem um
programa e os dados sobre os quais opera. Essa caracterstica foi herdada da arquitetura
bsica de von Neumann. Como veremos a seguir, essa deciso de design, com origem nos
anos 1940, embora tenha facilitado a evoluo dos computadores, abriu caminhos para os
exploits que conhecemos hoje.
Abaixo descrevemos o layout bsico da memria de um processo em um sistema
UNIX. Ele pode ser separado em 6 partes fundamentais:
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

Figura 2.3: Regies de memria em um processo.

responsvel por armazenar variveis globais no inicializadas. Como text e data,

bss tambm tem tamanho fixo conhecido desde o incio do processo.
heap Espao para variveis alocadas dinamicamente. A chamada de sistema sbrk
responsvel pelo controle do crescimento/encolhimento desse espao. Bibliotecas
geralmente facilitam a vida do programador disponibilizando interfaces mais
amigveis como malloc() e free(). Assim a biblioteca se encarrega de chamar sbrk()
para diminuir/aumentar o heap. Ela cresce do endereo mais baixo para o mais alto.
stack Mantm controle das chamadas de funes. Possibilita a recursividade. Logo,
possui tamanho varivel - crescendo do endereo mais alto para o mais baixo (sendo
antagonista do heap - ver figura 2.3). Esse crescimento que torna possvel que uma
chamada de funo que tenha seus dados sobrescritos influencie numa chamada de
funo anterior. Esse caracterstica explorada pelo Buffer Overflow - tratado no
captulo 4.
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.

2.5

Funcionamento mais detalhado do Stack

A pilha uma regio contnua com base fixa e tamanho varivel. Na arquitetura
abordada por esse trabalho, x86 (bem como em muitas outras), a pilha cresce em direo
ao endereo mais baixo. organizada em frames que so os blocos alocados quando
ocorrem chamadas a funes. Cada frame contm(ver figura 2.4):
parmetros
variveis locais
endereo de retorno da funo anterior
endereo do frame da funo que a chamou
2.5.1

Chamada de funes

Quando uma funo chamada, seus parmetros so empilhadas e posteriormente o

endereo do retorno. Isso fica a encargo da funo que faz a chamada. Para completar
o frame, aquela que chamada, empilha o endereo do frame da funo chamadora
(EBP) e posteriormente aloca na pilha o espao correspondente a suas variveis locais.
importante ressaltar que, caso o endereo de retorno, empilhado por quem chama, seja
alterado, o fluxo de execuo mudado. Pois justamente este o princpio do Buffer
Overflow. Ele ser abordado em maior detalhes na Seo 4.2.1.

2.6

Funcionamento mais detalhado do heap

A poro de memria correspondente ao heap possibilita ao programador alocar

dinamicamente memria que fica disponvel durante toda a execuo para qualquer
chamada de funo. Existem diversas formas de administrar a memria do heap, mas
o mais encontrado, conforme (LOVE, 2007), dividir o todo em parties de potncias
de 2. Chamadas funo malloc()/free(), em ltima anlise, correspondem a operaes
de alocar/liberar parties internas do heap. Normalmente a organizao das parties se
d como forma de uma lista encadeada. Assim, para efetuar o controle dos blocos, so
mantidas meta-informaes que determinam tamanho, endereo do prximo bloco livre
- entre outros - para que a gerncia da memria dinmica seja eficiente. Uma chamada
a free(), por exemplo, pode implicar acerto de diversos ponteiros que existem dentro das
parties no heap.

20

Havendo uma validao incorreta no software, pode ocorrer um overflow na rea do

heap. Se os dados escritos sobrepuserem os valores dos ponteiros de controle interno
dos blocos, fica aberto um caminho para que um atacante consiga uma escrita em um
endereo arbitrrio. Pois esse o princpio bsico de funcionamento de Heap Overflow.
Ele pressupe o conhecimento aprofundado da gerncia do heap; pois s dessa forma
possvel prever exatamente como os blocos so mantidos.

2.7

Mapemamento de memria annimo

Como visto no funcionamento bsico do heap, a fragmentao um problema a ser

considerado. Uma forma alternativa de alocar memria dinamicamente que no usa o
heap so os mapeamentos annimos. No Linux por exemplo, atravs da funo mmap()
possvel alocar um bloco de memria contnuo fora do heap que no est sujeito aos
problemas de fragmentao. Conforme, (LOVE, 2007), possvel considerar esse espao
de memria como um novo heap vindo de apenas uma alocao. No exemplo a seguir,
requisitado uma poro de memria de 64 bytes iniciando em NULL.
Listing 2.1: Mapeamento de memria annimo.
mmap (NULL, 6 4 , PROT_READ | PROT_WRITE ,
MAP_FIXED | MAP_ANONYMOUS | MAP_PRIVATE , 0 , 0 ) ;

1
2

Na tcnica NULL pointer exploit, conforme veremos mais adiante, essa possibilidade
de alocar um bloco com o incio pr-determinado muito til. No caso da chamada
de mmap() do exemplo anterior, estamos obtendo um bloco de 64 bytes comeando
no endereo zero(NULL). Isso nos permite colocar cdigo executvel nessa poro da
memria e, na presena de uma vulnerabilidade, desviar a execuo para esse ponto.

2.8

Registradores de controle

Uma parte fundamental da arquitetura que deve ser mencionada so os registradores

que possuem relao direta com o gerenciamento da memria. Talvez o mais importante
(na arquitetura base do estudo IA32) seja o EIP(Extended Instruction Pointer). Ele indica
o endereo da prxima instruo. Sobrescrev-lo equivale obter o controle do fluxo de
um processo. Alm dele, destacamos EBP(Extended Base Pointer) e ESP(Extended Stack
Pointer). ESP indica o endereo do ltimo valor inserido na pilha. O EBP indica o incio
da pilha para aquela chamada de funo. usado para referenciar variveis locais da
funo.

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

CLASSIFICAO DE VULNERABILIDADES

A classificao de vulnerabilidades representa enorme desafio. Nos dias de hoje,

no existe nenhum padro aceito globalmente para essa tarefa. Ainda assim, j houve
vrios avanos na rea. Existem padres para enumerar e catalogar vulnerabilidades, bem
como propostas que podem criar bases para uma classificao que venha a ser aceita pela
comunidade. Mtricas, relativas gravidade e ao impacto, tambm esto disponveis e
so empregadas no auxlio s instituies nas tomadas de decises.
No trabalho de Seacord e Householder, (SEACORD, 2005), temos os fatores que
motivam a busca pela organizao das vulnerabilidades em classes:
O entendimento das ameaas que elas representam;
Correlacionamento de incidentes, de exploits e de artefatos;
Avaliao da efetividade das aes de defesa;
Descoberta de tendncias 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

A dificuldade em classificar; estgio j alcanado: enumerao

Antes de entrarmos no mrito das vulnerabilidades, preciso definir com preciso

dois termos que utilizaremos por todo o captulo: classificar e enumerar. Como veremos,
a taxonomia mais custosa que a enumerao.
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:
Excluso mtua Um item no podem ser categorizado simultaneamente em dois grupos.
Exaustividade Os grupos, unidos, incluem todas as possibilidades.
1

Cincia da classificao.

23

Repetibilidade Diferentes pessoas extraindo a mesma caracterstica do objeto devem

concordar com o valor observado.
Aceitabilidade Os critrios devem ser lgicos e intuitivos para serem aceitos pela
comunidade.
Utilidade A classificao pode ser utilizada na obteno de conhecimento na rea de
pesquisa.
Vemos que os critrios para a taxonomia so exigentes e pressupem uma metodologia
cuidadosamente gerada para atend-los.
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.1.3

Da enumerao classificao

No trabalho de Mann, (MANN, 1999), h um excelente paralelo entre a questo

abordada nesse captulo e o advento da tabela peridica2 na Qumica. A organizao dos
elementos da forma como conhecemos hoje na tabela peridica foi um processo longo que
culminou com as ideias de Dimitri Mendeleev. Outros qumicos que o precederam foram
responsveis pela identificao e listagem dos elementos. Isso possibilitou um melhor
estudo e uma maior troca de informao precisa entre os pesquisadores.
Segundo Mann, a tabela peridica s pode ser efetivamente criada graas aos esforos
daqueles que enumeraram os elementos de forma mais simples antes de Mendeleev.
O trabalho deles permitiu a interoperabilidade necessria para o surgimento da tabela
peridica. Da mesma forma, nos anos antecedentes a 2000, a comunidade que
estudava e acompanhava as vulnerabilidades estava num patamar semelhante queles que
precederam Mendeleev. Ou seja, sequer havia uma enumerao mais amplamente aceita e
reconhecida das vulnerabilidades que permitisse avanos suficientes para uma taxonomia.
Citamos o ano de 2000 como parmetro, pois nessa poca, 1999, surgiria um
projeto que se tornaria referncia para a criao de uma padronizao da enumerao
de vulnerabilidades. No seria ainda um evento comparvel criao da tabela peridica
para Qumica (pois no trouxe a taxonomia) mas certamente lanaria as bases para a
interoperabilidade exigida para estudos mais aprofundados na rea. Estamos falando da
criao do CVE(Common Vulnerabilities and Exposures)34 pelo MITRE. A seo 3.2 traz
mais detalhes.
2

Dispe sistematicamente os elementos de acordo com suas propriedades permitindo uma anlise
multidimensional.
3
http://cve.mitre.org
4
Na poca de sua criao era originalmente conhecido por Common Vulnerabilities Enumeration - vide
(MEUNIER, 2006) pg. 9.

24

Organizao
Como se referia vulnerabilidade
CERT
CA-96.06.cgi_example_code
Cisco Systems
http - cgi-phf
DARPA
0x00000025 = http PHF attack
IBM ERS
ERS-SVA-E01-1996:002.1
Security Focus #629 - phf Remote Command Execution Vulnerability
Tabela 3.1: Uma vulnerabilidade: diversos nomes e nenhum entendimento
Podemos dizer, portanto, que atualmente, embora no tenhamos uma taxonomia
amplamente aceita pela comunidade, j foi atingido o estgio de enumerao. Projetos
como o CVE podem ser considerados como marcos dessa etapa. A seguir, iremos
abordar em mais detalhes o surgimento e o funcionamento dele. Isso nos possibilitar
compreender melhor a complexidade da classificao das vulnerabilidades bem como ir
facilitar o entendimento dos captulos seguintes que abordam exploits.

3.2
3.2.1

CVE
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:
Atribuio de um nome padronizado e nico a cada vulnerabilidade.
Independncia das diferentes perspectivas em que a vulnerabilidade ocorre.
Abertura total voltada ao compartilhamento pleno das informaes.
Segundo a prpria organizao, vide (CVE, 2010), o CVE no possui um objetivo
inicial de conter alguma espcie de taxonomia. Essa considerada uma rea de pesquisa
ainda em desenvolvimento. esperado que, com o auxlio prestado pela catalogao das
vulnerabilidades j constitua um importante passo para que isso ocorra.
Na figura 3.1, podemos visualizar um histrico da quantidade de vulnerabilidades
adicionadas. Nos ltimos anos podemos perceber que os incidentes registrados ficam na
mdia de 7000. Isso mostra relevncia que o projeto do CVE alcanou.
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:
O CVE est restrito a publicar vulnerabilidades j conhecidas.
Por diversas razes, a comunidade de segurana de informao sofre mais para
compartilhar dados sobre as ameas que os atacantes.
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.

3.3

Propostas taxonmicas

Nessa Seo, apresentaremos taxonomias para vulnerabilidades e um projeto,

anlogo ao CVE, que rene esforos para a padronizao da classificao: o CWE.
Primeiramente, faremos um breve histrico das propostas j criadas com esse fim. A
seguir, apresentaremos algumas das classificaes que consideramos de maior relevncia
e, por fim, trataremos do projeto CWE - que assume importante papel no contexto atual
na catalogao dos tipos de vulnerabilidades existentes.

26

3.3.1

Histrico das propostas

Em (GRGIO, 2005b), encontramos um levantamento das dessas alternativas. Mas,

como veremos, nenhuma delas atinge os objetivos de uma taxonomia plena - apresentados
na seo 3.1.1. Assim, buscaremos discutir as ideias para as metodologias de classificao
com o intuito de apontar suas vantagens e fraquezas.
Em 1976, surge o primeiro estudo, chamado Research Into Secure Operating
Systems(RISOS). Ele objetivava auxiliar na compreenso das falhas encontradas nos
sistemas operacionais como MUTICS, GECOS, IBM OS. Foram propostas 7 classes,
pg. 328 de (GRGIO, 2005b):
Validao incompleta de parmetros;
Validao inconsistente de parmetros;
Compartilhamento implcito de privilgios ou dados confidenciais;
Validao assncrona ou serializao inadequada;
Autorizao, autenticao ou identificao inadequadas;
Violao de proibio de limite;
Erro de lgica explorvel;
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:
Reforo e inicializao do domnio da proteo;
Validao de operandos / dependncias no gerenciamento das filas;
Sincronizao imprpria;
Erros de seleo de operadores crticos;
Embora a ideia inicial do PA tambm inclusse a deteco automtica de vulnerabilidades,
sendo pioneiro nesse ponto, a classificao proposta no era intuitiva e de difcil aplicao
- conforme consta em (TSIPENYUK, 2005). Logo, a aplicao prtica no foi levada
adiante, mas a base da proposta adicionou conhecimento na rea.
Segundo (GRGIO, 2005b), apenas no ano de 1992, teramos uma nova proposta de
classificao que trouxesse nova perspectiva ao estudo em questo. Trata-se do trabalho
de Landwher: A Taxonomy of Computer Security Flaws. Seu foco estava no auxlio aos
projetistas no desenvolvimento mais seguro do software. Sua classificao tinha por base
3 critrios:
Como o defeito entra no sistema(gnese);
Quando o defeito entrou no sistema(tempo de introduo);

27

Onde ele se manifesta(localizao);

De acordo com Grgio, seu principal problema era a ambiguidade no processo de
classificao. A dependncia na viso do classificador tem do sistema impede a
objetividade necessria a uma boa taxonomia. Outro problema nessa proposio,
abordado por Katrina, em (TSIPENYUK, 2005), est na dificuldade que pode surgir caso,
por exemplo, se desconhea a forma como a vulnerabilidade adentrou o sistema. Em tal
situao, no seria possvel identificar a gnese.
No ano de 1996, a taxonomia proposta por Aslam, em Use of a Taxonomy of Security
Faults, traria nova acrscimo s pesquisas na rea. Segundo, (TSIPENYUK, 2005)(pg.
3), o esquema proposto por Aslam bastante preciso; consistindo numa srie de perguntas
para cada categoria de vulnerabilidade. Em (GRGIO, 2005b), pg. 329, encontramos as
classes criadas por Aslam, com suas subdivises:
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).
3.3.2

Taxonomias e classificaes mais recentes

Agora trataremos das propostas para classificao de vulnerabilidades que surgiram

mais recentemente (aps 2005) e que merecem uma anlise mais apurada. So eles:
Preliminary List of Vulnerability Examples for Researchers(PLOVER);
Comprehesive, Lightweight Application Security Process(CLASP);
Seven Pernicious Kingdoms;
So taxonomias que no passam pelo rigor cientfico, pois no atendem a todos os
princpios taxonmicos, mas que ainda assim acrescentam bastante sobre o entendimento
dos problemas que as vulnerabilidades representam. o que diz Meunier em (MEUNIER,
2006) ao tratar das classificaes populares.
O PLOVER, criado em 2005 pelo MITRE em colaborao com o DHS(US.
Departement of Homeland Security)5 e o o NIST(National Institute of Technology) um
esquema de classificao que possui dezenas de categorias principais e, naturalmente,
possui ainda mais preciso do que a proposio de Aslam. Um de seus principais
idealizadores foi Steve Christey. Trata-se de um trabalho com slidas fundaes, pois
apresenta um Framework conceitual que permite discutir as vulnerabilidades em diversos
nveis. Nele so definidos uma srie de conceitos essenciais para o estudo da rea. Pode
ser encontrado em detalhes em (CHRISTEY, 2006).
5

http://www.dhs.gov/index.shtm

28

Dentre as suas contribuies, destacam-se o carter prtico; mais de 1400

vulnerabilidades identificadas no CVE foram devidamente classificadas utilizando esse
sistema. Foi uma taxonomia construda de baixa para cima(bottom-up). Essa experincia
foi muito til para a definio dos critrios.
Abaixo, seguem algumas categorias de mais alto nvel existentes no PLOVER
(existem 30 no total):
BUFF Contm erros como Buffer Overflow e Heap Overflow.
SPECTS(Technology-Specific Special Elements) Abrange erros que possibilitam
ataques de Injeo de SQL e XSS.
RACE Erros advindos de condies de corrida.
CRYPTO Falhas relacionadas o uso inadequado ou problemas na criptografia.
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:
Erros de range e de tipo;
Problemas no ambiente;
Erros de sincronizao e de temporizao;
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.
Features de segurana Trata do uso correto de peas chave na garantia da segurana
do software como: criptografia, autenticao, gerenciamento de privilgios, entre
outros.
Tempo e estado Relativo a problemas advindos do paralelismo.
sincronizao que expem o sistema.

Como erros na

Gerenciamento de erros Vulnerabilidades desse reino surgem quando os erros no

tratados corretamente. Quando um erro expe informaes do sistema ao atacante
desnecessariamente, j estamos diante de um exemplo.
Qualidade de cdigo Se a qualidade baixa, o comportamento imprevisvel. Tendo em
vista essa regra, problemas na codificao acabam levando a erros que permitem a
subverso do sistema.
Encapsulamento Falhas relacionadas ao no estabelecimento de limites entre os
componentes do sistema.
Ambiente Trata de problemas surgidos com questes externas ao software. No esto
relacionados ao cdigo, mas influenciam diretamente na segurana.
Como subdivises dos reinos, encontramos, por exemplo, o filo correspondente ao
Buffer Overflow - no reino do Erro de Validao e de Representao. Ainda nele, tambm
encontramos o filo de Injeo de Comandos. J no reino de Features de segurana, est
o filo da Randomizao Insegura - que trata da randomizao incorreta que pode ser uma
fraqueza para a criptografia. O erro correspondente a NULL pointer pertence ao filo Null
Dereference - que por sua vez englobado pelo reino Qualidade de cdigo.
Essa classificao foi desenvolvida com a projeo da adio de novos filos conforme
a necessidade. O intuito foi de criar reinos amplos o suficiente para que os devidos filos
fossem incorporados com o tempo.
3.3.3

O projeto CWE

Aps o surgimento do CVE, uma padronizao para identificao das vulnerabilidades

foi sendo alcanada. Entretanto, a classificao, que no era objetivo direto do CVE, foi
deixada de lado pelo projeto. Em 2005, mais de 5 anos depois da criao do CVE, aps
o estudo de uma srie de vulnerabilidades catalogadas, foi gerado o PLOVER - abordado
na Seo anterior.
A partir do estudo e da classificao resultante do PLOVER, surgiu a possibilidade de
se estabelecer descries comuns a comunidade para os tipos de vulnerabilidades. Desse
6

Artigo The Magic Number Seven, Plus or Minus Two de George Miller.

30

esforo, surge o CWE: Common Weakness Enumeration 7 . Embora esteja fundamentada

na classificao proposta pelo PLOVER, o CWE no se limita a ela. Tambm opera com
outras como: Seven Pernicious Kingdoms e o CLASP.
Conforme encontramos em (CWE, 2007), ele uma resposta necessidade das
instituies e das organizaes em utilizarem os mesmos termos e taxonomias no
tratamento dos problemas de segurana que enfrentam. Como saber quais as classes de
vulnerabilidades que uma ferramenta de deteco capaz de encontrar? Perguntas como
essas caem justamente no escopo do CWE.
Entre os objetivos e impactos diretos do CWE, encontrados em (CWE, 2009), temos:
Providencia uma linguagem comum para as discusses relativas s fraquezas
encontradas no software e nos sistemas;
Permite aos fabricantes de ferramentas de segurana fazer afirmaes claras e
consistentes sobre quais tipos de falhas elas cobrem;
Permite aos compradores de ferramentas de segurana comparar com melhor
qualidade as alternativas em virtude da discriminao da cobertura delas
encontradas no CWE.
Habilita governos, instituies e a indstria a utilizar a padronizao fornecida pelo
CWE para estabelecer contratos, termos e condies.
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.

3.4

Mtricas para vulnerabilidades: CVSS

Comparar objetivamente vulnerabilidades de acordo com sua criticidade algo muito

til para as organizaes. Isso possibilita que os gestores mensurem o grau de urgncia
com que devem ser tratadas as ameaas. Podemos considerar esse procedimento como um
tipo rudimentar de classificao. Ainda que no seja uma taxonomia, assume um papel de
destaque por permitir um padro para distinguir vulnerabilidades mais graves das demais.
3.4.1

Surgimento do CVSS

Para essa finalidade existe uma alternativa relativamente recente, o CVSS (Common
Vulnerability Scoring System), criado em 2005. Trata-se de um framework aberto para
atribuio de escore a vulnerabilidades. Ele oferece as seguintes vantagens, encontradas
em (MELL, 2007) - pg. 3:
Padronizao de escore de vulnerabilidades Quando uma organizao normaliza os
escores de vulnerabilidades em todas suas plataformas de hardware e software, ela
pode instituir uma poltica comum de gerenciamento das ameaas.
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

Priorizao de riscos Quando o escore ambiental calculado, a vulnerabilidade passa a

possuir contexto. De tal forma que o risco real que ela representa para a organizao
possa ser mensurado.
A organizao responsvel pelo CVSS a Forum of Incident Response and Security
Teams (FIRST)8 . Alm do FIRST, as seguintes organizaes tambm cooperaram para
seu surgimento:
CERT/CC
Cisco
DHS/MITRE
eBay
IBM Internet Security Systems
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.
3.4.2

As mtricas usadas

Para o clculo do escore de uma vulnerabilidade, o CVSS, na sua verso 2, possui

diversas mtricas que so divididas em 3 grupos principais. em (MELL, 2007)9 :
Mtricas bsicas Representam as caractersticas fundamentais da vulnerabilidade e so
constantes com relao ao tempo e ao ambiente.
Mtricas temporais Mudam com o transcorrer do tempo, mas no so suscetveis a
fatores ambientais.
Mtricas ambientais Esto
relacionadas unicamente ao ambiente em que a vulnerabilidade analisada. Por
isso, so absolutamente dependentes das particularidades de cada caso.
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:
Vetor de acesso Diz respeito ao nvel de acesso necessrio para explorar a
vulnerabilidade. Pode assumir trs valores: Local(exige acesso fsico ou uma conta
shell ), Rede adjacente( preciso ter acesso rede local) ou Rede(indica a chamada
vulnerabilidade remota - pode ser disparada de qualquer ponto da Internet).
8
9

www.first.org
Termos em ingls traduzidos livremente pelo autor.

32

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
Complexidade de acesso Indica a complexidade a ser enfrentada pelo atacante para
que ele, uma vez que tenha obtido acesso ao sistema alvo, possa explorar a
vulnerabilidade. Assume um dos valores alto, mdio ou baixo. A complexidade
considerada alta, por exemplo, se o ataque exige alguma tcnica de engenharia
social mais sofisticada ou se existe uma condio de corrida com janela muito
exgua que deve ser vencida.
Necessidade de autenticao Mede a quantidade de vezes que o atacante obrigado a
se autenticar durante o ataque - mesmo que seja usada a mesma credencial. um
dos valores: nenhuma, uma, vrias.
Impacto na confidencialidade Mede o impacto causado na abertura de dados
confidenciais gerados pelo ataque. Se nenhuma informao, em princpio protegida,
comprometida a medida assume valor nenhum. Havendo acesso a alguma
informao, considerado parcial. dito completo caso o atacante tenha total
acesso de leitura aos dados confidenciais.
Impacto na integridade Avalia a possibilidade que o atacante possui de alterar os dados
quando o ataque bem sucedido. Se no mais possvel confiar na integridade dos
dados aps o ataque, pois qualquer arquivo pode ter sido modificado, considerada
completa. No havendo possibilidade de alterao, assume o valor nenhuma.
denominada parcial quando apenas parte dos dados pode ter sido comprometidos.
Impacto na disponibilidade Indica o quanto a disponibilidade do sistema pode ser
afetada pelo ataque. dita completa caso o sistema possa ser totalmente desligado
ou inutilizado pelo atacante. Assume o valor nenhuma quando no pode haver
alterao na disponibilidade e parcial se o servio ainda puder estar disponvel mas
no plenamente.
As mtricas do grupo temporal so opcionais. Ou seja, podem ser desconsideradas
no clculo do escore conforme a vontade nos analistas. Por isso, cada uma delas pode
assumir o valor no definido indicando que ela no deve participar do escore. So 3 os
critrios que so suscetveis a alteraes com o passar do tempo:
Facilidade de explorao Mede o estado atual das tcnicas e do cdigo disponvel para
explorao da vulnerabilidade. Seus valores so, em ordem crescente de facilidade:
no comprovada, prova de conceito, funcional e alta. O primeiro indica que
um exploit meramente terico e no h cdigo disponvel que comprove como
explorar a falha. Havendo cdigo facilmente acessvel de exploit ou mesmo se
operaes manuais so suficientes, estamos diante de alta facilidade de explorao.

33

Confiabilidade no report Mede o grau de confiana na existncia da vulnerabilidade

bem como a credibilidade dos detalhes tcnicos fornecidos quando ela foi reportada.
Seus possveis valores so: no confirmada(quando h apenas um rumor de uma
origem sem credibilidade), no corroborada(h fontes no oficiais com possveis
incoerncia em seus reports) e confirmada( o autor ou o fabricante admitem
o problema ou ele j amplamente conhecido existindo at exploits facilmente
encontrados).
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.
Os fatores relativos influncia do ambiente, so medidos na mtricas ambientais.
Cada organizao pode sofrer diferentemente o impacto de uma vulnerabilidade dada
a heterogeneidade com que podem se organizar em termos do software e hardware
utilizados para desempenhar suas funes. Exemplificando, caso uma empresa preste
algum tipo de servio de backup de dados, a integridade e a confidencialidade da
informao que ela mantm possuem importncia mxima. Em contrapartida, se a
atividade desempenhada pela empresa estiver relacionada hospedagem de projetos
de cdigo fonte aberto, a disponibilidade assume muito maior importncia que a
confidencialidade. Da mesma forma como os critrios temporais, eles podem assumir
o valor no definido; indicando que ele no utilizado no clculo do escore final. Abaixo,
so explicados os 5 critrios que compem a mtrica temporal:
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.
Abundncia de alvos Mensura a proporo dos possveis alvos sobre o contingente de
sistemas da organizao. Pode ser nenhuma, baixa(1 a 25%), mdia(26 a 75%) e
alta(76 a 100%) .
Importncia da confidencialidade Indica a relevncia da confidencialidade dos dados
mantidos pela empresa. Assume os valores baixo, mdio e alto.
Importncia da integridade Anlogo importncia da confidencialidade.
Importncia da disponibilidade Anlogo importncia da confidencialidade.
3.4.3

Clculo do escore

Tendo sido apresentadas as mtricas, faremos breve explicao do funcionamento do

clculo do escore, que varia de 0 a 10, para uma vulnerabilidade. A figura 3.2 apresenta
uma viso geral desse processo. Passos necessrios:
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)

2. Consultar as tabelas, no apndice A, para definir um valor numrico a partir do

valor nominal escolhido no passo anterior.
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.
5. Calcular o do escore final usando a equao ambiental, A.5, a partir do
escore temporal. Tambm opcional; pois os critrios ambientais podem ser
desconsiderados.
Ao final do clculo, a vulnerabilidade recebe um escore de 0 a 10. Sendo 10 o valor da
mais crtica possvel. importante destacar, que a atribuio dos valores, feita no passo
1, deve ser realizada por especialistas na rea seguindo um critrios padronizados.

35

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:
Parada parcial ou completa do sistema(DoS);
Exposio de dados confidenciais;
Escalada de privilgios;
Execuo de cdigo injetado pelo atacante;

36

Logo, ao explorar uma vulnerabilidade, podem ser gerados impactos na integridade, na

confidencialidade ou na disponibilidade de um sistema.
De modo geral, o grande objetivo de um atacante conseguir executar cdigo
arbitrrio em seu alvo. Isso, porm, nem sempre possvel. Cada vulnerabilidade,
conforme analisado no captulo anterior, determina um universo de possibilidades para
um exploit que a ataque.
Uma interessante forma de entender os exploits, sob a tica de sua operao, est na
separao deles em control-data e non-control-data. Conforme (CHEN, 2005), ataques
do tipo control-data so aqueles que alteram dados de controle do programa alvo (como
endereo de retorno da funo ou ponteiros) para executar cdigo injetado ou desviar
para outras bibliotecas. Os do tipo non-control-data, em contraponto, so aqueles que no
alteram nenhum dado de controle do programa e no desviam seu fluxo de execuo, mas
conseguem alguma vantagem para o atacante - como autenticao ilegtima, elevao de
privilgio, leitura de dados confidenciais, etc. Ao apresentar os tipos de exploits, ser feito
uso desse critrio de classificao. Normalmente, os ataques que alteram estruturas de
controle so aqueles que possibilitam execuo arbitrria de cdigo, enquanto os demais
usam o prprio cdigo da aplicao, explorando alguma falha de lgica ou de verificao.

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);
4.2.1

Buffer Overflow

Um dos tipos mais bem conhecidos e um dos mais explorados. Tem um impacto
enorme pois possibilita ao atacante a execuo de cdigo arbitrrio no sistema atacado.
O famoso artigo Smashing the Stack for Fun and Profit de 1996, por Aleph One, foi
o primeiro a tratar em detalhes dessa tcnica. Mas conforme, (ANLEY, 2007), essa
estratgia j vinha sendo aplicada com sucesso por mais de 20 anos antes da publicao
do artigo de Aleph One.
Ocorre quando a aplicao guarda dados a serem lidos dos usurio(ou de qualquer
fonte externa) em um buffer alocado na pilha sem verificar se o que foi fornecido est
dentro do limite aceitvel(tamanho do buffer. Isso acaba resultando na grave falha que
ser apresentada abaixo.
Conforme explicado na Seo 2.4, no stack frame existem valores que controlam o
fluxo de execuo de uma aplicao. Dentre eles, est o valor de retorno de uma rotina.
Qualquer chamada de funo coloca na pilha o endereo para o qual ela deve retornar
aps seu fim. Se esse valor for alterado, possvel mudar o fluxo da aplicao - fazendo
com que ele seja desviado para outro ponto qualquer.

37

Figura 4.1: Esquema da pilha no buffer overflow. Fonte: (MARTINS, 2009).

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).
4.2.2

Heap Overflow

Semelhante ao buffer overflow quanto falha que o provoca. Diferencia-se,

entretanto, pelo fato do buffer a sofrer o overflow estar no heap e no na pilha. Pode
ser de muito mais complexa execuo que muitos outras tcnicas - isso porque, conforme
veremos, no possui o carter mais genrico que seu equivalente para a pilha.
Est diretamente relacionado implementao feita para manejar o heap no sistema
afetado. Isso geralmente atribuio da biblioteca C. Logo, alm da vulnerabilidade
de overflow, deve estar presente uma verso de biblioteca C que faa alguma gerncia
incorreta do heap para que um ataque desse tipo seja possvel.

38

Assim, um exploit de heap overflow totalmente focado em uma determinada verso

de biblioteca C de um sistema, pois normalmente as aplicaes no fazem sua prpria
gerncia do heap. Na Seo 2.6, h uma explicao do funcionamento do heap que auxilia
na compreenso desse tipo de ataque.
Para ilustrarmos melhor esse tema, iremos focar em um sistema especfico para
mostrar a sistemtica e a potencialidade de um heap overflow. Ser a implementao
de gerncia do heap do Linux originalmente escrito por Doug Lee. A tarefa de controle
da memria dinmica extremamente complexa e desafiadora, pois est condicionada
a otimizao temporal e espacial. Como muitas aplicaes fazem uso intensivo de
chamadas a malloc, free e mmap - todas para controle do heap - preciso um enorme
cuidado para que os recursos de CPU e memria sejam bem utilizados de forma a no
prejudicar o desempenho da aplicao e do sistema como um todo.
Para manter controle do heap, nos blocos alocados e fornecidos s aplicaes, so
tambm postos dados de manuteno. So meta informaes que visam auxiliar na
administrao dos blocos de memria. Assim, por exemplo, ao alocarmos uma poro de
memria utilizando malloc, escondido no bloco, teremos dados que a biblioteca mantm.
Para a referida verso da biblioteca C do Linux, havia uma falha na qual, uma vez que
os metadados dos blocos fossem alterados (via overflow) de uma determinada forma, o
atacante poderia conseguir uma escrita arbitrria e um endereo arbitrrio. Conforme j
abordado anteriormente, uma falha dessa magnitude implica a possibilidade de alterao
do fluxo da aplicao caso seja sobrescrita alguma estrutura de dados de controle. Uma
alternativa seria um ponteiro para um funo - pois uma vez sobrescrito, bastaria que ele
passasse a apontar para o cdigo injetado pelo atacante.
Como a inteno desse captulo fornecer uma viso geral, no ser detalhada a
construo do ataque. possvel, porm, descrever de forma o contexto de atuao do
atacante. Sendo possvel o overflow no heap, atravs da construo de um bloco de
memria cuidadosamente montado1 , o atacante pode inserir dados que iro explorar uma
falha na gerncia dos blocos. Quando ocorrer uma chamada funo free() na aplicao,
ser possvel obter uma escrita em endereo arbitrrio - graas a atualizao incorreta da
lista encadeada que mantm os blocos. Isso porque o atacante, atravs do overflow, ter
alterado maliciosamente as meta informaes de controle do heap. Para uma viso mais
completa, aconselhada a leitura de (ANLEY, 2007) captulo 5.
4.2.3

Injeo de SQL

Diferentemente dos exploits anteriores, no se trata de um erro de corrupo de

memria. Serve como boa forma de contraponto para mostrar que um sistema pode ter
sua confidencialidade e integridade afetados de outra forma. Ocorre na camada de banco
de dados de uma aplicao em virtude de uma filtragem inadequada dos dados usados
para gerar queries SQL.
Ainda que seja uma classe muito diferente, quando comparado aos 2 tipos descritos
anteriormente, cabe destacar que seria identificado como non-control-data. No
necessria nenhuma alterao no fluxo do programa explorado.
Sua potencialidade enorme. Como implica a possibilidade do atacante injetar
queries no banco de dados do sistema alvo, significa dizer que ele ter todos os privilgios
de acesso que a aplicao possuir. Pode ser possvel expor informaes sigilosas,
alter-las ou mesmo destruir toda a base de dados.
1

Alocado via malloc()

39

A tcnica desse exploit, portanto, consiste em utilizar os comandos SQL previstos na

aplicao para executar aes de interesse do atacante - expondo ou alterando dados de
forma no prevista. Assim, basta que o atacante possua bons conhecimentos da linguagem
SQL, para que ele possa alterar a semntica das queries e obter vantagens.
4.2.4

XSS (Cross Site Scripting)

Um dos ataques mais difundidos na web. Conforme (DHANJANI, 2009), o meio

mais comum de ataques a clientes web - constituindo poderosa arma contra a rede interna
das corporaes. Trata-se de um ataque voltado para o lado do cliente - diferentemente
daqueles expostos anteriormente - que buscam explorar o servidor.
Seu funcionamento bsico se d atravs da injeo de cdigo malicioso por atacantes
em pginas web. Esse cdigo acaba sendo executado por clientes sem seu conhecimento.
Isso possibilita aos atacantes obter acesso a dados restritos mantidos pelos clientes nos
browsers. Uma das possveis implicaes o roubo de sesses web - tornando o atacante
capaz de acessar o servidor, indistintamente, com os mesmos privilgios do usurio
legtimo.
um problema semelhante injeo de SQL - j que a validao imprpria(ou
mesmo inexistente) permite que cdigo malicioso seja processado pelo servidor e posto no
contedo de suas pginas para ser entregue a outros usurios. Isso confirma, novamente, a
premente necessidade de validao de todo e qualquer dado de entrada em uma aplicao.
Uma das tcnicas mais utilizadas para roubo de sesses, descrita em (DHANJANI,
2009), a injeo de cdigo Javascript no servidor para repassar ao atacante todos os
dados da sesso do cliente que acesse a pgina. Para isso, o atacante mantm um servidor
que acionado toda vez que um cliente processa o script que ele injetou no servidor
vulnervel. Esse script executado no cliente, vtima, fornece ao servidor do atacante toda
informao necessria para que seja possvel assumir a identidade dela.
Outro possvel ataque, tambm apresentado em (DHANJANI, 2009) o roubo de
senhas armazenadas nos browsers dos clientes. Isso ocorrer quando alguma vtima utiliza
o recurso de armazenamento de senhas. Muito embora isso constitua uma comodidade,
uma vez que o servidor esteja vulnervel a XSS, os atacantes podem, atravs de script
forjado para fingir um login injetado no servidor, recuperar as senhas armazenadas
browser.
Para aprofundamento nas tcnicas de XSS e para maior conhecimento nas formas de
preveno, aconselhvel a leitura do captulo 2 de (DHANJANI, 2009). H riqueza de
exemplos e derivaes do XSS que constituem nova gerao dessa forma de ataque.

4.3

Preveno de ataques

Para prevenir as indesejveis consequncias dos exploits apresentados anteriormente,

mas no se restringindo a eles, sero discutidos princpios bsicos para o desenvolvimento
do software. So meios de trazer maiores garantias contra os ataques na origem. Ser
demonstrado que a validao dos dados usados pelas aplicaes, bem como o uso
de ferramentas de anlise de cdigo e de testes so exigncias que no podem ser
desconsideradas.
4.3.1

Validao de dados de entrada

Um dos pontos primordiais para a defesa contra os ataques a validao dos dados de
entrada. Sendo esse procedimento capaz de deter uma srie de ameaas. Uma aplicao

40

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.
4.3.2

Ferramentas de anlise esttica e auditoria de cdigo

Uma das melhores formas de preveno a ataques auditar o cdigo. A busca

por falhas no precisa ser um procedimento manual; h uma srie de ferramentas,
algumas delas sofisticadas e focadas nessa tarefa, que podem facilitar muito a vida dos
desenvolvedores. Nessa Seo, iremos abordar essa estratgia na busca por problemas
que possam ser eliminados j na fase de desenvolvimento - procurando deixar o mnimo
possvel de brechas para os atacantes.
Conforme (TAKANEM, 2008), a auditoria de cdigo cai na categoria de teste
estrutural caixa-branca. Isso porque parte do cdigo fonte para desempenhar sua tarefa.
O mesmo autor tambm destaca que esse processo, assim como os testes fuzzing(vide
captulo 6), no capaz de comprovadamente encontrar todos os bugs ou erros possveis.
Ainda assim, ele recomenda fortemente seu uso em complementao a outras tcnicas de
testes(como o fuzzing ou outros tipos de teste caixa-preta).
Muito embora o uso de ferramentas estticas no possa substituir um auditor
experiente, conforme ressalta (ANLEY, 2007), elas podem servir de base para a tarefa.
Em sua maioria, elas possuem uma base de dados de padres de cdigo perigoso. o
caso do uso da funo strcpy para a cpia de strings. Uma linha de que contenha esse
tipo de chamada ser encontrada e reportada como problema a ser tratado - dado o risco
que ela representa. Como exemplos de ferramentas para auxlio na busca por falhas no
software, temos:
Splint Faz anlise de falhas de cdigo C. Segundo (ANLEY, 2007), capaz de realizar
algumas verificaes bem complexas.
RATS Busca por falhas j bem conhecidas em linguagens com C, C++, Perl e Python.
No possui a mesma profundidade nas verificaes que Splint, mas uma tima
forma de garantir a ausncia de problemas j superados.
2

Processo de descoberta do nome associado a um dado IP.

41

Flawfinder Semelhante a RATS. Ambas surgem simultaneamente e cobrem uma mesma

gama de falhas em suas verificaes.
Como forma de preveno aos ataques, principalmente em se tratando de projetos
construdos em linguagens como C e C++, o uso dos tipos de ferramentas descritas acima
constitui quase uma obrigao. Seu uso simples e pode fornecer o ponto de partida para
uma auditoria manual do cdigo - que, naturalmente, tambm fortemente aconselhvel.

4.4

Protees e contra-protees

Existem diversas protees para impedir um exploit. So recursos dos compiladores,

das bibliotecas, do hardware e dos sistemas operacionais que servem de contra ponto s
mais variadas tcnicas que os atacantes j criaram. Seu principal objetivo resguardar
os sistemas mesmo que os desenvolvedores no tenham seguido as recomendaes de
segurana. De forma que, mesmo na presena de uma vulnerabilidade, um ataque no
seja possvel ou seus efeitos sejam minimizados ao mximo.
Conforme possvel encontrar em (ANLEY, 2007), destacamos os seguintes
mecanismos de proteo:
1. Pilha no executvel;
2. W X(permisso de escrita ou de execuo - nunca ambas);
3. Canrio para pilha;
4. Reordenamento das variveis na pilha;
5. ASLR - Randomizao do espao de endereos;
A seguir, cada uma ser explicada em seus aspectos fundamentais.
4.4.1

Pilha no executvel

A primeira, pilha no executvel, uma reao natural a um dos ataques mais comuns:
o buffer overflow. H registros de propostas de pilha no executvel desde 1996 conforme (ANLEY, 2007)(pg. 376). O exploit clssico sendo baseado na cpia de shell
code para o buffer e posterior execuo dele ficaria impraticvel. Mas no demorou muito
para os atacantes reagirem. Surgiram novas tcnicas que funcionam mesmo quando no
possvel executar o cdigo injetado na pilha. Sua estratgia bsica era: a partir do
controle do stack frame, criar uma chamada vlida para biblioteca C ou chamadas de
sistema. Inicialmente, ela foi denominada return-into-libc.
Essa nova tcnica de exploit abriria caminho para uma srie de outras. Todas elas
conseguindo desviar a execuo para algum cdigo j existente e, portanto, vlido,
evitando a necessidade de uma pilha executvel. Para citar algumas delas: ret2plt,
ret2strcpy, ret2gets, ret2syscall, ret2data, ret2text. Em (ANLEY, 2007), captulo 14, h
detalhes sobre elas.
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).

um princpio fundamental da maioria das tcnicas de ataque: injetar cdigo (escrever) e

execut-lo.
Embora essa tcnica seja hoje em dia conhecida pelo batismo de Theo Raadt,
desenvolvedor e lder do projeto do OpenBSD, ela tem sua origem na dcada de 1970.
Em (ANLEY, 2007), mencionado que o sistema Multics teria sido um dos pioneiros a
contar com esse tipo de proteo. Para facilitar essa estratgia de defesa na arquitetura
x86, em 2003, a AMD criaria o NX(Non-eXecutable). Um suporte no hardware que
identificasse uma pgina de memria que no pudesse ser executada. O equivalente da
Intel seria o ED(Execute Disable).
Mesmo sendo uma excelente forma de impedir ataques, isolada, essa defesa no
capaz suficiente. Algumas tcnicas derivadas de return-into-libc so imunes.
4.4.3

Canrio para a pilha

Outra forma de proteo para a pilha colocao de um canrio. Trata-se de um

valor(normalmente de 32 bits) que posto no stack frame para identificar se houve um
overflow na pilha. A figura 4.2 ilustra essa proteo. O canrio posto de forma a
proteger o endereo de retorno. Ao trmino da chamada da funo, ele verificado e,
caso no seja o valor esperado, a aplicao terminada.
Sua primeira implementao foi o StackGuard em 1998, vindo a fazer parte do
compilador GCC(GNU Compiler Collection) - posteriormente sendo substitudo pelo
SSP(Stack-Smashing Protector) (MARTINS, 2009). O SSP alm de implementar
proteo por canrio, tambm atua reordenando as variveis da pilha para aumentar a
segurana - conforme explicado na Seo 4.4.4.
Atualmente uma proteo padro em quase todos os sistemais operacionais e
certamente contribui muito para frear exploits de buffer overflow. Sua proteo ainda
maior quando combinada com o reordenamento da pilha.

43

Figura 4.3: Modelo de pilha ideal para o SSP. Fonte: (MARTINS, 2009).

4.4.4

Reordenamento de variveis na pilha

aplicada pelo SSP e complementa a proteo oferecida pelo canrio. uma barreira
extra para que um overflow nos buffers - que s detectado aps o trmino da funo no seja usado para afetar outras variveis.
Seu objetivo , conforme (MARTINS, 2009): "isolar os arrays que podem vir a vazar
dados, para que seu estouro no afete as outras variveis locais da funo. Isso garante
a integridade das variveis automticas no decorrer da funo, e evita o seu possvel uso
para a injeo de shellcode".
baseada em um modelo ideal de pilha no qual as variveis locais que no so buffers
so melhor protegidas contra possveis overflows. O modelo melhor compreendido
atravs da visualizao da figura 4.3.
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

NULL POINTER EXPLOIT

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.

5.1

O que um NULL pointer

O primeiro ponto a ser abordado o NULL pointer. Na linguagem de programao

C, podemos considerar um ponteiro como um valor inteiro que referencia uma posio
de memria. Ou seja, trata-se de um valor que aponta para o incio de uma determinada
regio de memria. Quando um ponteiro deferenciado, passamos a acessar o valor
presente na posio de memria para o qual ele aponta. Ilustrando, segue pequeno trecho
de cdigo C.
Listing 5.1: Ponteiro em C
1
2
3
4
5
6

int val = 10;

i n t p o i n t e r = &v a l ;
/ p o i n t e r has t h e a d d r e s s o f v a l /
int x = pointer ;
/ p o i n t e r r e t u r n s 10 /
No Linux, o arquivo stddef.h contm a definio de NULL, que por conveno,
denomina um ponteiro com valor zero. Um ponteiro nulo, ento, aponta para a posio

46

zero de memria. Como, em regra geral, os sistemas utilizam o esquema de memria

virtual, na prtica, esse endereo zero deve ser considerado to somente no espao
de endereamento do processo em questo. Como normalmente ele no constitui um
mapeamento vlido, pois os processos no iniciam com aquela poro mapeada, os
acessos a essa regio implicam violao s regras do esquema de memria virtual. Erros
como esse resultam no trmino da aplicao. Por isso, na maioria dos casos, um acesso a
um ponteiro nulo apenas sinnimo de uma DoS (negao de servio).
Diversas falhas em uma aplicao real podem levar presena de um ponteiro
zerado. Falhas ao inicializar uma estrutura de dados pode deixar ponteiros nulos
inadvertidamente. Outro possvel problema pode ocorrer quando o sistema tem sua
memria esgotada e, a chamada responsvel por alocar mais espao retorna NULL, mas
como essa possibilidade no considerada pelo programador, o ponteiro a receber esse
bloco de memria acaba ficando zerado e a aplicao segue normalmente.
Vemos, portanto, que um ponteiro nulo um caso particular no qual a regio
de memria referenciada aquela que inicia no endereo zero (no contexto de
endereamento do processo em questo - considerado o uso de memria virtual). Exceto
em casos especiais, essa situao leva a erros na aplicao que resultam em seu trmino.
Conforme trataremos a seguir, h casos em que um ponteiro nulo ir possibilitar um
ataque.

5.2

Como funciona a tcnica

A tcnica de explorao desse tipo de vulnerabilidade ir variar conforme o contexto

em que surge e como utilizado o ponteiro nulo. Conforme exposto anteriormente,
esse mtodo no to genrico como as falhas de buffer overflow. So ataques mais
focados que exigem ajustes muito maiores em funo das especifidades da aplicao alvo.
Como em outros gneros de exploits, o objetivo desejado a escrita de dados fornecidos
pelo usurio em endereos arbitrrios. Pois isso possibilita, por exemplo, a cpia de um
shellcode para ser executado. Mas isso no uma regra, h falhas de NULL pointer que
envolvem ponteiros para funes que possuem um caminho mais simples para explorao.
Para fins de simplificao, vamos dividir os tipos de ataques com essa tcnica em duas
famlias. Como podem existir vrias formas de explorao de aplicaes em que surgem
ponteiros nulos, para facilitar a compreenso, vamos tomar dois tipos representativos
que so capazes de passar a ideia fundamental. Numa delas, um endereo que define
a localizao de uma escrita depende de um ponteiro zerado. Em outra, esse ponteiro
define uma funo a ser executada. A primeira chamaremos de ponteiro nulo de escrita
e a segunda de ponteiro nulo de funo.
5.2.1

Ponteiro nulo de escrita

Nessa situao, por algum motivo, um ponteiro que define um endereo de escrita
fica nulo. Seja porque a memria alocada foi retornada em NULL e no foi verificada
ou mesmo porque a aplicao no validou corretamente a entrada e o calculou
indevidamente. O artigo de Mark Dowd, (DOWD, 2008), trata com riqueza de detalhes
esse gnero de falha.
Para que uma falha de NULL pointer desse tipo possa resultar em um ataque, podemos
elencar dois pr-requisitos:
O ponteiro nulo utilizado para calcular o endereo de uma escrita

47

A escrita depende de algo fornecido pelo usurio alm do NULL pointer

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 /
5.2.2

Ponteiro nulo de funo

Ocorre quando, por necessidade de dinamismo, uma funo que deve cumprir
determinado papel, definida por um ponteiro. Normalmente, ele deve conter um valor
vlido de um endereo de memria que contenha cdigo que cumpra com as aes
desejadas. Mas isso pode, na prtica, no se confirmar. Um valor NULL pode estar
no ponteiro no momento em que a funo chamada.
Se o endereo zero no constituir uma regio vlida, a aplicao terminar com um
erro. Mas e, se pusermos algo nessa regio para ser executado? Imagine que um atacante
tenha posto um shellcode justamente nesse ponto e provocou a chamada funo definida
pelo ponteiro nulo. A, certamente, poderamos estar frente a um ataque com grandes
chances de ser bem sucedido.
Como pr-requisitos, podemos elencar, portanto:
Um ponteiro nulo define o endereo de uma funo a ser chamada
O usurio pode provocar a chamada dessa funo
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.

5.3

Exemplos reais de NULL pointer exploit

Nessa seo, apresentamos vulnerabilidades reais que exemplificam o exploit em

estudo. Aquele que no poderia faltar, sem dvida, a falha tratada por Mark Dowd.
Seu artigo rico em detalhes e mostra todas as etapas que tornam possvel um ataque.
Tambm no poderamos deixar de analisar os erros encontrados no Kernel do Linux
em 2009. Isso porque problemas encontrados recentemente demonstraram que o sistema
estava exposto fazia oito anos. "Eight Years of Linux Kernel Vulnerable": chegou a

48

ser o ttulo de matrias divulgadas na Internet como encontrado em (CUNNINGHAM,

2009). No demorou muito para que uma caada a NULL pointer fosse realizada para
que diversas falhas fossem encontradas. Abordaremos duas delas.
5.3.1

Falha na mquina virtual do ActionScript

Trata-se de uma vulnerabilidade que se enquadra no que denominamos ponteiro

nulo de escrita (em 5.2.1). Consta no CVE como CVE-2007-0071. Foi objeto do
estudo do artigo (DOWD, 2008). A falha ocorre na leitura de arquivos SWF(Shockwave
Flash). Dados no arquivo so usados como parmetros de alocao de memria. Se for
passado um valor muito alto, como 2 gigabytes, a alocao no bem sucedida e, por
consequncia, um ponteiro nulo retornado. A aplicao realiza uma escrita na memria
usando como parmetros do clculo do endereo de destino o ponteiro nulo com outro
valor lido do arquivo (escolhido pelo usurio). Na pgina 7 de (DOWD, 2008), temos
uma verso alto nvel desse trecho de cdigo em que ocorre o clculo do endereo de
destino e a escrita na memria.
O destino da escrita escolhido pelo usurio quase de forma arbitrria. Existem
algumas restries como divisibilidade por 12 quando somado a 4. Mas isso no impede
que um ataque seja realizado. Como possvel acompanhar em (DOWD, 2008), criando
um arquivo do tipo SWF da forma correta e manipulando detalhes da mquina virtual
do ActionScript, o atacante torna-se capaz de executar seu shellcode na mquina alvo.
Isso feito atravs da construo de bytecode nativo para a mquina virtual ActionScript
que permite a injeo do shellcode. Aps a execuo do ltimo, a aplicao retorna
normalmente ao seu fluxo criando a impresso que nada demais ocorreu.
Pela enorme base de usurios que utilizam o Flash Player afetado, podemos dizer
que o impacto da explorao dessa vulnerabilidade foi enorme. Principalmente porque
a esmagadora maioria dos usurios jamais consideraria um uma apresentao em Flash
como um potencial vetor de ataque.
Vrios fatores foram necessrios para que um exploit fosse possvel nesse caso. Falhas
na validao de dados fornecidos pelo usurio foram os mais graves. Mas no foram
os nicos. A aplicao tambm no soube lidar corretamente com erros na alocao
de memria. Essa vulnerabilidade, como tantas outras, portanto, surge apenas pela
combinao de uma srie de problemas que so devidamente concatenados por uma mente
criativa e obstinada de um atacante.
5.3.2

Falhas no kernel do Linux

Existem diversas falhas documentadas no kernel do Linux relacionadas a NULL

pointer. Desde problemas na inicializao de estruturas de dados, condies de corrida
inesperadas e at erros na compilao. So falhas que surpreenderam pelo tempo que
permaneceram escondidas e algumas at pela relativa facilidade de explorao conforme
veremos a seguir.
Iniciaremos pelo erro conhecido no CVE como CVE-2009-2692. Trata-se de uma
vulnerabilidade muito grave que possibilita uma escalada de privilgios no sistema.
Verses desde 2.6.0 a 2.6.30.4 e 2.4.4 a 2.4.37.4 estavam suscetveis a esse bug; nada
menos que 8 anos de releases do kernel.
Sua origem encontra-se na inicializao incorreta de ponteiros de funes em
estruturas de dados do kernel; nesse caso, proto_ops_structures. Um bug em uma macro
(SOCKOPS_WRAP) acabava deixando no inicializadas funes responsveis, por
exemplo, de assumir o controle quando uma operao no disponvel fosse requisitada.

49

Enquadra-se, portanto, no que convencionamos como ponteiro nulo de funo.

Mais especificamente, quando um socket fosse usado e, fosse chamada a funo
sock_sendpage, e no fosse possvel enviar a pgina, a funo sock_no_sendpage deveria
ser despertada para tratar a situao. Mas, conforme explicamos, o valor NULL estaria
ocupando o devido local do endereo da funo sock_no_sendpage. Logo, o contexto da
execuo seria transferido para a regio de memria iniciada em zero. Por isso, sendo
injetado um cdigo nesse bloco, ele seria executado com os privilgios do kernel. Em
(TINNES, 2009), possvel obter mais detalhes sobre a questo.
A seguir, segue o cdigo que tira proveito dessa vulnerabilidade e possibilita ao
atacante a execuo de cdigo com privilgio mximo no sistema.
Listing 5.3: Exploit para CVE-2009-2692
1 # i n c l u d e < s t d i o . h>
2 # i n c l u d e < s y s / s o c k e t . h>
3 # i n c l u d e < s y s / mman . h>
4
5 # d e f i n e PAGE_SIZE 4096
6
7 i n t main ( ) {
8
v o i d mem ;
9
char t e m p l a t e [ ] = " / tmp / fileXXXXXX " ;
10
i n t f d i n = mkstemp ( t e m p l a t e ) ;
11
i n t f d o u t = s o c k e t ( PF_PPPOX , SOCK_DGRAM, 0 ) ;
12
int i ;
13
14
mem = mmap (NULL, 6 4 , PROT_READ | PROT_WRITE ,
15
MAP_FIXED | MAP_ANONYMOUS | MAP_PRIVATE , 0 , 0 ) ;
16
17
p r i n t f ( "mmap=%x \ n " , mem) ;
18
19
char s h e l l c o d e [ ] =
20
" \ x31 \ xdb \ x f 7 \ xe3 \ xb0 \ x04 \ x43 \ xeb \ x0a \ x59 "
21
" \ xb2 \ x1d \ xcd \ x80 \ xb0 \ x01 \ x4b \ xcd \ x80 \ xe8 "
22
" \ xf1 \ x f f \ x f f \ x f f g o t _ k e r n e l ! \ a \ n" ;
23
24
f o r ( i = 0 ; i < 3 6 ; i ++)
25
( char )mem[ i ] = s h e l l c o d e [ i ] ;
26
27
p r i n t f ( " f d i n=%d \ n " , f d i n ) ;
28
p r i n t f ( " f d o u t=%d \ n " , f d o u t ) ;
29
p r i n t f ( "%d \ n " , u n l i n k ( t e m p l a t e ) ) ;
30
p r i n t f ( "%d \ n " , f t r u n c a t e ( f d i n , PAGE_SIZE ) ) ;
31
p r i n t f ( "%d \ n " , s e n d f i l e ( f d o u t , f d i n , NULL, PAGE_SIZE ) ) ;
32
33
return 0;
34 }
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

A chamada a sendfile ir exigir, no contexto criado de erro de envio, uma chamada a

sock_no_sendpage. Como o endereo dela estar em zero, conseguimos desviar para o
shellcode no contexto do kernel.
A segunda vulnerabilidade que utilizaremos como exemplo conhecida no CVE como
CVE-2009-3547. Qualquer verso anterior a 2.6.32-rc6 vulnervel. Como o exemplo
anterior, tambm trata-se de uma falha que possibilita escalada de privilgios. Mas
um bug de mais difcil compreenso e explorao. Ainda assim, vrios exploits foram
divulgados por diferentes autores; provando sua viabilidade.
Ocorre devido a uma condio de corrida que pode deixar um ponteiro nulo. De
forma simplificada, podemos apontar a falha como uma no proteo de uma regio
crtica. As funes pipe_read_open(), bem como pipe_write_open() e pipe_rdwr_open(),
relacionadas intercomunicao de processos, podem no proteger corretamente o
acesso ao ponteiro que controla o total de processos leitores/escritores. Podemos ver a
dificuldade de reproduo dessa condio de corrida pelas palavras, (CHEW, 2009), do
desenvolvedor do kernel do Linux Earl Chew : "Note that the failure window is quite
small and I could only reliably reproduce the defect by inserting a small delay". Segundo
Earl, apenas uma pequena janela de tempo surgia para que o problema fosse detectado.
Podemos considerar essa falha muito mais sutil em sua manifestao que a primeira.
Ainda assim, pelo diff apresentado por Earl Chew para tratar o problema, vemos que,
novamente, um caminho possvel para evitar o pior foi a validao do ponteiro. Abaixo,
apresentamos patch por Earl Chew, encontrado em (CHEW, 2009), que impede a
explorao do erro.
Listing 5.4: Patch para CVE-2009-3547
i n d e x 52 c4151 . . a e 1 7 d 0 2 100644 ( f i l e )
a / f s / p i p e . c
+++ b / f s / p i p e . c
@@ 777 ,36 +777 ,55 @@ p i p e _ r d w r _ r e l e a s e ( s t r u c t i n o d e i n o d e ,
struct f i l e filp )
static int
pipe_read_open ( s t r u c t inode inode , s t r u c t f i l e f i l p )
{

/ We c o u l d h a v e p e r h a p s u s e d a t o m i c _ t ,

b u t t h i s and f r i e n d s b e l o w a r e t h e

o n l y p l a c e s . So i t d o e s n t seem w o r t h w h i l e .
/
+
i n t r e t = ENOENT ;
+
m u t e x _ l o c k (& i n o d e >i _ m u t e x ) ;

i n o d e > i _ p i p e > r e a d e r s ++;

+
+
i f ( i n o d e > i _ p i p e ) {
+
r e t = 0;
+
i n o d e > i _ p i p e > r e a d e r s ++;
+
}
+
m u t e x _ u n l o c k (& i n o d e >i _ m u t e x ) ;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25 +

return 0;
return r e t ;

51

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

}
static int
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 )
{
+
i n t r e t = ENOENT ;
+
m u t e x _ l o c k (& i n o d e >i _ m u t e x ) ;

i n o d e > i _ p i p e > w r i t e r s ++;

+
+
i f ( i n o d e > i _ p i p e ) {
+
r e t = 0;
+
i n o d e > i _ p i p e > w r i t e r s ++;
+
}
+
m u t e x _ u n l o c k (& i n o d e >i _ m u t e x ) ;

return 0;
return r e t ;
}

static int
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 )
{
+
i n t r e t = ENOENT ;
+
m u t e x _ l o c k (& i n o d e >i _ m u t e x ) ;

i f ( f i l p >f_mode & FMODE_READ)

i n o d e > i _ p i p e > r e a d e r s ++;

i f ( f i l p >f_mode & FMODE_WRITE)

i n o d e > i _ p i p e > w r i t e r s ++;

+
+
i f ( i n o d e > i _ p i p e ) {
+
r e t = 0;
+
i f ( f i l p >f_mode & FMODE_READ)
+
i n o d e > i _ p i p e > r e a d e r s ++;
+
i f ( f i l p >f_mode & FMODE_WRITE)
+
i n o d e > i _ p i p e > w r i t e r s ++;
+
}
+
m u t e x _ u n l o c k (& i n o d e >i _ m u t e x ) ;

return 0;
return r e t ;
}
/

Vemos que nas linhas 16 a 21 temos a insero de uma verificao do ponteiro i_pipe.

52

Logo, mesmo na presena da concorrncia, no h chance de que i_pipe seja deferenciado

com valor NULL.
Ambas as vulnerabilidades analisadas, ao nosso ver, apontam dois problemas graves.
Primeiramente, a aparente falta de rigor nos testes. Como foi possvel que uma
vulnerabilidade como CVE-2009-2692 tenha permanecido por 8 anos sem ser descoberta
pelos desenvolvedores? Como se trata de um problema de inicializao de variveis, no
seria to complexo detect-lo.
J a segunda questo que gostaramos de apontar, o problema do mapeamento do
endereo zero por parte da aplicao do usurio permitindo que o kernel o acesse e execute
cdigo nele. Na seo 2.3.4, foi demonstrado como kernel e aplicaes em modo usurio
compartilham o mesmo espao de endereamento lgico. Essa deciso tem impacto direto
sobre a possibilidade dos exploits abordados. Houvesse uma devida separao entre os
segmentos, usando os atributos de base e limite por exemplo, isso jamais ocorreria. Pois
o mapeamento do endereo zero em modo usurio no seria acessvel pelo kernel.
Como forma de tratar esse problema, foi usado o parmetro mmap_min_addr. Ele
define no sistema qual o endereo mais baixo que pode ser requisitado mapeamento
de memria via mmap. Quando seu valor diferente de zero, como 4Kb ou 64Kb, o
mapeamento para endereo zero, at o valor escolhido, fica vedado. Por padro, seu
valor era zero, mas foi elevado para 4096 a partir de junho de 2009, como resposta s
vulnerabilidades de NULL pointer. O autor do patch foi Christoph Lameter - encontrado
em (LAMETER, 2009)
5.3.3

NULL pointer em ARM e XScale

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

Como evitar o problema

H vrios caminhos que podem convergir para que no existam vulnerabilidades

causadas por ponteiros nulos. Nas sees anteriores, foram abordados diversos aspectos
que demonstraram porque o problema existe e os pr-requisitos para que ele seja
explorado.
Podemos elencar trs pontos principais sobre os quais podem se assentar as defesas e
medidas de precauo contra os exploits de NULL pointer. A preveno passa diretamente
por:
Boas escolhas arquiteturais
Um desenvolvimento consciente da ameaa do ponteiro nulo
A aplicao contnua de testes
5.4.1

Decises estruturais

A forma como o sistema concebido em termos de endereamento e possibilidades de

mapeamento das regies de memria deve estar ciente do riscos impostos por ponteiros
nulos. Conforme tratado na seo referente a exemplos de exploits, vide 5.3.2, no
aceitvel que o sistema operacional divida com a aplicao do usurio o mesmo espao
de endereamento. Considerando que
Da mesma forma, de acordo com o exposto na seo 5.3.3, qualquer deciso
arquitetural que coloque importantes estruturas de controle do sistema no endereo zero,
extremamente temerria. Isso porque havendo uma referncia a um ponteiro nulo que
possa ser explorada, o atacante tem seu trabalho facilitado uma vez que haja um alvo
direto na regio de memria zero. Arquiteturas como a XScale, que deixam a tabela de
rotina de interrupes iniciando no endereo zero, assumem um risco desnecessrio.
Assim, desde a concepo de uma arquitetura ou da organizao de um sistema
operacional, existem fatores que devem ser relevados sobre a tica de uma vulnerabilidade
de ponteiro nulo. Um design preventivo contribui decisivamente para que esse tipo de
problema sequer seja possvel. Mesmo que isso resulte em problemas de compatibilidade
ou perdas de desempenho, as escolhas mais seguras devem ter prioridade.
5.4.2

Programao consciente

Como em todas as vulnerabilidades, o papel do programador primordial. Sua

incapacidade de vislumbrar situaes de risco e trat-las devidamente faz total diferena.
absolutamente necessrio que essa forma de falha de segurana seja considerada. Um
cuidado especial deve ser tomado para que no surjam ponteiros nulos durante a execuo
de uma aplicao e, mesmo que isso ocorra, que seja devidamente detectado e tratado.
Certos procedimentos, portanto, so indispensveis. Como, por exemplo, verificar se,
ao alocar memria dinmica, no recebemos um NULL. No aceitvel que os ponteiros
sejam manipulados sem a devida verificao. O programador no pode simplesmente
assumir que receber um endereo vlido. Ambos os exploits reais apresentados, vide
5.3, poderiam ter sido evitados caso houvesse uma conferncia correta dos valores
manipulados.
Logo, o conhecimento dos riscos que a falha de NULL pointer apresenta essencial
para que os desenvolvedores construam aplicaes mais seguras. Padres para validar
ponteiros antes de seu uso devem ser apresentados e cobrados. Nesse aspecto, ferramentas

54

automticas para verificao da qualidade do cdigo podem ser um grande diferencial.

Assim, prticas de programao no seguras so detectadas desde a origem.
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

FUZZING: DETECO DE VULNERABILIDADES

Dentre muitas alternativas na busca por vulnerabilidades no software, a abordagem

fuzzing, sem dvida, deve ser destacada. Constitui um meio que pode resultar em tima
relao custo benefcio, pois pode, em muitos casos, oferecer uma resposta rpida e de
baixo custo. Vem se tornando cada vez mais sofisticada e j assume papel importante em
grandes desenvolvedores de software.

6.1

O que fuzzing?

Enquanto as tcnicas padro de teste de software se concentram em testes positivos

(tambm conhecidos como testes de conformidade), a tcnica fuzzing voltada para os
requisitos negativos. No busca testar as features, mas visa verificar o comportamento
do software nos casos em que o sistema recebe entradas mal formadas ou fora do padro
esperado.
Essa caracterstica extremamente interessante no que se refere deteco de
vulnerabilidades. Isso porque elas geralmente so descobertas quando se busca
combinaes de entradas no testadas originalmente pelo desenvolvedor.
Podemos compar-la tcnica injeo de falhas - muito embora essa seja mais
conhecida por testes em hardware. O princpio, porm, muito semelhante. Entradas
mal formadas so fornecidas ao hardware de forma a sabermos com exatido as possveis
reaes do sistema.
Considerando as observaes introduzidas acima, definimos fuzzing, conforme
(TAKANEM, 2008), como um mtodo de descoberta de falhas no software que
fornece entradas inesperadas ao sistema e o monitora esperando por excees .
Por essa definio, vemos que nenhum conhecimento do funcionamento interno da
aplicao exigido. Nesse sentido, fuzzing considerado um tipo de teste caixa preta
(Black Box Testing) - mas importante ressaltar que muito embora o cdigo fonte no
seja necessrio, ele pode ser de grande ajuda na aplicao do mtodo. H, ainda, novas
formas de fuzzing que partem do somente cdigo fonte para gerao dos testes. A
denominada fuzzing de caixa branca (Whitebox Fuzz Testing) busca aplicar o conceito
central de variao nas entradas aliada ao conhecimento interno da aplicao visando
superar barreiras intrnsecas aos testes caixa preta.
Vemos, portanto, que esse um campo extremamente amplo dentro da rea de testes
de software. Nosso intuito fornecer uma viso ampla que permita demonstrar seu valor
no contexto da busca por vulnerabilidades.

56

6.2
6.2.1

Origens e breve histrico

Uso do conceito antes do surgimento oficial

Essa metodologia de teste relativamente recente. Surge na dcada de 1980. A

primeira ferramenta com conceitos fuzzing teria surgido com o The Monkey. No
era um software, mas um gerador de cliques e movimentos de mouse que visavam
simular um macaco utilizando o Macintosh das maneiras mais inesperadas possveis. Os
desenvolvedores a consideraram uma excelente ajuda pois atravs dela puderam descobrir
uma srie de bugs e conseguiram aumentar a robustez do sistema. (HERTZFELD, 1983).
6.2.2

O surgimento oficial

A experincia acima seria uma das primeiras formas de uso do conceito de fuzzing.
Mas como marco oficial do nascimento, podemos considerar a pesquisa feita por Barton
Miller no final da dcada de 1980 e incio dos anos 90. Como fruto do seu trabalho,
surgiu a primeira ferramenta fuzzing em software chamada Fuzz. Miller e sua equipe a
utilizaram para gerar entradas randmicas para testar ferramentas bsicas dos sistemas
UNIX. Sua surpresa foi enorme em perceber como foi possvel derrubar boa parte das
aplicaes sem muito esforo. Ficava ntido o enorme potencial de um novo conceito a
ser explorado.
6.2.3

O desenvolvimento da tcnica

A partir do final da dcada de 1990, os pesquisadores, entusiasmados com os

resultados iniciais, criaram o projeto PROTOS. Seu objetivo estava na gerao de sutes de
teste capazes de simplificar a anlise de protocolos - como HTTP, DNS e SNMP. Nesse
ponto, a simples gerao de entrada randmica j havia evoludo para ferramentas que
modelavam os protocolos. No incio dos anos 2000, a Microsoft chegou a investir no
projeto PROTOS. Esse gigante do software viria apostar fortemente nesse caminho, pois
como veremos mais adiante, seo 6.7, ela ser responsvel pela criao de importantes
ferramentas na rea.

6.3

Conceitos importantes

A seguir so discutidos conceitos que so peas de grande relevncia para o melhor

entendimento da tcnica fuzzing.
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.
6.3.2

Superfcie de ataque

Muito embora a inteno seja alcanar cobertura mxima, muitas vezes certo trechos
do cdigo simplesmente so inacessveis a fatores externos. De forma que, nenhum
tipo de entrada possa alterar em nada seu comportamento. A superfcie de ataque
justamente todo o cdigo possvel de ser coberto - pois, em contraste ao exposto acima,
influencivel por aes do usurio.

57

6.4

Etapas Fuzzing

Segundo (TAKANEM, 2008), podemos dividir a aplicao da metodologia fuzzing de

teste em 5 etapas.
Identificao das entradas
Gerao das entradas
Envio das entradas
Monitoramento do alvo
Anlise dos resultados
6.4.1

Identificao das entradas

Etapa que corresponde busca por interfaces ao sistema alvo. Podem ser sockets
de rede, variveis de ambiente, arquivos, argumentos da linha de comando, interfaces
de chamada remota(RPC), entre outros. Toda e qualquer forma de comunicao que
possa influir na execuo deve ser considerada. Como um exemplo mais surpreendente,
podemos citar a memria compartilhada.
6.4.2

Gerao das entradas

o ponto crtico da metodologia. Saber como criar os dados a serem passados ao alvo.
Podem ser completamente randmicos, mutaes de dados pr-existentes ou mesmo fruto
de uma completa modelagem de um protocolo. Se estamos testando um servidor web por
exemplo, podemos gerar requisies totalmente aleatrias, alterar sesses web legtimas
gravadas para inserir possveis falhas ou at modelarmos o protocolo HTTP para criao
de sesses semi-vlidas.
6.4.3

Envio das entradas

Consiste no fornecimento das entradas criadas ao sistema alvo. Implica o contato com
o sistema atravs de suas interfaces. Seja ela a linha de comando, o sistema de arquivos
ou conexes ao um servidor. Apenas alterar uma varivel de ambiente antes de iniciar a
aplicao testada j pode ser considerada um envio de entrada.
6.4.4

Monitoramento do alvo

Pouco adianta interagir com sistema testado de todas as formas possveis sem
acompanhar criteriosamente sua execuo. Suas manifestaes devem ser observadas
e possveis falhas ou problemas, objetivos do teste, no podem passar despercebidas.
Naturalmente, quanto mais qualificada a tcnica fuzzing, maior a capacidade de
identificao de problemas no sistema alvo. Por isso, saber identificar, por exemplo,
falhas de corrupo de memria, negaes de servio, acessos no permitidos, constitui
o grande diferencial de um fuzzer. O uso de um debugger na aplicao alvo uma das
alternativas.
6.4.5

Anlise dos resultados

Com as informaes coletadas pelo monitoramento, torna-se necessrio identificar se

existem ou no falhas de segurana. Muitas vezes os problemas manifestados constituem

58

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.

6.5

Tipos de fuzzers

Para classificar os fuzzers podemos seguir dois critrios bsicos. Eles determinam a
rea de atuao e o tipo de entradas geradas.
Tipo de vetor de ataque
Complexidade dos casos de teste
6.5.1

Tipos por vetor de ataque

De acordo com o tipo de aplicao ao qual o fuzzer se dirige, ele possui um

determinado vetor de ataque. Pode ser voltado, por exemplo, para testes de clientes web
(como browsers). Nesse caso, seu vetor de ataque est no protocolo HTTP. De forma
anloga, se for voltado para testes de leitores de pdf, seu vetor de ataque estar na gerao
dos arquivos.
6.5.2

Tipos por complexidade de casos de teste

A complexidade com que o fuzzer cria suas entradas constitui outro meio de
classificao. Alguns podem ser muito simples pois apenas randomizam certos
parmetros antes de fornec-los ao sistema alvo. Outros, porm, podem conter todo um
modelo de um protocolo; sendo capazes de gerar complexas interaes semi-vlidas em
que apenas certos parmetros sofrem algum tipo de alterao visando disparar algum erro.
Geralmente, os mais simples, meramente randmicos, acabam possuindo baixa
cobertura do cdigo testado. Isso porque eles no alcanam grande profundidade na
aplicao testada. Logo na superfcie, algum parmetro gerado acaba no sendo aceito e
mudanas em outros pontos da entrada sequer so considerados. o caso, por exemplo,
de um testador de um servidor HTTP que, sendo totalmente randmico, cria apenas
requisies mal formadas que sequer chegam a disparar alguma rotina de gerao de
resposta pelo servidor.
Por esse critrio, podemos citar as seguintes famlias de fuzzer:
Estticos ou randmicos Os mais simples. No possuem qualquer noo de protocolo.
Testam aplicaes baseadas em requisio/resposta sem controle de estado.
Baseados em bloco Implementam estruturas bsicas de requisio/resposta e so
capazes de validar as entradas de forma a respeitar parmetros como checksums.
De gerao dinmica ou baseados em evoluo No compreendem o protocolo a ser
testado, mas baseado nas respostas do sistema podem, dinamicamente, gerar
entradas.
Baseados em modelos ou simuladores Podem constituir a implementao completa de
um protocolo. Permitem gerar entradas que em sequncia de acordo com um estado.
Por isso, podem, por exemplo, interagir com aplicaes que trabalham com sesses.

59

6.6

Monitoramento da aplicao

A interao com a aplicao testada torna possvel examin-la de forma a revelar os

erros; ainda assim, isso de nada til caso no saibamos identificar no sistema alvo os
sintomas das falhas. O monitoramento o responsvel por passar os alertas de problemas.
Logo a pergunta que se impe : o que pode ocorrer no sistema indicando uma falha?
Entre as manifestaes que devem ser reconhecidas pelo monitoramento, podemos citar:
Negaes de servio (DoS) (o sistema deixa de responder)
Problemas relacionados memria (segfault)
Injeo de metadados (como injeo de SQL)
Permisso de acesso a reas proibidas
As formas de monitoramento variam, naturalmente, tanto quanto os prprios sistemas
testados. Acompanhar uma aplicao escrita em C e um portal web em PHP so tarefas
bem distintas - exigindo, naturalmente, tcnicas diferenciadas.
Uma forma genrica garantir que o alvo est sempre respondendo corretamente
a certas interaes. Assim, possvel identificar se ocorre ou no uma negao de
servio. Logo, manter requisies bem formadas com respostas conhecidas intercaladas
aos demais testes, auxilia o reconhecimento de falhas.
Outro meio, talvez o mais natural, acompanhar a sada gerada pelo alvo na suas
mais variadas formas. o caso da sada padro, dos logs, de arquivos temporrios, entre
outros. O fuzzer pode procurar por padres que revelem as falhas - como, por exemplo,
avisos de erros de corrupo de memria.
O uso de um depurador (debugger) tambm constitui outra forma de monitoramento.
Com esse recurso, podemos esperar por determinadas excees e descobr-las to
prontamente os casos de teste as gerem.
6.6.1

Meios intrusivos

Para auxiliar na descoberta das falhas o mais na origem possvel, existem mtodos
ainda mais intrusivos que os expostos anteriormente. Fazer com que a aplicao testada
carregue bibliotecas diferentes das originais um dos caminhos.
Trocando a biblioteca que faz o gerenciamento de memria dinmica, responsvel
pelo chamadas como malloc(), possvel devolver devolver aplicao blocos de
memria que permitam a fcil identificao de overflows. Assim, muito antes que um
erro de corrupo de memria fosse gerado, ele j teria sido detectado.
Numa mesma abordagem, a tcnica chamada simulao binria, (TAKANEM, 2008)
pg. 181, tambm visa acompanhar com enorme proximidade o sistema alvo. Esse o
caso da ferramenta Valgrind (encontrada em http://valgrind.org). Nela, usada uma CPU
sinttica que recebe todas as instrues e pode analis-las na busca por problemas antes
de serem repassadas CPU real. Todos os acessos memria so controlados. Com esse
tipo de acompanhamento, as vulnerabilidades podem ser encontradas em tempo real e
informaes valiosas sobre sua possibilidade de explorao j so conhecidas.

6.7

White Fuzz Testing: execuo simblica e fuzzing

Nessa seo, apresentamos uma nova abordagem do ramo fuzzing. Fruto da pesquisa
de Patrice Godefroid e associados descrita em (GODEFROID, 2008). Originalmente,

60

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.1

Deficincias do mtodo caixa preta

Antes de apresentarmos a tcnica de fuzzing caixa branca desenvolvida por

pesquisadores da Microsoft, necessrio expor certas deficincias naturais dos testes de
caixa preta.
Tomemos como exemplo uma aplicao que possua 3 parmetros de entrada (de 32
bits): x, y e z. No seu cdigo fonte, existe uma condio na qual, a menos que valor de
y seja 25, apenas um primeiro bloco da aplicao executado. Logo percebemos que,
a cobertura de um teste caixa preta nesse caso fica seriamente prejudicada. Dificilmente
teremos entradas geradas com essa particularidade a ponto de explorar com efetividade
possveis erros. Essa dificuldade de percorrer todos os caminhos de execuo possveis
um fator que limita muito a capacidade da maioria das abordagens fuzzing de caixa preta.
6.7.2

Funcionamento bsico

A tcnica opera fornecendo, primeiramente, entradas vlidas aplicao. Ento

ela executada simbolicamente com todas as condies sendo registradas. Cada um
dos blocos condicionais acaba escolhendo um caminho distinto de execuo dadas as
entradas iniciais. Assim, possvel saber que certos valores de entradas implicam a
explorao de certos caminhos. Numa prxima execuo, usando um resolvedor lgico,
as condies so negadas de forma a descobrir novos valores de entrada que possibilitem
que a aplicao siga outros caminhos.
Operando iterativamente, o fuzzer aliado execuo simblica acaba explorando os
mais variados caminhos existentes. O intuito garantir que situaes inesperadas sejam
encontradas graas a combinaes de entradas escolhidas justamente para adentrar os
blocos de cdigo que podem no ter sido testados adequadamente.
Para ilustrar, simplificadamente, apresentamos abaixo um pequeno trecho de cdigo.
1
2
3
4
5
6
7
8
9

Listing 6.1: Cdigo de teste para ilustrar tcnica

void t e s t ( i n t a , i n t b ) {
i f ( a > 10) {
i f ( b == 5 )
error () ;
ok ( ) ;
} else {
ok ( ) ;
}
}
No caso acima, a poderamos fornecer, inicialmente, os valores 0 e 1 para a e
b respectivamente. O primeiro bloco condicional, avaliado pela execuo simblica,
assumiria falso e cairamos em ok().
Na segunda etapa, o resolvedor dos blocos condicionais, buscando negar a primeira
condio, descobriria, que o valor de a deveria ser 11. Mantido o valor inicial de b,
conseguiramos, nessa nova execuo simblica, chegar em um novo bloco condicional.

61

Dessa vez, b sendo 1, camos novamente em ok(). Na iterao seguinte, porm, o

algoritmo seria capaz de identificar que, para negar o segundo bloco condicional, seria
preciso que b assumisse o valor 5. Assim, com a valendo 11 e b com valor 5, numa ltima
execuo encontraramos error().
Logo, o Whitebox Fuzz necessita de um sistema muito sofisticado de execuo
simblica bem como um resolvedor de condies suficientemente inteligente para
encontrar os valores corretos de entradas que explorem toda aplicao.
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:
Exploso combinatorial de caminhos
Imperfeies da execuo simblica
Devido a enorme quantidade de possveis caminhos de uma aplicao de grande porte,
pode no ser factvel explorar a todos. Isso pode ser contornado examinando certas
funes em isolado atravs de sumrios que identificam pr-condies e ps-condies
de cada uma.
Alm da dificuldade da quantidade dos caminhos, as imperfeies na execuo
simblica podem apresentar srias restries. Instrues muito complexas bem como
chamadas de sistema e de certas bibliotecas podem ser extremamente difceis de prever.
Nesses casos, a randomizao pode ser usada mas gerando prejuzos preciso.
6.7.4

SAGE: implementao da tcnica

Como resultado da pesquisa, foi implementado na Microsoft, a ferramenta SAGE

(Scalable, Automated, Guided Execution). Embora o acesso a SAGE seja restrito a
pessoal da empresa, a abordagem aplicada de domnio pblico. Pela experincia
relatada em (GODEFROID, 2008), possvel dizer que a SAGE foi bem sucedida em
encontrar erros de segurana at ento no descobertos por outras ferramentas. Os
autores, observam, porm, que uma das suas grandes dificuldades a lentido imposta
pela execuo simblica.

62

CONCLUSO

Nesse trabalho foram abordados aspectos essenciais relacionados segurana do

software. Ao tratar de vulnerabilidades e tcnicas de exploits, ele objetivou trazer ao
leitor um contexto fundamental para um entendimento da rea. Dada a relevncia que o
software atingiu nos dias de hoje, no mais admissvel que qualquer desenvolvimento
srio desconsidere princpios de segurana. Sendo eles: as possveis vulnerabilidades, as
formas de ataque e, naturalmente, as formas de preveno.
No que se refere s vulnerabilidades, esse trabalho, ao tratar de sua classificao,
pode identificar que esse tpico ainda no pacfico no meio acadmico ou industrial.
Mesmo que tenham sidos feitos avanos, a comunidade carece de um padro aceito
uniformemente. Ficou ntido que a complexidade dessa tarefa enorme. O prprio
carter multifacetado das vulnerabilidades explica um pouco essa barreira; elas podem
ser analisados por diversos ngulos e estamos longe de encontrar uma viso unificadora
que traga sentido a todas suas faces. Apenas assim seria alcanada uma taxonomia em
sentido estrito.
No campo dos exploits, pode ser visto que, com a evoluo natural das tcnicas de
ataque e de defesa, a vida dos especialistas na rea torna-se cada vez mais rdua. As
formas mais simples de explorar vulnerabilidades j no so mais efetivas; seja porque as
falhas que as tornam possveis ficaram menos frequentes no desenvolvimento, seja porque
protees mais bem concebidas foram sendo habilitadas por padro nos sistemas. Isso vai
obrigando os atacantes a encontrarem novos mtodos cada vez mais sofisticados que,
naturalmente, vo exigindo conhecimento ainda mais especfico. Em alguns momentos,
porm, ainda ser possvel surgir alguma espcie de reviravolta - como na descoberta
dos diversos erros de NULL pointer no kernel do Linux. Episdio que demonstrou a
existncia de uma srie de falhas por vrios anos em um dos sistemas mais utilizados surpreendentemente, algumas delas de fcil explorao.
Para a preveno de problemas de segurana no software, uma das principais
propostas apresentadas foi o uso do testes fuzzing. Sendo uma tcnica extremamente
eficiente e que j vem sendo usada por atacantes para a descoberta de problemas nos
sistemas, esse trabalho buscou demonstrar seu valor e indic-la como arma a ser utilizada
pelos prprios desenvolvedores. Por que j no conceber, desde o princpio, um projeto
considerando essa alternativa de teste se os atacantes certamente iro utiliz-la? Conforme
foi visto, gigantes da rea, como a Microsoft, j perceberam seu enorme valor e investem
fortemente nela. necessrio, portanto, que, ao menos, consideremos essa possibilidade.
Isso porque no aceitvel correr o risco de deixar apenas para os atacantes utilizarem e
aperfeioarem uma tcnica que possa desequilibrar em favor deles.

63

REFERNCIAS

ANLEY, C. The shellcoders Handbook: discovering and exploring security holes.

2a .ed. [S.l.]: Wiley Publishing, Inc., 2007.
BOVET, D. P. Understanding the Linux Kernel, 3rd Edition. [S.l.]: OReilly, 2005.
CHEN, S. Non-Control-Data Attacks Are Realistic Threats. Junho, 2005. Disponvel
em: http://research.microsoft.com/en-us/um/people/shuochen/papers/usenix05data_attack.pdf.
Acessado em Junho 2010.
CHEW, E. Linux kernel git commit: pipe.c null pointer deference. Outubro,
2009. Disponvel em: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;
a=commitdiff;h=ad3960243e55320d74195fb85c975e0a8cc4466c. Acesso em: junho
2010.
CHRISTEY,
S.
PLOVER.
Maro,
2006.
Disponvel
http://cwe.mitre.org/documents/sources/PLOVER.pdf. Acesso em: junho 2010.

em:

COMMITTEE, P. I. T. A. Cyber Security: a crisis of prioritization. Disponvel em:

http://www.nitrd.gov/pitac/reports/20050301_cybersecurity/cybersecurity.pdf. Acessado
em: junho 2010.
COX, M. J. Red Hats Top 11 Most Serious Flaw Types for 2009. Feveiro, 2010.
Disponvel em: http://www.awe.com/mark/blog/20100216.html . Acesso em: junho
2010.
CUNNINGHAM, J. S. Eight Years of Linux Kernel Vulnerable. Agosto, 2009.
Disponvel em: http://www.osnews.com/story/21993/Eight_Years_of_Linux_Kernel_Vulnerable.
Acesso em: junho 2010.
CVE. CVE FAQ. Janeiro, 2010. Disponvel em: http://cve.mitre.org/about/faqs.html.
Acesso em: maio 2010.
CWE.
About
CWE.
Setembro,
2007.
http://cwe.mitre.org/about/index.html. Acessado em: junho 2010.

Disponvel

em:

CWE. Process. Agosto, 2009. Disponvel em: http://cwe.mitre.org/about/process.html.

Acessado em: junho 2010.
DHANJANI, N. Hacking: the next generation. [S.l.]: OReilly, 2009.
DOWD, M. Application-Specific Attacks: leveraging the actionscript virtual machine.
IBM Global Technology Services, [S.l.], p.25, 2008.

64

FLORIAN, C. Vulnerability Related Standards. Outubro 2009. Disponvel em:

http://www.gfi.com/blog/vulnerability-related-standards/. Acesso em: maio 2010.
FURLAN, L. H. Estudo sobre Estouros de Buffer. 2005. Trabalho de concluso de
curso Instituto de Informrtica da UFRGS.
GODEFROID, P. Automated Whitebox Fuzz Testing. Network Distributed Security
Symposium (NDSS), [S.l.], p.16, 2008.
GRGIO, A. R. A. Um Estudo sobre Taxonomias de Vulnerabilidades. Disponvel em
http://mtc-m18.sid.inpe.br/dpi.inpe.br/hermes2@1905/2005/10.04.04.11. Acessado em:
Junho 2010.
GRGIO, A. R. A. Taxonomias de Vulnerabilidades: situao atual. V Simpsio
Brasileiro em Segurana da Informao e de Sistemas Computacionais, [S.l.], 2005.
HARRIS, S. Gray Hat Hacking: the ethical hackers handbook. [S.l.]: McGraw, 2008.
HERTZFELD, A. Folklore story about Monkey. Outubro, 1983. Disponvel em:
www.folklore.org/StoryView.py?story=Monkey_Lives.txt. Acesso em: junho 2010.
HOGLUND, G. Exploiting Software: how to break code. [S.l.]: Addison-Wesley
Professional, 2004.
HOLANDA FERREIRA, A. B. de. Novo Dicionrio Aurlio da Lngua portuguesa.
1a .ed. [S.l.: s.n.], 1975.
JACK, B. Vector Rewrite Attack: exploitable null pointer vulnerabilities on arm and
xscale architectures. Juniper, [S.l.], 2007.
LAMETER, C. Linux kernel git commit:
use mmap_min_addr
independently
of
security
models.
Junho,
2009.
Disponvel
em:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;
a=commit;h=e0a94c2a63f2644826069044649669b5e7ca75d3. Acessado em: Junho
2010.
LOVE, R. Linux System Programming. 1a .ed. [S.l.]: OReilly Media, Inc., 2007.
MANN, D. E. Towards a Common Enumeration of Vulnerabilities. The MITRE
Corporation, [S.l.], 1999.
MARTIN, R. A. The Vulnerabilities of Developing on the Net. Janeiro, 2001.
Disponvel em: http://cve.mitre.org/docs/docs-2001/DevelopingOnNet.html. Acessado
em Junho 2010.
MARTINS, H. G. Estudo sobre a explorao de vulnerabilidades via estouros de
buffer, sobre mecanismos de proteo e suas fraquezas. 2009. Dissertao (Mestrado
em Cincia da Computao) Instituto de Informrtica da UFRGS.
MCGRAW, G. Software Security: building security in. [S.l.: s.n.], 2006.
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

MEUNIER, P. Classes of Vulnerabilities and Attacks. [S.l.]: Wiley Handbook of

Science and Technology for Homeland Security, 2006.
RATANAWORABHAN, P. Nozzle:
a defense against heap-spraying
code
injection
attacks.
Novembro,
2008.
Disponvel
em:
http://research.microsoft.com/pubs/76528/tr-2008-176.pdf. Acessado em:
Junho
2010.
SANTOS BRANDO, A. J. dos. O Uso de Ontologia em Alertas de Vulnerabilidades. IV
Workshop em Segurana de Sistemas Computacionais, [S.l.], 2004.
SEACORD, R. C. A structured approach to classifying security vulnerabilities. [S.l.]:
CMU/SEI, 2005.
SECURE
SOFTWARE,
I.
The
CLASP
Application
Security
Process.
Janeiro,
2006.
Disponvel
em:
http://searchappsecurity.techtarget.com/searchAppSecurity/downloads/clasp_v20.pdf
. Acessado em: Junho 2010.
TAKANEM, A. Fuzzing for Software Security Testing and Quality Assurance. [S.l.]:
Artech House, INC., 2008.
TINNES,
J.
Linux
NULL
pointer
deference
due
to
incorrect
proto_ops
initializations.
Agosto,
2009.
Disponvel
em:
http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html. Acesso em:
maio 2010.
TSIPENYUK, K. Seven Pernicious Kingdoms: a taxonomy of software security errors.
NIST Workshop on Software Security Assurance Tools, Techniques, and Metrics,
[S.l.], 2005.

66

APNDICE A

A.1

EQUAES CVSS 2.0

Equaes do escore bsico

EscoreBasico = ((0.6 Impacto) + (0.4 Explorabilidade) 1.5) algo

(A.1)

Impacto = 10.41 (1 (1 ImactoConf ) (1 ImpactoInt) (1 ImpactoDisp))

(A.2)
Explorabilidade = 20 V etorAcesso ComplexidadeAcesso N ecessidadeAut
(A.3)

A.2

Equaes do escore temporal

Utiliza o escore bsico.

EscoreT emporal = EscoreBasico F acExploracao N ivelRemed Conf Report
(A.4)

A.3

Equaes do escore ambiental

Utiliza o escore temporal.

EscoreT emporal = EscoreBasico F acExploracao N ivelRemed Conf Report
(A.5)

67

Mtricas bsicas
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
Mtrica

Mtricas temporais
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
Mtrica

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