notes/vlc/04_02_pourquoi_sandboxer.md

Pourquoi faire du sandboxing est important

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 orthogonal 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 donc particulièrement intéressant dans le cas du multimédia 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.

Dans VLC

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.

Dans la vraie vie

Si les objectifs et besoin décrits au dessus ne suffisent pas à convaincre, prendre des exemples de la vraie vie permet de se persuader 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.