% Des correctifs de s�curit� � la mise � jour
Nicolas Loriant - Marc S�gura-Devillechaise - Jean-Marc Menaud
The ever growing software complexity suggests that they will never be bugfree and therefore secure. Software compagnies regulary publish updates. But maybe because of lack of time or care or maybe because stopping application is annoying, such updates are rarely if ever deployed on users' machines. \\ We propose an integrated tool allowing system administrators to deploy critical security updates on the fly on applications running remotly without end-user intervention. Our approach is based on an aspect weaving system, Arachne, that dynamicaly rewrites binary code. Hence updated applications are still running while they are updated. Our second tool Minerve integrates Arachne within the standart updating process: Minerve takes a patch produced by diff and eventually builds a dynamic patch that can later be woven to update the application on the fly. In addition, Minerve allows to consult patches translated in a dedicated language and hence eases auditing tasks.
arachne.tex
\section{Arachne : injection dynamique des correctifs}\label{sec:ara}
\indent Cette section d�crit  les outils associ�s � Arachne permettant au RSSI de compiler la rustine dynamique avant de l'injecter dans l'application � mettre � jour, puis s'ach�ve par une vue d'ensemble des m�canismes exploit�s dans la mise en \oe uvre d'Arachne.

\subsection{Les outils de compilation et de d�ploiement}\label{sec.arachne.compil}
\indent Arachne s'accompagne de deux outils, un compilateur d'aspects \texttt{acc}, g�n�rant une DLL native et un tisseur \texttt{weave} permettant d'injecter, \emph{tisser} les aspects compil�s dans l'application incrimin�e. Ind�pendamment de notre hypoth�se de travail qui suppose que la rustine traduite par \Nom est correcte, la compilation effectu�e par \texttt{acc} constitue une v�rification globale de la coh�rence de la rustine. Plus pr�cis�ment, elle garantit l'absence d'erreurs syntaxiques. De plus, � l'injection, \texttt{weave} v�rifie que l'application � mettre � jour contient bien les symboles attendus par la rustine. Ainsi, si une rustine essaie de remplacer une fonction ou une variable globale qui n'est pas d�finie dans l'application, l'injection de la rustine �choue. Bien que ce type de v�rification ne permette pas de garantir que la rustine corrige le trou de s�curit�, il permet n�anmoins d'assurer un niveau minimal de coh�rence. Si la rustine n�cessite plusieurs points d'instrumentation, Arachne garantit l'atomicit� de la r��criture : soit toutes les fonctions/variables sont remplac�es soit aucune. Enfin, une option particuli�re permet � Arachne de v�rifier si une fonction � remplacer est en cours d'ex�cution et dans l'affirmative, d'attendre la fin d'ex�cution avant le tissage.

