1 / 14

Software security patches Audit, deployment and hot update

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

alyssa
Download Presentation

Software security patches Audit, deployment and hot update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Nicolas Loriant, Marc Ségura-Devillechaise, Jean-Marc Menaud, Obasco GroupEMN/INRIA Software security patchesAudit, deployment and hot update Workshop on Aspects, Components, and Patterns for Infrastructure Software

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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 );

  7. 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?

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

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

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

  11. 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.

  12. 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

  13. 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

  14. 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?

More Related