Скачать презентацию Software security patches Audit deployment and hot update Скачать презентацию Software security patches Audit deployment and hot update

940c942ca09da78f039f80f9ebb4eb07.ppt

  • Количество слайдов: 14

Software security patches Audit, deployment and hot update Nicolas Loriant, Marc Ségura-Devillechaise, Jean-Marc Menaud, 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 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 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 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 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 ( An example + if ( nresp > 100) + fatal (" input_userauth_info_response : nresp too big %u", nresp ); call ( void input_userauth_info_response (int , u_int 32_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 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 Coherency at the source code level update program data’s type definition alterations State problems Coherency at the source code level update program data’s type definition alterations of code structure function add simple type suppress replace complex type defnition. add new field type 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

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

Framework architecture Process version 1. 0 diff 1. 0 -> 1. 1 Arachne source Framework architecture Process version 1. 0 diff 1. 0 -> 1. 1 Arachne source version 1. 0 Minerve aspect 1. 0 -> 1. 1 Process version 1. 0 Arachne aspect 1. 0 -> 1. 1

Evaluation • Patches samples: – security advisory published by the CERT for open source 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 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 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 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?