\subsection{Impl�mentation d'Arachne}\label{sec.arachne.impl}
\indent Le tisseur d'Arachne, pilot� par la commande \emph{weave}, r�crit � la vol�e le code binaire de l'application dans laquelle il doit injecter les aspects \cite{segura-menaud-al.aosd2003}. Il est difficile de couvrir les diff�rentes strat�gies de r��criture utilis�es par le tisseur. Nous pr�cisons ici toutefois le principe g�n�ral qui permet � Arachne de remplacer une fonction par une autre avant de pr�ciser les probl�mes techniques qui compliquent sa mise en oeuvre. \\

\indent Sur une machine Pentium sous Linux, un appel de fonction au niveau source se traduit dans le code binaire de l'application par une instruction assembleur \texttt{CALL}  suivie de l'adresse de la fonction � invoquer. Arachne d�sassemble le code binaire de l'application et y recherche les instructions \texttt{CALL}. Pour cela, il utilise les tables de symboles g�n�r�es � la compilation pour retrouver, � partir de l'adresse manipul�e par l'instruction \texttt{CALL}, le nom symbolique de la fonction invoqu�e. Au tissage, Arachne charge la DLL contenant les aspects et r�crit les diff�rents \texttt{CALL} vers la fonction � remplacer par des \texttt{CALL} vers la fonction appropri�e de la DLL. Un m�canisme similaire mais plus complexe permet � Arachne de remplacer les lectures/�critures sur les variables globales. \\
\indent En pratique, plusieurs probl�mes compliquent la mise en oeuvre du principe de r��criture d�crit plus haut. En r�sum�, il s'agit de garantir l'atomicit� des r��critures effectu�es dans le code objet de l'application, d'assurer la coh�rence de l'ex�cution, de garantir que l'ensemble des aspects de la DLL soit tiss�s d'une mani�re atomique (c'est-�-dire qu'un aspect ne puisse pas s'ex�cuter alors que les autres sont en train d'�tre tiss�s), de g�rer les contraintes impos�es par le syst�me d'exploitation en terme de s�paration des espaces d'adressage et finalement de r�soudre les probl�mes d'efficacit�. Arachne r�sous les probl�mes d'atomicit� des r��critures par un syst�me de verrous tournants reposant sur la taille des instructions de sauts courts et sur la taille des acc�s m�moire atomiques sous Pentium. La coh�rence de l'ex�cution est assur�e par un crochet g�n�r� � la vol�e lors du tissage : Ce crochet sauvegarde et restaure les registres n�cessaires. L'utilisation d'un test sur une garde garantit que l'ensemble des aspects de la DLL sont tiss�s de mani�re atomique. La s�paration impos�e des espaces d'adressage par le syst�me d'exploitation emp�che un processus de modifier l'espace m�moire d'un processus tiers. La premi�re fois qu'Arachne tisse dans un processus, il acc�de � son espace m�moire en utilisant les fonctions de d�verminage \texttt{ptrace}, puis il cr�� un processus l�ger d'instrumentation partageant le m�me espace d'adressage que l'application. Arachne pilote ensuite ce processus l�ger d'instrumentation en utilisant une interface d'interconnexion : le tissage s'effectue ainsi globalement sans interruption de l'application. Arachne adresse les probl�mes d'efficacit� par des caches con�us pour n'examiner une fois au plus le code binaire de l'application.

architecture.tex
\section{Atelier de d�ploiement}\label{sec:arch}
\indent Traditionnellement dans les logiciels libres, lorsqu'une une faille de s�curit� est d�couverte, un correctif est propos� sous la forme d'une rustine source (patch) produite par l'utilitaire {\tt diff}. Cet outil permet de lister les diff�rences textuelles entre deux fichiers sources.\\
\indent Lorsque le RSSI prend connaissance d'une faille de s�curit� qui affecte son parc informatique, il v�rifie en examinant les sources du logiciel que le correctif ne remet pas en cause son int�grit�. Il doit alors recompiler, red�ployer le logiciel corrig� sur l'ensemble du parc puis r�-initialiser le logiciel et/ou la machine. \\
\indent Ce processus de mise � jour pr�sente plusieurs lacunes. En premier lieu, l'audit des rustines fournies par les �diteurs logiciels est difficile � r�aliser car les fichiers de diff�rences textuelles entre les versions d'un logiciel ne fournissent pas d'informations pertinentes et claires des modifications apport�es par la rustine. En second lieu, les failles de s�curit� sont toujours pr�sentes tant que le logiciel incrimin� n'a pas �t� stopp�. Or pour certaines applications comme les serveurs de vente en ligne, cette contrainte n'est pas acceptable. De plus, un RSSI ne peut prendre la responsabilit� d'arr�ter l'application d'un utilisateur sans savoir si ce dernier a pr�alablement sauvegard� son travail. En dernier lieu, le d�ploiement du logiciel corrig� doit se faire machine apr�s machine ce qui, sans outil adapt�, est une perte de temps importante et peut �tre compliqu� dans un environnement mobile. \\
\indent Notre atelier logiciel est destin� � faciliter la lecture des correctifs, � automatiser leurs d�ploiements et enfin � les appliquer dynamiquement sans arr�t des logiciels. Dans ce dessein, notre atelier est bas� sur deux outils : Minerve et Arachne. \\
\indent Le premier est charg� � la fois de valider le correctif dans le cadre d'une application dynamique et de transformer les rustines sources tr�s peu lisibles en fichiers de description des modifications pr�sentant au RSSI une vue synth�tique des modifications qui seront apport�es. Minerve permet de pr�senter au RSSI le corps des fonctions avant et apr�s modification en utilisant une symbolique pour d�signer les points de changement. Apr�s validation du RSSI en fonction des informations fournies par Minerve sur l'applicabilit� dynamique du correctif, le fichier est compil� en binaire sous forme d'une librairie, puis d�ploy� sur l'ensemble des machines concern�es par la mise � jour. \\
\indent Le second, pr�install� sur l'ensemble du parc, est alors charg� d'appliquer le correctif. Sa principale fonction consiste � s'ins�rer dynamiquement et sans l'arr�ter dans le logiciel incrimin�, puis de r�crire le code binaire du logiciel en vue de remplacer les fonctions impliqu�es dans la faille de s�curit� par leurs nouvelles versions contenues dans la DLL pr�c�demment diffus�e. \\
\indent Finalement, le correctif n'est appliqu� que pour la dur�e d'ex�cution du logiciel. En effet, en parall�le � cette op�ration, une mise � jour classique par application du patch sur les sources est effectu�e. Les prochaines ex�cutions du logiciel seront donc li�es � la nouvelle version \cite{2004:novadigm:hp}. Dans notre atelier, le travail de l'administrateur se limite � effectuer une veille sur les failles et correctifs diffus�s, valider les correctifs concern�s par les machines/logiciels qu'il administre et finalement indiquer � nos outils le sous ensemble des machines/logiciels � mettre � jour.


art.tex
\section{Travaux apparent�s}\label{sec:art}
\indent \`A notre connaissance, aucune autre solution ne propose \emph{� la fois} la v�rification de l'applicabilit� d'une mise � jour dynamique et son d�ploiement � chaud. La v�rification et la coh�rence des mises � jour ont essentiellement �t� �tudi�es sous l'angle de contraintes sur  l'�tat de l'ex�cution de l'application � mettre � jour \cite{1996:tse:gupta} ou sur la structure \cite{1993:segal:podus} de son code. Notre approche se concentre elle sur la structure de la rustine source traditionnellement distribu�e. Dyninst \cite{buck00api} et Vulcan \cite{edwards.srivastava.ea:vulcan}  explorent tout deux la possibilit� de r��crire le code binaire � chaud. Contrairement � notre approche, ces outils travaillent au niveau de l'assembleur et ne garantissent pas l'atomicit� de la r��criture. C'est un probl�me quand la mise � jour implique d'instrumenter le programme  � plusieurs endroits.


dcor.tex
%	POUR COMPILER
%	latex dcor.ltx && bibtex dcor && latex dcor.ltx && latex dcor.ltx


%\documentclass[10pt,twoside,openright,a4paper]{report}
% Documentation du style Latex pour les articles de revues ou de conf�rences Hermes
% Les consignes aux auteurs sont en annexe de ce document.

\documentclass[french,a4paper]{article-hermes}
%%% Commandes spcifiques  l'article
\newcommand{\cfsect}[1]{(\textit{cf.} section~\ref{#1})}
\newcommand{\cfsectpage}[1]{(\textit{cf.} section~\ref{#1}, page~\pageref{#1})}
\providecommand{\figureref}[1]{\figname~\ref{#1}}
\providecommand{\cftab}[1]{(\textit{cf.} tableau~\ref{#1})}
\newcommand{\cmd}[1]{{\upshape\texttt{\symbol{"5C}#1}}}

\usepackage{url}
\usepackage{lgrind}


\hyphenation{Ara-chne Mi-ner-ve}

\newcommand{\Nom}{ Minerve }

\begin{document}

%\maketitle % Exemple de 1ere page sans les valeurs de champs
            % pour afficher les commandes  utiliser

%\journal[Mode d'emploi]{Signature de l'article~: nom de la revue}%
%   {10}{5}{1999}{1}{15}% Exemple avec numros de page


%\journal{DECOR}{}{}{2004}{1}{2}
\proceedings{DECOR'2004, D�ploiement et (Re)Configuration de Logiciels}{65}
\title[Des correctifs de s�curit� � la mise � jour%
 ]%
      {%
Des correctifs de s�curit� � la mise � jour 
}

\subtitle{%
Audit, d�ploiement distribu� et injection � chaud}
\author{Nicolas Loriant - Marc S�gura-Devillechaise - Jean-Marc Menaud }

\address{%
\'Ecole des Mines de Nantes, projet Obasco EMN/INRIA, \\
\{nloriant,msegura,jmenaud\}@emn.fr \hfill \url{http://www.emn.fr/x-info/arachne}}

\resume{La complexit� toujours croissante des logiciels implique un accroissement des bogues. Ces derniers restent le 
 vecteur principal d'attaque des pirates informatiques et imposent aux �diteurs logiciels d'�mettre r�guli�rement des mises � jour pour leurs corrections. Cependant, peu d'utilisateurs sont pr�ts � arr�ter leurs applications et � investir le temps n�cessaire pour mettre  � jour leur poste de travail. Dans les faits, les correctifs sont rarement d�ploy�s, m�me quand ceux-ci sont critiques. \\
Nous proposons un atelier de d�ploiement permettant � un administrateur syst�me d'appliquer � chaud, � distance et sans l'intervention des utilisateurs, des rustines de s�curit�. Pour �viter l'arr�t des logiciels concern�s, notre approche est bas�e sur un tisseur dynamique d'aspects, Arachne. Notre second outil, Minerve, s'int�gre dans le processus de mise � jour standard : il prend en entr�e une rustine source produite par \texttt{diff} et g�n�re, quand cela est possible, une rustine dynamique d�ployable � la vol�e. Il permet de consulter les rustines exprim�es dans un langage d�di� et facilite ainsi la t�che d'audit des mises � jour d�ploy�es.}

\abstract{The ever growing software complexity suggests that they will never be bugfree and therefore secure. Software compagnies regulary publish updates. But maybe because of lack of time or care or maybe because stopping application is annoying, such updates are rarely if ever deployed on users' machines. \\
We propose an integrated tool allowing system administrators to deploy critical security updates on the fly on applications running remotly without end-user intervention. Our approach is based on an aspect weaving system, Arachne, that dynamicaly rewrites binary code. Hence updated applications are still running while they are updated. Our second tool Minerve integrates Arachne within the standart updating process: Minerve takes a patch produced by \texttt{diff} and eventually builds a dynamic patch that can later be woven to update the application on the fly. In addition, Minerve allows to consult patches translated in a dedicated language and hence eases auditing tasks.}



\motscles{mise � jour de programme � chaud, programmation par aspect, d�ploiement distribu�, s�curit�}

\keywords{hot software update, aspect-oriented programming, distributed deployment, security}

\maketitlepage

\input{introduction}
\input{architecture}
\input{theorie}
\input{arachne.tex}
\input{evaluation}
\input{art}
\section{Conclusion}\label{sec:con}
\indent Nous avons pr�sent� dans cet article un atelier pour le d�ploiement � chaud de correctifs de s�curit�. Cet atelier est compos� de deux outils. Le premier, Minerve, assure la faisabilit� d'un d�ploiement � chaud et r�duit le temps n�cessaire � la certification par le RSSI d'un correctif. Le second, Arachne, applique � chaud sur un programme en cours d'ex�cution, la rustine dynamique produite par Minerve. Notre atelier s'ins�re dans le processus traditionnel de mise � jour des logiciels libres bas� sur les utilitaires \texttt{diff} et \texttt{patch}. L'utilisation de notre atelier permet un gain de temps significatif dans le d�ploiement et apporte donc une plus grande r�activit� quant � la correction des failles. \\
\indent Concr�tement, Minerve, transforme un correctif peu lisible en un fichier d�crivant les modifications � apporter au logiciel. Ces modifications sont exprim�es sous forme d'un aspect dont les coupes se limitent au remplacement de fonctions et/ou � l'acc�s � une variable. En ce sens nous n'utilisons pas l'ensemble du pouvoir d'expression de la programmation par aspect. Le second, Arachne, injecte dynamiquement l'aspect compil� dans l'application  � mettre � jour. Pour des raisons techniques, nous nous sommes pour l'instant limit�s aux programmes �crits en C s'ex�cutant sur une plate-forme IA32 dans un environnement Linux. L'atelier Minerve/Arachne a permis de d�ployer l'ensemble des correctifs de s�curit� publi�s par le CERT/CC sur les logiciels libres depuis 2002.



\bibliography{dcor}

%\section{Annexe}\label{sec:anne}

\end{document}

evaluation.tex
\section{\'Evaluation}\label{sec:eval}

\indent Cette section pr�sente une �valuation de notre atelier compos� de Minerve et Arachne. Pour cela, nous avons appliqu� notre m�thodologie aux mises � jour de s�curit� concernant des logiciels libres, publi�es depuis le d�but de l'ann�e 2002 par le CERT/CC. Apr�s un pr�sentation de l'organisme et de l'�chantillon d'�tude, nous pr�sentons nos r�sultats sur l'ensemble de l'�chantillon puis d�crirons un exemple concret de rustine dynamique.

\subsection{\'Echantillon d'�tude}

\indent Le CERT/CC pour \og Computer Emergency Response Team / Coordination Center\fg \- est un centre d'expertise cr�� en novembre 1988, suite � l'apparition du ver \emph{Morris}. Par ses activit�s de veille, de diffusion, d'alerte et de formation, il cherche � am�liorer la s�curit� des syst�mes informatiques. Sa long�vit�, son ind�pendance vis-�-vis des �diteurs de logiciels ainsi que son r�le pr�ventif et curatif font de lui un acteur de r�f�rence mondiale du domaine. Depuis 1988, il a ainsi collect� une des bases de donn�es les plus compl�te en mati�re de failles de s�curit�. 
Toutes les failles relev�es par le CERT/CC sont class�es suivant trois cat�gories. La premi�re, les alertes recensent les attaques perp�tr�es contre des syst�mes informatiques. La seconde, les rapports de vuln�rabilit� listent les failles dans les applications. Enfin la derni�re cat�gorie, les avis r�f�rencent un ou plusieurs rapports de vuln�rabilit�. Les avis se limitent aux failles de s�curit� critiques sur des logiciels largement r�pandus et fournissent syst�matiquement les correctifs associ�s. \\
%\subsubsection{Donn�es collect�es}
\indent Notre �tude s'est donc port�e sur l'ensemble des avis publi�s par le CERT/CC depuis le d�but de l'ann�e 2002 jusqu'� aujourd'hui. Cette p�riode repr�sente un total de 67 avis, 30\% concernent des produits Microsoft, 20\% des logiciels propri�taires autres que Microsoft, 40\% r�f�rencent des failles dans des logiciels libres et les 10\% restants concernent de l'informatique embarqu�e dans des mat�riels r�seau. 14 avis concernent des logiciels libres sous Linux. Nous en avons �cart� deux parce qu'ils affectaient des versions obsol�tes introuvables. \\
\indent Nous avons constat� que \nombre{44\%} des failles examin�es sont des d�bordements de tampon : Ce type de dysfonctionnement peut permettre � un utilisateur malveillant de faire ex�cuter du code arbitraire par le processus vis�. \nombre{19\%} pr�sentaient des erreurs de format : ces erreurs affectent les fonctions � nombre de param�tres  variables (ex : {\tt printf}). Un utilisateur malveillant peut exploiter cette faille pour obtenir des informations sur le processus vis�. \nombre{12\%} des cas recensent des doubles d�sallocations m�moire. Cette faille provoque normalement une erreur de segmentation mais peut sous certaines conditions permettre l'ex�cution de code arbitraire. \nombre{6\% } des avis examin�s pr�sentent un d�bordement d'entier : Ceci se produit lorsque la valeur d'un entier d�passe la limite du type. Enfin, \nombre{19\% } des trous de s�curit� r�sultent de combinaisons des erreurs de conceptions cit�es ci-dessus. \\
\indent Toutes ces failles se basent sur des hypoth�ses faites par le programmeur sur les param�tres du programme mis en d�faut par un utilisateur malveillant. Ainsi, ces failles peuvent se corriger tr�s simplement : il suffit d'ajouter des tests sur les valeurs des param�tres. L'examen des rustines correctives de ces trous de s�curit� nous a permis de d�gager le contenu des modifications apport�es � un programme pour corriger une faille. Nous avons pu constater la corr�lation avec le type des dysfonctionnements recens�s, puisque \nombre{90\%} des correctifs source ne contenaient que des modifications de fonctions sans changement de signatures. Seulement \nombre{10\%} contenait � la fois des modifications de code et des transformations de types. \\
\indent Ce constat ainsi que les exp�rimentations que nous avons r�alis�es, nous permettent d'affirmer que notre atelier est applicable � tous les trous de s�curit� �tudi�s. \\

\subsection{Un exemple de mise � jour}
\indent Nous pr�sentons dans cette section une des failles que nous avons pu corriger automatiquement gr�ce � Minerve. Il s'agit d'une vuln�rabilit� d�couverte en juin 2002 et qui concerne le serveur de communication \textsc{OpenSSH} (avis num�ro 18/2002 du CERT/CC) \cite{2003:cert:overview}. 
Cette faille concerne le m�canisme d'authentification du protocole SSH2 : {\tt challenge response}. Elle affecte les versions de {\tt 2.3.1p1} � {\tt 3.3} configur�es avec les options {\tt SKEY} ou {\tt BSD\_AUTH}. C'est le cas pour l'installation par d�faut dans la plupart des distributions Linux. Cette faille consiste en un d�bordement d'entier exploitable par des utilisateurs malveillants afin d'ex�cuter du code arbitraire par le programme r�sidant {\tt sshd}, ex�cut� g�n�ralement avec les droits super-utilisateur.

\subsubsection{Rustine source}
\indent La rustine source fournie par les d�veloppeurs de \textsc{OpenSSH} corrige les fonctions {\tt input\_\-userauth\_\-info\_\-response} et {\tt input\_\-userauth\_\-info\_\-response\_\-pam}. Les modifications se bornent � ajouter des tests de validit� sur le param�tre {\tt nresp} dans ces deux fonctions. Lorsque ces tests de validit� �chouent, la fonction {\tt fatal} est d�clench�e pour terminer la session en cours. Comme le montre la figure \ref{fig:patch}, l'examen de la rustine produite par \texttt{diff} ne permet pas de comprendre facilement les changements effectu�s par le correctif.\\
\lagrind[ht]{patchSource.tex}{Une partie du fichier de diff�rences {\tt diff} de la mise � jour de s�curit� de {\tt sshd} r�f�renc�e par le CERT/CC par {\tt CA-2002-18}}{fig:patch}

\subsubsection{Rustine dynamique}
\indent Minerve produit � partir de la rustine source une rustine dynamique. La rustine dynamique contient essentiellement une suite d'aspects qui r�alisent le remplacement des fonctions du programme de base,  {\tt input\_\-userauth\_\-info\_\-response} et {\tt input\_\-userauth\_\-info\_\-response\_\-pam}. Les fonctions corrig�es poss�dent le suffixe {\tt "\_new"}. Finalement, les anciennes fonctions pouvant �tre appel�es dans {\tt sshd} indiff�remment par un appel direct de fonction ou par un appel par pointeur, deux aspects sont n�cessaires pour chacune de ces fonctions afin de r�aliser leur remplacement � coup s�r. La figure \ref{code:arachne} illustre ces aspects pour la fonction {\tt input\_\-userauth\_\-info\_\-response}. \\
\indent La coupe de l'aspect {\tt ReplaceFunctionCall} capture l'ensemble des appels directs � cette fonction (ligne 2 du source figure \ref{code:arachne}). L'action remplace son ex�cution par celle de la nouvelle version � laquelle les m�me arguments sont fournis (ligne 3). Cet aspect permet ainsi de remplacer tous les appels directs � {\tt input\_\-userauth\_\-info\_\-response}. La coupe du second aspect {\tt ReplacePointer} capture les acc�s en lecture sur l'adresse de la fonction {\tt input\_\-userauth\_\-info\_\-response} (ligne 6). C'est cette valeur qui peut �tre ensuite utilis�e dans un appel de fonction par pointeur. La valeur lue est remplac�e dans l'action de l'aspect (ligne 7) par l'adresse de la nouvelle version de la fonction d�finie dans la rustine dynamique. Ainsi toutes les lectures de l'adresse de l'ancienne fonction seront remplac�es par une lecture de l'adresse de la nouvelle fonction. 


\lagrind[ht]{patch.tex}{Aspects g�n�r�s par Minerve pour le remplacement syst�matique d'une fonction}{code:arachne}

\indent Comme le montre la figure \ref{code:arachne}, la syntaxe des rustines produites par Minerve facilite r�ellement le travail d'audit des correctifs. Sur l'ensemble des correctifs publi�s par le CERT/CC en 2002, le gain de temps est r�ellement sensible. Si on exclut les temps r�seau, dans nos exp�riences, une mise � jour est d�ploy�e en moyenne sur un poste en 253 $\mu s$ sans m�me que l'utilisateur en ait conscience. De plus avec notre atelier, le RSSI ne g�re pas la mise � jour d'un poste mais de la totalit� du parc. Le temps pour appliquer un correctif est ind�pendant du nombre de machines composant le parc.



introduction.tex
\section{Introduction}

\indent Pour l'ann�e 2003, 80\% des attaques informatiques subies par les entreprises sont li�es � un manquement dans le d�ploiement des correctifs de s�curit�s\cite{2004:devoteam:enquete}. En effet, la plupart des attaques informatiques exploitent des failles de s�curit� r�pertori�es. Dans le cas de la derni�re attaque m�diatis�e, le virus Sasser, une rustine corrigeant la vuln�rabilit� exploit�e �tait disponible quinze jours avant la propagation du virus. De ce fait, une grande partie des attaques informatiques subies pourraient �tre �vit�es en menant de front � la fois, une veille attentive sur les failles de s�curit� d�tect�s par les organismes sp�cialis�s, et par une application rapide des correctifs sur l'ensemble des machines concern�es. Cette double mission est g�n�ralement octroy�e � un administrateur syst�me promu au rang de RSSI (Responsable de la S�curit� du Syst�me Informatique). En l'absence d'outils ad�quats, le RSSI est toutefois d�nu� de moyens pour lutter efficacement contre les d'attaques potentielles. En effet, la simple mission de veille lui demandera un peu plus de 13 semaines de travail � raison de cinq minutes pour chacune des 5500 alertes annuelles recens�es\cite{2003:cert:overview}. En supposant qu'il ait la charge d'administrer 100 machines, qu'elles ne soient concern�es que par 1\% des  alertes et que l'application d'un  correctif demande une heure de travail, le temps n�cessaire � leur d�ploiement s'�l�vera au total � plus de 157 semaines de travail par an.\\
\indent Nous proposons dans cet article une approche semi-automatique pour le d�ploiement des correctifs de s�curit�s. Le but de cette approche est de r�duire significativement le temps n�cessaire au d�ploiement des correctifs. Le principal probl�me n'est pas tant l'application du correctif en lui m�me mais d'obtenir de l'utilisateur l'acc�s aux machines n�cessaires et l'arr�t des applications � mettre � jour (prise de contact, sauvegarde de la session et des documents etc..). 
Notre approche est  bas�e sur deux outils, Minerve et Arachne. Le premier r�duit le temps de certification des correctifs par le RSSI. Le second permet le d�ploiement des correctifs sans avoir � arr�ter l'application � mettre � jour. La mise � jour � chaud �vite au RSSI d'obtenir l'accord de l'utilisateur pour appliquer un correctif et r�duit ainsi significativement leur temps de d�ploiement. La section \ref{sec:arch} pr�sente une vue d'ensemble de notre atelier de d�ploiement et son int�gration dans le processus traditionnel de mise � jour des logiciels libres. Les sections \ref{sec:etude} et \ref{sec:ara} pr�sentent respectivement nos outils : Minerve et Arachne. La section \ref{sec:eval} d�crit une �valuation de l'atelier appliqu� aux derniers trous de s�curit�. Avant de conclure, la section \ref{sec:art} r�sume quelques  principaux travaux connexes.\\
patch.tex
% Remember to use the lgrind style

\Head{}
\File{patch.ac}{2004}{6}{15}{16:29}{321}
\L{\LB{\N{1}:}\Tab{3}{\V{ReplaceFunctionCall}_[:}}
\index{input\_userauth\_info\_response}\Proc{input\_userauth\_info\_response}\L{\LB{\N{2}:}\Tab{6}{\K{void}_\V{input\_userauth\_info\_response}(\K{int}_\V{type},_\V{u\_int32\_t}_\V{seq},_\K{void}*_\V{ctxt})_[:_\{}}
\L{\LB{\N{3}:}\Tab{9}{\V{input\_userauth\_info\_response\_new}(\V{type},_\V{seq},_\V{ctxt});}\Tab{60}{\}_:]_:]}}
\L{\LB{\N{4}:}}
\L{\LB{\N{5}:}\Tab{3}{\V{ReplacePointer}_[:}}
\L{\LB{\N{6}:}\Tab{6}{\K{void}*_(\V{input\_userauth\_info\_response})(\K{int},_\V{u\_int32\_t},_\K{void}*)_[:_\{}}
\L{\LB{\N{7}:}\Tab{12}{\K{return}_\&\V{input\_userauth\_info\_response\_new};}\Tab{54}{\}_:]_:]}}

patchSource.tex
% Remember to use the lgrind style

\Head{}
\File{patchSource.diff}{2004}{6}{16}{10:17}{249}
\L{\LB{_}\Tab{3}{\V{authctxt}\-\!\>\V{postponed}_=_\N{0};}\Tab{30}{\C{}/*_reset_*/\CE{}}}
\L{\LB{_}\Tab{3}{\V{nresp}_=_\V{packet\_get\_int}();}}
\index{if}\Proc{if}\L{\LB{+}\Tab{3}{\K{if}_(\V{nresp}_\>_\N{100})}}
\L{\LB{+}\Tab{6}{\V{fatal}(\S{}\3input\_userauth\_info\_response:_nresp_too_big_\%u\3\SE{},_\V{nresp});}}
\L{\LB{_}\Tab{3}{\K{if}_(\V{nresp}_\>_\N{0})_\{}}
\L{\LB{_}\Tab{6}{\V{response}_=_\V{xmalloc}(\V{nresp}_*_\K{sizeof}(\K{char}*));}}
\L{\LB{_}\Tab{6}{\K{for}_(\V{i}_=_\N{0};_\V{i}_\<_\V{nresp};_\V{i}++)}}

theorie.tex
\section{Minerve : v�rification de l'applicabilit� dynamique des correctifs}\label{sec:etude}

\indent Les rustines sources fournies par les �diteurs logiciels sont g�n�r�es et d�ploy�es � partir des programmes {\tt diff} et {\tt patch}. Ces outils manipulent uniquement des diff�rences textuelles entre fichiers sources sans exploiter des informations s�mantiques sur les modifications apport�es. Si cette approche permet de valider l'application d'un correctif dans un cadre statique (ou off line), elle n'est pas suffisante dans un cadre dynamique (ou on line). Minerve est charg� de classifier les changements effectu�s dans le code de l'applicatif puis d'informer le RSSI de l'applicabilit� dynamique de ceux-ci (section 3.1). Enfin, un fichier des modifications plus expressif qu'un simple {\tt diff} est produit pour faire appel � l'audit du RSSI (section 3.2). \\

\indent En vue de d�montrer la faisabilit� de notre approche nous nous sommes limit� � ne consid�rer que les programmes �crits en langage C ANSI et compil� sur les plateformes IA-32 dans un environnement Linux. Nous supposons �galement que les rustines sources fournies par les �diteurs sont coh�rentes (i.e. que les sources corrig�es passent la phase de compilation et fournissent un programme valide).

\subsection{Classification et V�rification}
\indent Le premier objectif de l'outil est de classifier les modifications � effectuer sur un programme cible �crit en C.
Le langage C est un langage proc�dural typ� � effet de bord. Il contient deux sortes de types, les types simples qui refl�tent les entit�s que le processeur peut manipuler efficacement, et les types structur�s, construits par le d�veloppeur par agr�gation de types simples. Une rustine source modifie le comportement d'un programme en modifiant la d�finition des proc�dures qu'il contient, et/ou en modifiant les types associ�s aux variables qu'il utilise. Si d'un point de vue statique les deux types  de modifications peuvent �tre trait�es sym�triquement, d'un point de vue dynamique, chacun des cas doit �tre trait� diff�remment. 

\subsubsection{Modification de fonctions}\label{sec:remp_fct}

\indent Nous distinguons trois types de correctifs li�s aux fonctions : l'ajout, la suppression et la modification. En r�alit� ces trois types de correctifs peuvent se r�sumer en un seul : la modification d'une fonction. 
En effet, l'ajout d'une fonction $g$ dans un programme implique qu'il existe au moins une fonction $f$ qui a �t� modifi�e de sorte qu'elle utilise $g$. Dans le cas contraire l'ajout de $g$ n'aurait aucun sens. De m�me, la suppression d'une fonction $g$ n�cessite qu'au moins une fonction $f$ soit modifi�e. Dans le cas contraire, une erreur � la compilation du programme corrig� serait g�n�r�e. Or, nous avons pr�cis� que les rustines consid�r�es �taient coh�rentes. Nous nous limitons donc aux cas de la modification d'une fonction $ f $ et parlerons de $ f'$ pour d�signer la nouvelle version de $ f$ (donc apr�s application de la rustine). \\
\indent La modification d'une fonction peut entra�ner le changement de sa signature et/ou le changement de son corps. Le changement de la signature d'une fonction est �quivalent � l'ajout d'une nouvelle fonction. Pour le deuxi�me cas, le remplacement de $ f $ par $ f'$ sans modification de prototype, il est n�cessaire de s'assurer que $f$ n'est et ne sera jamais plus ex�cut�e \cite{1993:segal:podus,1998:gupta:osvc}. Cette premi�re condition ne peut �tre v�rifi�e que dynamiquement par inspection de la pile d'ex�cution. Pour cela, nous nous appuyons sur l'outil Arachne pr�sent� en section \ref{sec:ara}. De plus, le code ajout� (si il y a lieu) dans  $ f$ ne doit pas lire les donn�es produites par $f$. Pour cela nous pensons utiliser un outil de propagation de type nomm� Lackwit \cite{1997:lackwit:callahan}.



\subsubsection{Modification d'une variable}
\indent Nous distinguons deux types de modifications, celles li�es au changement de type de base, et celles li�es � la modification des types structur�s.
\begin{itemize}
\item La red�finition du type d'une variable n�cessite deux op�rations : la propagation de l'�tat de la variable et les modifications � apporter au code qui la manipule. Augmenter la taille d'une variable sans modifier son type num�rique (ex: {\it int}$\rightarrow$ {\it long int}) ne pose pas de probl�me de conversion, puisque le nouveau type englobe l'ancien. Au contraire, la diminution de la taille d'une variable (ex: {\it long int}$\rightarrow$ {\it int}) ou la modification du type num�rique de celle-ci (ex: {\it float}$\rightarrow$ {\it int}) n'est possible que si sa valeur courante peut-�tre contenue par le nouveau type ou si l'on dispose d'une fonction de conversion. Modifier la taille ou le type num�rique d'une variable n�cessite de modifier �galement le code binaire manipulant celle-ci. En effet, les instructions processeur, les registres, les drapeaux ainsi que les exceptions associ�es � des types diff�rents sont distincts. La modification d'une instruction peut n�cessiter de r�organiser les instructions voisines. Cette r�organisation peut s'�tendre au remplacement complet de la fonction acc�dant � la variable dont le type a �t� modifi�. Les registres globaux �tant de la responsabilit� des fonctions appelantes et les autres registres des fonctions appel�es %\cite{1994:pht:abi:supp}
, la modification du type num�rique d'une variable peut alors �galement n�cessiter la modification des fonctions appelant les fonctions qui acc�dent aux variables modifi�es. Ce cas n'est n�anmoins pas un probl�me puisqu'il est r�solu par la technique d'instrumentation d'Arachne.
\item Modification de la d�finition d'un type structur� : nous avons choisi de pr�senter l'ajout d'un champ dans un type structur� puisqu'il illustre bien les probl�mes li�s � ce type de modifications (suppression, remplacement, inversion). La modification d'un type structur� peut modifier la contrainte d'alignement sur la repr�sentation m�moire des instances de ce type. %\cite{1994:pht:abi:supp}. 
Certaines instructions de la plate-forme IA-32 peuvent avoir des comportement diff�rents, voir ne pas fonctionner lorsque les donn�es qu'elles manipulent ne sont pas align�es %2001:intel:instruction
. Modifier toutes les variables existantes du type modifi� imposerait alors �galement de mettre � jour l'ensemble des instructions manipulant ce type dans le programme d'origine. Or, la coh�rence de la mise � jour ne pourrait alors �tre garantie qu'en stoppant le programme. Toutefois, une technique de r��criture appropri�e permet de r�soudre ce probl�me. En effet, un champ ajout� dans un type structur� lors d'une mise � jour n'existe pas dans le programme de base, seules les instructions ajout�es peuvent manipuler celui-ci. Il est ainsi possible de modifier ces derni�res de fa�on � associer via une fonction de hachage, � chaque variable du type d'origine une variable repr�sentant le nouveau champ. La cr�ation du nouveau champ peut se faire de mani�re paresseuse pour chaque variable. Ceci nous permet d'�viter la modification de toutes les variables de ce type lors de la mise � jour.
\end{itemize}
\indent Sachant que le RSSI est plac� au centre de notre architecture, l'ensemble des informations de v�rifications effectu�es par Minerve ne lui sont pr�sent�es qu'� titre indicatif. Libre � lui de valider ou non la rustine dynamique. Pour l'aider dans cette t�che Minerve produit un fichier concentrant l'ensemble des modifications � apporter au logiciel incrimin� dans un format lisible et compatible avec notre outil de transformation de code � chaud. La section suivante d�crit le processus d'inspection de la rustine.
\subsection{L'audit du RSSI}\label{sec.arachne.audit}
\indent L'inspection du code de la rustine r�pond � deux buts. D'abord elle permet de s'assurer que la faille de s�curit� recens�e est v�ritablement corrig�e. Puis, elle veille � ce que de nouveaux trous de s�curit� ne soit pas introduits par erreur. Il peut �galement �tre utile d'adapter un correctif de s�curit� au syst�me local d'information. Par exemple, diff�rents experts en s�curit� pr�conisent que la correction d'une vuln�rabilit� s'accompagne de la mise en place d'une alarme signalant toute tentative d'exploitation de la vuln�rabilit� colmat�e \cite{Sch00}. Une fois la rustine traduite par  \Nom dans le langage d'Arachne, le RSSI peut facilement l'�diter au cours de l'audit afin d'y placer une alarme qui va par exemple, d�clencher le syst�me de d�tection d'intrusion (IDS). \\
\indent Au contraire de \texttt{diff} et \texttt{patch} qui fonctionnent par substitution de lignes, \Nom utilise Arachne pour remplacer des fonctions aux comportements erron�s par de nouvelles fonctions et red�finir les acc�s fautifs aux variables globales. Une fois la rustine traduite par Minerve dans le langage d'Arachne, la rustine contient l'ensemble des entit�s (variables globales et fonctions) � red�finir. Chaque rustine de s�curit� est ainsi trait�e comme une pr�occupation � part, inspectable et �ditable isol�ment des autres. De plus, le format de fichier est directement compatible avec Arachne \cite{ segura-menaud-al.cfse2003}, un tisseur dynamique d'aspect pour le langage C. \\
\indent Avec Arachne, chaque substitution ou \emph{aspect} est d�finie par un couple (coupe, action). Une coupe sp�cifie quand dans le flot d'ex�cution du programme, le code d�crit dans l'action doit s'ex�cuter. Une coupe est une s�quence d'appels de fonctions �ventuellement termin�e par un acc�s en lecture ou en �criture � une variable globale. Tous les �l�ments, sauf le dernier de la s�quence, d�terminent le contexte d'ex�cution de la coupe. Dans ce cadre d'�tude, nous utilisons Arachne comme un outil d'instrumentation � chaud nous permettant d'intercepter tout acc�s � une fonction ou � une variable particuli�re. De ce fait, les abstractions langage de haut niveau propre � la programmation par aspect et fournies par Arachne ne seront pas utilis�es dans notre solution. 

dcor.bbl
\begin{thebibliography}{}

\bibitem[BUC~00]{buck00api}
\textsc{Buck B.}\andname{}\textsc{Hollingsworth J.~K.}, \guilo{}An {API} for
  Runtime Code Patching\guilf{},
\newblock \textit{The International Journal of High Performance Computing
  Applications}, \volumename\ 14, \numbername\ 4, 2000,  \pagesname{} 317--329.

\bibitem[CER~03]{2003:cert:overview}
\textsc{CERT}, \guilo{}Computer Emergency Response Team Coordination
  Center\guilf{},
\newblock \technicalreportname{}, 2003, Carnegie Mellon University.

\bibitem[DEV~04]{2004:devoteam:enquete}
\textsc{Devoteam}, \guilo{}Enqu\^ete Europ\'eene sur la S\'ecurit\'e des
  Syst\`emes d'Information\guilf{},
\newblock \technicalreportname{}, 2004, XP Conseil.

\bibitem[EDW~01]{edwards.srivastava.ea:vulcan}
\textsc{Edwards A.}, \textsc{Srivastava A.}\andname{}\textsc{Vo H.},
  \guilo{}Vulcan\guilf{},
\newblock \technicalreportname{} \numbername MSR-TR-99-76, \Jan{} 2001,
  Microsoft Research (MSR).

\bibitem[GUP~96]{1996:tse:gupta}
\textsc{Gupta D.}, \textsc{Jalote P.}\andname{}\textsc{Barua G.}, \guilo{}A
  Formal Framework for On-line Software Version Change\guilf{},
\newblock \textit{IEEE Transactions on Software Engineering}, \volumename\ 22,
  \numbername\ 2, 1996,  \pagesname{} 120--131.

\bibitem[GUP~98]{1998:gupta:osvc}
\textsc{Gupta D.}, \textsc{Barua G.}\andname{}\textsc{Jalote P.}, \guilo{}A
  Formal Framework for On-line Software Version Change\guilf{},
\newblock , 1998.

\bibitem[HP~04]{2004:novadigm:hp}
\textsc{HP}, \guilo{}\textsc{Novadigm}: Software management, automated change
  management\guilf{},
\newblock \technicalreportname{}, 2004, Hewlett-Packard.

\bibitem[O'C~97]{1997:lackwit:callahan}
\textsc{O'Callahan R.}\andname{}\textsc{Jackson D.}, \guilo{}Lackwit: {A}
  Program Understanding Tool Based on Type Inference\guilf{},
\newblock \Inname{} \textit{Proceedings of the 1997 International Conference on
  Software Engineering}, ACM Press, 1997,  \pagesname{} 338--348.

\bibitem[SCH~00]{Sch00}
\textsc{Schneier B.}, \textit{Secrets and Lies : Digital Security in a
  Networked World},
\newblock Wiley, \Aug{} 2000.

\bibitem[SEG~93]{1993:segal:podus}
\textsc{Segal M.~E.}\andname{}\textsc{Frieder O.}, \guilo{}On-the-Fly Program
  Modification: Systems for Dynamic Updating\guilf{},
\newblock \textit{{IEEE} Software}, \volumename\ 10, \numbername\ 2, 1993.

\bibitem[SEG~03a]{segura-menaud-al.cfse2003}
\textsc{Segura-Devillechaise M.}, \textsc{Menaud J.-M.}, \textsc{Lawall
  J.}\andname{}\textsc{Muller G.}, \guilo{}Extensibilit\'ee Dynamique dans les
  Caches Web : une Approche par Aspects\guilf{},
\newblock \Inname{} \textit{3\`eme Conf\'erence Fran\c{c}aise sur les
  Syst\`emes d'Exploitation ({CFSE'03})}, La Colle sur Loup, \Oct{} 2003.

\bibitem[SEG~03b]{segura-menaud-al.aosd2003}
\textsc{Segura-Devillechaise M.}, \textsc{Menaud J.-M.}, \textsc{Muller
  G.}\andname{}\textsc{Lawall J.}, \guilo{}Web Cache Prefetching as an aspect:
  Towards a Dynamic-Weaving Based Solution\guilf{},
\newblock \Inname{} \textit{Proceedings of the 2nd international conference on
  Aspect-oriented software development}, Boston, Massachusetts, USA, \Mar{}
  2003, ACM Press,  \pagesname{} 110--119.

\end{thebibliography}
