Software security patches Audit, deployment and hot update Nicolas Loriant, Marc Ségura-Devillechaise, Jean-Marc Menaud, Obasco Group EMN/INRIA Workshop on Aspects, Components, and Patterns for Infrastructure Software

Trends 80% of computer attacks are exploiting published security vulnerabilities The Sasser example: –the patch correcting the security hole was available two weeks before Sasser diffusion

The problem Reading CERT/CC bulletins: –5500 security alerts per year –asume 5 minutes per bulletin –Total: 13 weeks of work Solution: system administrator Work for one system administrator –Hypothesis 100 machines only 1% of the reported vulnerabilities are relevant 1 hour to update one computer –Total: 157 weeks per year

Our goals an integrated framework allowing system administrators to deploy critical security updates –update applications on the fly –integrates well with the standard updating process –without the intervention of the end-user. –eases auditing tasks Two tools : Minerve & Arachne

Minerve Input –the old application source code –a patch produced by the standard tool: diff patch = summary of textual differences between 2 versions of the source code Translating a patch into aspects

An example + if ( nresp > 100) + fatal (" input_userauth_info_response : nresp too big %u", nresp ); call ( void input_userauth_info_response (int, u_int32_t, void *)) && args ( type, seq, ctxt ) then input_userauth_info_response_new (type, seq, ctxt );

Minerve additional features Perform as much checks as possible to ensure that the patch once translated can be deployed on the fly –once woven, aspects will change the version of the application –can the state of the (old) application at weaving time be understood by the new version of the application?

State problems update program function alterations of code structure addreplacesuppress data’s type definition simple type type change scope change complex type defnition. add new field remove field change a type field Coherency at the source code level Coherency at the application level Is the application still making the same thing? ex : s = s + 1 -> s = s - 1

Arachne A dynamic weaver for legacy C applications –without source and binary preparation –without service interruption –with good performance

Framework architecture source version 1.0 Minerve diff 1.0 -> 1.1 aspect 1.0 -> 1.1 Process version 1.0 aspect 1.0 -> Arachne Process version 1.0 aspect 1.0 -> Arachne

Evaluation Patches samples: –security advisory published by the CERT for open source C programs since 2002 Conclusions –successfull translation of the different patches into aspects –successfull deployed (weaving) of the produced aspects –excluding network transfer time, our system updates an application in less than 250µs.

Future works: Minerve checks Current limitations: –no check to determine whether the functions to be replaced will not be running at weaving/deployment time –restricted checks regarding data structure alterations Ideas to solve these issues –analyze the data produced and consumed for each replaced functions –temporarily runs the execution of the old function and its new version implies that an application can not make side effect on another application –application = client + server

Conclusion A framework for dynamic patching –Minerve translates patches into aspects that can be deployed on the fly –Minerve tries to ensure that the application will remain coherent after weaving the aspects –Arachne weaves patches dynamically Main advantage: easy integration –support standard patches published by software developers Applied successfully on the CERT security advisories patches

Discussion Today we know how to design dynamic weaving systems Dynamic weaving systems offer real benefits –see security patches Today dynamic weavers offer little help for state issues In this context, could naive programmers and/or automated tools use them properly? –i.e. how can we help them to cope with state problems?