Browse Source

chapters/why_sandboxing: correction du titre et des termes employés

Alexandre Janniaux 7 years ago
parent
commit
818192076a
1 changed files with 13 additions and 12 deletions
  1. 13 12
      chapters/why_sandboxing.tex

+ 13 - 12
chapters/why_sandboxing.tex

@@ -52,19 +52,20 @@ 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
 d'exploiter également des failles de sandboxing et plus seulement des failles
 lié au travail multimédia réalisé par VLC.
 lié au travail multimédia réalisé par VLC.
 
 
-\section{Dans la vraie vie}
+\section{Exemples d'attaques}
 
 
-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.
+Si les objectifs et besoin décrits au dessus paraissemt trop thérique, 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
 TODO: lien