123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293 |
- \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 «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.
- 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 «facilement» un
- déréférencement de pointeur invalide \footnote{dans l'optimisation Just-In-Time
- du moteur javascript} dans un des processus «renderer» 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.
|