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{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 CVE. Ces CVE 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.

\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 «The Most Secure Browser.» 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, comme celle de TODO:Xxxx
utilisant des techniques de fuzzing pour trouver un déréférencement de pointeur
invalide dans l'optimisation Just-In-Time du moteur javascript qui tourne dans
un processus «Renderer» plus ou moins dédié à l'onglet. Les failles peuvent
ainsi toujours exister, mais restent confinées au contenu apportant leur
exploitation.

TODO: lien

Malheureusement tout n'est pas complètement pensé pour la sécurité et une des
fonctionnalités qui était activée par défaut sur quelques distributions Linux
permettait à un site de faire télécharger un fichier sans l'accord de la
personne. Or, 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 ImageMagik pour pouvoir parser les fichiers et extraire
les métadonnées.