internship-report-vlc/chapters/why_sandboxing.tex

\section{Objectifs}

Dans la partie précédente, nous avons détaillé ce qu'était le sandboxing,
apparaissant comme dernière mesure une fois l'application corrompue par une
attaque. On peut alors se demander s'il ne vaut pas mieux concentrer ses efforts
sur l'audit et le renforcement du reste du code. On pourrait par exemple
imaginer la réécriture de l'ensemble du code de VLC dans un langage apportant
plus de garanties de sécurité. Après tout, s'il n'y a pas de faille possible, il
n'y a pas besoin de se protéger de ses failles.

Dans le monde réel, ces deux objectifs de sécurité, le sandboxing et la
réduction des failles, sont totalement orthogonaux et les deux efforts doivent
être réalisés en même temps. Corriger des brêches dans la sécurité de
l'application permet de s'assurer que le samdboxing fonctionne plus
efficacement, tandis qu'isoler les différentes parties de l'application permet
de limiter l'impact d'une faille potentielle avant qu'elle soit corrigée.

Le sandboxing joue ici le rôle de réduction de la surface d'attaque, qui est un
mécanisme classique. Le code en lui-même de la sandbox est censé être plus
facilement auditable, beaucoup plus court et moins dépendant du domaine lié à la
solution qu'apporte le logiciel, c'est-à-dire ne pas forcément saisir les
spécificités liées au multimédia dans notre cas. C'est donc particulièrement
intéressant dans le cadre de logiciels comme VLC ou Chromium qui demande une
palette de compétences assez large.

Il faut néanmoins ne pas oublier qu'il ne s'agit pas d'un patch magique. Une
sandbox intrusive introduit du nouveau code et de nouvelles interactions avec le
système sous-jacent. De nouvelles failles peuvent donc apparaître, liées soit au
noyau du système et des API de sandboxing, soit parce que le code n'est pas
suffisamment robuste ou suffisamment découplé de l'application. Il faut donc
mettre une attention particulière à la vérification des mesures mises en place.

\section{Exemples d'attaques}

Si les objectifs et besoins décrits au dessus paraissemt trop théorique, il est
possible de prendre des exemples de la vraie vie pour se convaincre d'avoir
besoin de ces mesures. L'exemple le plus connu de sandbox intrusive est celle
de Chromium, qui s'appelle lui-même \og{}The Most Secure Browser.\fg{} Le développement
de Chromium est basé depuis ses commencements sur un modèle de sandbox.
L'application a donc dès le départ été écrite avec l'isolation des modules en
tête. Plusieurs exemples d'attaques ont été montrées.

Un exemple est celle de Jordan Rabet, présenté dans sa conférence à la BlueHat
IL\cite{JRabetBrowserSecurity}.
Il utilise notamment des techniques de fuzzing pour trouver \og{}facilement\fg{} un
déréférencement de pointeur invalide \footnote{dans l'optimisation Just-In-Time
du moteur javascript} dans un des processus \og{}renderer\fg{} de Chromium. Les
renderers étant plus ou moins confinés à l'onglet, l'attaque est confinée au
contenu même qui lui permet d'exister et n'apporte donc plus de valeur ajoutée.

Malheureusement tout n'est pas complètement pensé pour la sécurité. L'exemple d'une
fonctionnalités qui était activée par défaut dans chromium sur quelques distributions Linux
permettait à un site de faire télécharger un fichier sans l'accord de la
personne montre les failles liés à l'expérience utilisateur. 

Pour les personnes utilisant Gnome ou KDE, un tracker de fichier tourne en tâche
de fond afin d'indexer les métadonnées des fichiers, en particulier des images
et vidéos. Ces trackers utilisent la plupart du temps directement GStreamer ou
ImageMagick pour pouvoir parser les fichiers et extraire les métadonnées, et il
était alors possible d'écrire une attaque pour exploiter ces bibliothèques
depuis un site web\cite{GstreamerSecuIssue}.

\section{Dans VLC}

% TODO expliquer ce qu'est une CVE
Le sandboxing apporte particulièrement une plus grande confiance dans VLC qui a
déjà subit plusieurs failles qui ont été exposées publiquement dans des CVE
\footnote{Common Vulnerabilities and Exposures}. Ces failles touchent en grande
partie les modules de demux, qui permettent de récupérer les différents flux,
audio, vidéo et sous-titre d'un flux multimédia.

VLC étant programmé majoritairement en C et C++, est particulièrement sensible à
une grande classe de défauts exploitable, comptant par exemple les use after
free, buffer overflow, double free, corruption mémoire, etc. Ces défauts
arrivent la majorité du temps dans des chemins d'exécution impliquant de la
manipulation de blocs de données et son interprétation, donc impliquant en
particulier ces modules demux.

Or on peut noter que la plupart des demux n'ont pas besoin d'accès ou de\
permissions en particulier : ce sont des parseurs de données. Ils doivent
seulement avoir accès à certains blocs mémoires en entrées et générer de
nouveaux blocs mémoires en sortie.

Les isoler du reste de l'application permet donc de fortement limiter l'impact
de ces modules, laissant à l'exécution de code arbitraire la nécessité
d'exploiter également des failles de sandboxing et plus seulement des failles
lié au travail multimédia réalisé par VLC.

C'est d'autant plus vrai lorsque la libvlc, qui utilise directement ces
modules, peut être utilisée dans d'autres applications potentiellement plus
critiques.