-
Notifications
You must be signed in to change notification settings - Fork 0
/
conclusioni.tex
122 lines (104 loc) · 5.71 KB
/
conclusioni.tex
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
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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
\chapter{Conclusioni}
Lo sviluppo di uno strumento come Dropper mi ha permesso di studiare
ed esplorare problematiche interessanti e complesse. Uno strumento che
riesce infatti ad analizzare un file binario e da esso estrarne in
maniera automatica le informazioni necessarie per poter costruire un
payload funzionante implica la risoluzione di diverse problematiche
che abbracciano più aree dell'informatica. In particolare in questo
lavoro alcuni strumenti propri dell'intelligenza artificiale hanno
giocato un ruolo cruciale rendendo evidente l'apporto che questa
disciplina può dare all'area della sicurezza informatica in
generale. Tra le problematiche più rilevanti nello sviluppo di uno
strumento come Dropper elenchiamo:
\begin{enumerate}
\item L'estrapolazione della semantica dei singoli gadget
\item L'individuazione di una sequenza di gadget che ci consente di
eseguire una data operazione. Questo punto è complicato dal fatto che gli
effetti di un gadget possono interferire con quelli di un altro
nonché con l'esecuzione stessa del programma in esame
\item Scegliere, in base alle operazioni disponibili, la strategia da
utilizzare per eseguire l'exploit
\item Individuare una sequenza di operazioni che eseguono con successo
una data strategia
\end{enumerate}
Il primo punto è stato affrontato, come descritto nei capitoli
\ref{cap:architettura} e \ref{cap:implementazione}, attraverso sia
tecniche di emulazione che tecniche di verifica basate sulla
rappresentazione in formule logiche delle istruzioni dei
gadget. Dropper può estrapolare la semantica di diverse tipologie di
gadget che ci permettono di eseguire operazioni, come il caricamento di
costanti nei registri o l'effettuare operazioni aritmetiche in
locazioni di memoria arbitrarie, e ed è facilmente estendibile per
incorporare ulteriori analisi semantiche che consentano di eseguire
operazioni sempre più complesse.
La scelta di una sequenza di gadget che ci permetta di eseguire
un'operazione articolata è un'altra problematica
interessante. Infatti, oltre ad essere sicuri che la catena abbia gli
effetti desiderati, è interessante cercare, tra le sequenze di gadget
che ci permettano una particolare operazione, quella che produca un
payload di minore lunghezza. Infatti, anche se questo dipende molto
dalla tipologia di errore che si sta sfruttando, spesso si è limitati
nella quantità di dati da poter iniettare.
Le catene che attualmente dropper riesce a generare ci consentono di
avere una visione ad un livello di astrazione più alto delle
operazioni che possiamo eseguire con i singoli gadget. Per generare
catene di queste operazioni, come descritto nei capitoli precedenti,
si utilizza un approccio per lo più programmatico, usando quando
possibile algoritmi greedy per la generazione di soluzioni di una
certa qualità. Tuttavia il problema di generazione di una catena,
definito come l'ordine nel quale effettuare alcune azioni (i gadget)
per raggiungere un dato stato del sistema, si presta naturalmente ad
una traduzione in un problema di planning.
Alcune considerazioni su questo approccio, insieme ad una prima
possibile modellazione che utilizzi il linguaggio PDDL 2.1
\cite{pddl-97,fox-03} sono riportate nella sez. \ref{sec:pddl}.
Le ultime problematiche che sono state affrontate, nella nostra
panoramica dal basso verso l'alto, sono la scelta di una tecnica di
exploiting e di una sequenza di operazioni per applicare tale
tecniche. Tra le strategie applicate con successo nei primi testcase
troviamo
\begin{inparaenum}[1)]
\item l'utilizzo della funzione ``read'' per la scrittura in memoria
\item utilizzo di sequenza di gadget sempre per la scrittura in memoria
\item got patching e
\item return-to-plt
\end{inparaenum}
Trovare le sequenze per portare a termine queste tecniche è un
problema per certi versi simile a trovare le catene di gadget per
eseguire le operazioni ``elementari'', ma da un punto di astrazione
più alto. Vi è qui, tra le difficoltà più rilevanti, quella di
esaminare tutte le possibili sequenze di operazioni per applicare
quella tecnica. In questa fase i vantaggi dell'utilizzo di un planner
sembrano ancora più rilevanti.
I test durante lo sviluppo sono stati effettuati prendendo in esame
alcuni livelli di exploit-exercise\cite{exploit-exercise} e alcuni
eseguibili contenuti nelle bin-utils (ls, echo, mv).
\section{Sviluppi futuri}
Di seguito sono elencate alcune idee per lo sviluppo futuro di Dropper:
\begin{itemize}
\item Utilizzo di un'esecuzione simbolica, che semplificherebbe di
molto l'analisi semantica, potendo verificare direttamente le
relazioni tra valori in ingresso ed effetti dei gadget
\item Ulteriori indagini sull'utilizzo di una modellazione in
problemi di planning
\item Estrapolazione di gadget non ``classici''. Ad esempio
un'estensione della ROP consiste nell'utilizzare sequenze di
istruzioni che terminano con un'istruzione di tipo
\lstinline{jmp} invece che con una di tipo \lstinline{ret}
(infatti questa tecnica prende il nome di \emph{Jump Oriented
Programming} \cite{Checkoway-10}).
Un altro esempio è quello di ricercare gadget di lunghezza maggiore ma
con effetti secondari ``controllabili'', ad esempio obbligando il
gadget a seguire un flusso di esecuzione piuttosto che
un altro. Quest'ultima tipologia di gadget è necessaria per eludere
alcune tecniche di mitigazione che si basano sul monitoraggio di un
numero limitato di istruzioni
\item Aumentare le architetture supportate
\item Implementazione di nuove strategie di exploit e rendere
più semplice l'incorporazione di strategie definite
dall'utente
\end{itemize}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "tesi"
%%% End: