View
2
Download
0
Category
Preview:
Citation preview
Software security secure programming
Lecture 1 introduction
Master M2 Cybersecurity amp MoSiG
Academic Year 2020 - 2021
Who are we
Teaching staffI Laurent Mounier (UGA) Marie-Laure Potet (G-INP)
Mathias Ramparon (G-INP)I research within Verimag LabI research focus formal verification code analysis compilation
techniques language semantics and (software) security
AttendeesI Master M2 on Cybersecurity [mandatory course]I Master M2 MoSiG [optionnal course]
rarr various skills backgroud and interests
2 21
Agenda
Part 1 an overview of software security and secure programmingI 6 weeks (18 hours)I for all of you I classes on tuesday (1115am-1245am) and wednesday (2pm-330pm)rarr includes lectures exercises and lab sessions
Part 2 some tools and techniques for software securityI 7 weeks (21 hours)I for M2 Cyberscurity onlyI class on tuesday (815am - 1115am)
3 21
Examination rulesThe rules of the game
AssignmentsI M1 a written exam (duration sim 15h mid-November)I M2 a (short) report on lab sessionsI M3 an oral presentation (in January)I M4 final written exam (duration=2h end of January)
Mark computation (3 ECTS)I for MoSiG students
M = (03timesM2) + (07timesM1)
I for Cybersecurity students
M = (05timesM1 + 025timesM2 + 025timesM3)2 + (05timesM4)
4 21
Course user manual
An (on-going) course web page
httpwww-verimagimagfr~mounierEnseignementSoftware_Security
I course schedule and materials (slides etc)I weekly reading suggestions to complete the lectureI other background readingbrowsing advices
During the classes Alternation between lectures written excercices lab exercises but no ldquoformalrdquo lecturesrarr questions amp discussions always welcome
heterogeneous audience + open topics rArr high interactivity level
5 21
PrerequisitesIdeally
This course is concerned with
Programming languagesI at least one (classical) imperative language
C or C++ Java Python I some notions on compilation amp language semantics
What happens behind the curtainSome notions aboutI assembly code (ARM x86 others )I memory organization (stack heap)
6 21
Outline
Some practical information
What software security is (not) about
About software security
The context computer system security
Question 1 what is a ldquocomputer systemrdquo or an execution plateform
Many possible incarnations egI (classical) computer mainframe server desktopI mobile device phone tablets audiovideo player etc
up to IoT smart cards I embedded (networked) systems inside a car a plane a
washing-machine etcI cloud computing virtual execution environmentI but also industrial networks (Scada) etcI and certainly many more
rarr 2 main characteristicsI include hardware + softwareI openconnected to the outside world
7 21
The context computer system security (ctrsquod)
Question 2 what does mean security
I a set of general security properties CIAConfidentiality Integrity Availability (+ Non Repudiation + Anonymity + )
I concerns the running software + the whole execution plateform(other users shared resources and data peripherals network etc)
I depends on an intruder modelrarr there is an ldquoexternal actorrdquo1 with an attack objective in mind andable to elaborate a dedicated strategy to achieve it (6= hazards)rarr something beyond safety and fault-tolerance
rarr A possible definitionI functionnal properties = what the system should doI security properties = what it should not allow wrt the intruder model
Rk functionnal properties do matter for ldquosecurity-orientedrdquo software (firewalls etc)
1could be the user or the execution plateform itself8 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Who are we
Teaching staffI Laurent Mounier (UGA) Marie-Laure Potet (G-INP)
Mathias Ramparon (G-INP)I research within Verimag LabI research focus formal verification code analysis compilation
techniques language semantics and (software) security
AttendeesI Master M2 on Cybersecurity [mandatory course]I Master M2 MoSiG [optionnal course]
rarr various skills backgroud and interests
2 21
Agenda
Part 1 an overview of software security and secure programmingI 6 weeks (18 hours)I for all of you I classes on tuesday (1115am-1245am) and wednesday (2pm-330pm)rarr includes lectures exercises and lab sessions
Part 2 some tools and techniques for software securityI 7 weeks (21 hours)I for M2 Cyberscurity onlyI class on tuesday (815am - 1115am)
3 21
Examination rulesThe rules of the game
AssignmentsI M1 a written exam (duration sim 15h mid-November)I M2 a (short) report on lab sessionsI M3 an oral presentation (in January)I M4 final written exam (duration=2h end of January)
Mark computation (3 ECTS)I for MoSiG students
M = (03timesM2) + (07timesM1)
I for Cybersecurity students
M = (05timesM1 + 025timesM2 + 025timesM3)2 + (05timesM4)
4 21
Course user manual
An (on-going) course web page
httpwww-verimagimagfr~mounierEnseignementSoftware_Security
I course schedule and materials (slides etc)I weekly reading suggestions to complete the lectureI other background readingbrowsing advices
During the classes Alternation between lectures written excercices lab exercises but no ldquoformalrdquo lecturesrarr questions amp discussions always welcome
heterogeneous audience + open topics rArr high interactivity level
5 21
PrerequisitesIdeally
This course is concerned with
Programming languagesI at least one (classical) imperative language
C or C++ Java Python I some notions on compilation amp language semantics
What happens behind the curtainSome notions aboutI assembly code (ARM x86 others )I memory organization (stack heap)
6 21
Outline
Some practical information
What software security is (not) about
About software security
The context computer system security
Question 1 what is a ldquocomputer systemrdquo or an execution plateform
Many possible incarnations egI (classical) computer mainframe server desktopI mobile device phone tablets audiovideo player etc
up to IoT smart cards I embedded (networked) systems inside a car a plane a
washing-machine etcI cloud computing virtual execution environmentI but also industrial networks (Scada) etcI and certainly many more
rarr 2 main characteristicsI include hardware + softwareI openconnected to the outside world
7 21
The context computer system security (ctrsquod)
Question 2 what does mean security
I a set of general security properties CIAConfidentiality Integrity Availability (+ Non Repudiation + Anonymity + )
I concerns the running software + the whole execution plateform(other users shared resources and data peripherals network etc)
I depends on an intruder modelrarr there is an ldquoexternal actorrdquo1 with an attack objective in mind andable to elaborate a dedicated strategy to achieve it (6= hazards)rarr something beyond safety and fault-tolerance
rarr A possible definitionI functionnal properties = what the system should doI security properties = what it should not allow wrt the intruder model
Rk functionnal properties do matter for ldquosecurity-orientedrdquo software (firewalls etc)
1could be the user or the execution plateform itself8 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Agenda
Part 1 an overview of software security and secure programmingI 6 weeks (18 hours)I for all of you I classes on tuesday (1115am-1245am) and wednesday (2pm-330pm)rarr includes lectures exercises and lab sessions
Part 2 some tools and techniques for software securityI 7 weeks (21 hours)I for M2 Cyberscurity onlyI class on tuesday (815am - 1115am)
3 21
Examination rulesThe rules of the game
AssignmentsI M1 a written exam (duration sim 15h mid-November)I M2 a (short) report on lab sessionsI M3 an oral presentation (in January)I M4 final written exam (duration=2h end of January)
Mark computation (3 ECTS)I for MoSiG students
M = (03timesM2) + (07timesM1)
I for Cybersecurity students
M = (05timesM1 + 025timesM2 + 025timesM3)2 + (05timesM4)
4 21
Course user manual
An (on-going) course web page
httpwww-verimagimagfr~mounierEnseignementSoftware_Security
I course schedule and materials (slides etc)I weekly reading suggestions to complete the lectureI other background readingbrowsing advices
During the classes Alternation between lectures written excercices lab exercises but no ldquoformalrdquo lecturesrarr questions amp discussions always welcome
heterogeneous audience + open topics rArr high interactivity level
5 21
PrerequisitesIdeally
This course is concerned with
Programming languagesI at least one (classical) imperative language
C or C++ Java Python I some notions on compilation amp language semantics
What happens behind the curtainSome notions aboutI assembly code (ARM x86 others )I memory organization (stack heap)
6 21
Outline
Some practical information
What software security is (not) about
About software security
The context computer system security
Question 1 what is a ldquocomputer systemrdquo or an execution plateform
Many possible incarnations egI (classical) computer mainframe server desktopI mobile device phone tablets audiovideo player etc
up to IoT smart cards I embedded (networked) systems inside a car a plane a
washing-machine etcI cloud computing virtual execution environmentI but also industrial networks (Scada) etcI and certainly many more
rarr 2 main characteristicsI include hardware + softwareI openconnected to the outside world
7 21
The context computer system security (ctrsquod)
Question 2 what does mean security
I a set of general security properties CIAConfidentiality Integrity Availability (+ Non Repudiation + Anonymity + )
I concerns the running software + the whole execution plateform(other users shared resources and data peripherals network etc)
I depends on an intruder modelrarr there is an ldquoexternal actorrdquo1 with an attack objective in mind andable to elaborate a dedicated strategy to achieve it (6= hazards)rarr something beyond safety and fault-tolerance
rarr A possible definitionI functionnal properties = what the system should doI security properties = what it should not allow wrt the intruder model
Rk functionnal properties do matter for ldquosecurity-orientedrdquo software (firewalls etc)
1could be the user or the execution plateform itself8 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Examination rulesThe rules of the game
AssignmentsI M1 a written exam (duration sim 15h mid-November)I M2 a (short) report on lab sessionsI M3 an oral presentation (in January)I M4 final written exam (duration=2h end of January)
Mark computation (3 ECTS)I for MoSiG students
M = (03timesM2) + (07timesM1)
I for Cybersecurity students
M = (05timesM1 + 025timesM2 + 025timesM3)2 + (05timesM4)
4 21
Course user manual
An (on-going) course web page
httpwww-verimagimagfr~mounierEnseignementSoftware_Security
I course schedule and materials (slides etc)I weekly reading suggestions to complete the lectureI other background readingbrowsing advices
During the classes Alternation between lectures written excercices lab exercises but no ldquoformalrdquo lecturesrarr questions amp discussions always welcome
heterogeneous audience + open topics rArr high interactivity level
5 21
PrerequisitesIdeally
This course is concerned with
Programming languagesI at least one (classical) imperative language
C or C++ Java Python I some notions on compilation amp language semantics
What happens behind the curtainSome notions aboutI assembly code (ARM x86 others )I memory organization (stack heap)
6 21
Outline
Some practical information
What software security is (not) about
About software security
The context computer system security
Question 1 what is a ldquocomputer systemrdquo or an execution plateform
Many possible incarnations egI (classical) computer mainframe server desktopI mobile device phone tablets audiovideo player etc
up to IoT smart cards I embedded (networked) systems inside a car a plane a
washing-machine etcI cloud computing virtual execution environmentI but also industrial networks (Scada) etcI and certainly many more
rarr 2 main characteristicsI include hardware + softwareI openconnected to the outside world
7 21
The context computer system security (ctrsquod)
Question 2 what does mean security
I a set of general security properties CIAConfidentiality Integrity Availability (+ Non Repudiation + Anonymity + )
I concerns the running software + the whole execution plateform(other users shared resources and data peripherals network etc)
I depends on an intruder modelrarr there is an ldquoexternal actorrdquo1 with an attack objective in mind andable to elaborate a dedicated strategy to achieve it (6= hazards)rarr something beyond safety and fault-tolerance
rarr A possible definitionI functionnal properties = what the system should doI security properties = what it should not allow wrt the intruder model
Rk functionnal properties do matter for ldquosecurity-orientedrdquo software (firewalls etc)
1could be the user or the execution plateform itself8 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Course user manual
An (on-going) course web page
httpwww-verimagimagfr~mounierEnseignementSoftware_Security
I course schedule and materials (slides etc)I weekly reading suggestions to complete the lectureI other background readingbrowsing advices
During the classes Alternation between lectures written excercices lab exercises but no ldquoformalrdquo lecturesrarr questions amp discussions always welcome
heterogeneous audience + open topics rArr high interactivity level
5 21
PrerequisitesIdeally
This course is concerned with
Programming languagesI at least one (classical) imperative language
C or C++ Java Python I some notions on compilation amp language semantics
What happens behind the curtainSome notions aboutI assembly code (ARM x86 others )I memory organization (stack heap)
6 21
Outline
Some practical information
What software security is (not) about
About software security
The context computer system security
Question 1 what is a ldquocomputer systemrdquo or an execution plateform
Many possible incarnations egI (classical) computer mainframe server desktopI mobile device phone tablets audiovideo player etc
up to IoT smart cards I embedded (networked) systems inside a car a plane a
washing-machine etcI cloud computing virtual execution environmentI but also industrial networks (Scada) etcI and certainly many more
rarr 2 main characteristicsI include hardware + softwareI openconnected to the outside world
7 21
The context computer system security (ctrsquod)
Question 2 what does mean security
I a set of general security properties CIAConfidentiality Integrity Availability (+ Non Repudiation + Anonymity + )
I concerns the running software + the whole execution plateform(other users shared resources and data peripherals network etc)
I depends on an intruder modelrarr there is an ldquoexternal actorrdquo1 with an attack objective in mind andable to elaborate a dedicated strategy to achieve it (6= hazards)rarr something beyond safety and fault-tolerance
rarr A possible definitionI functionnal properties = what the system should doI security properties = what it should not allow wrt the intruder model
Rk functionnal properties do matter for ldquosecurity-orientedrdquo software (firewalls etc)
1could be the user or the execution plateform itself8 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
PrerequisitesIdeally
This course is concerned with
Programming languagesI at least one (classical) imperative language
C or C++ Java Python I some notions on compilation amp language semantics
What happens behind the curtainSome notions aboutI assembly code (ARM x86 others )I memory organization (stack heap)
6 21
Outline
Some practical information
What software security is (not) about
About software security
The context computer system security
Question 1 what is a ldquocomputer systemrdquo or an execution plateform
Many possible incarnations egI (classical) computer mainframe server desktopI mobile device phone tablets audiovideo player etc
up to IoT smart cards I embedded (networked) systems inside a car a plane a
washing-machine etcI cloud computing virtual execution environmentI but also industrial networks (Scada) etcI and certainly many more
rarr 2 main characteristicsI include hardware + softwareI openconnected to the outside world
7 21
The context computer system security (ctrsquod)
Question 2 what does mean security
I a set of general security properties CIAConfidentiality Integrity Availability (+ Non Repudiation + Anonymity + )
I concerns the running software + the whole execution plateform(other users shared resources and data peripherals network etc)
I depends on an intruder modelrarr there is an ldquoexternal actorrdquo1 with an attack objective in mind andable to elaborate a dedicated strategy to achieve it (6= hazards)rarr something beyond safety and fault-tolerance
rarr A possible definitionI functionnal properties = what the system should doI security properties = what it should not allow wrt the intruder model
Rk functionnal properties do matter for ldquosecurity-orientedrdquo software (firewalls etc)
1could be the user or the execution plateform itself8 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Outline
Some practical information
What software security is (not) about
About software security
The context computer system security
Question 1 what is a ldquocomputer systemrdquo or an execution plateform
Many possible incarnations egI (classical) computer mainframe server desktopI mobile device phone tablets audiovideo player etc
up to IoT smart cards I embedded (networked) systems inside a car a plane a
washing-machine etcI cloud computing virtual execution environmentI but also industrial networks (Scada) etcI and certainly many more
rarr 2 main characteristicsI include hardware + softwareI openconnected to the outside world
7 21
The context computer system security (ctrsquod)
Question 2 what does mean security
I a set of general security properties CIAConfidentiality Integrity Availability (+ Non Repudiation + Anonymity + )
I concerns the running software + the whole execution plateform(other users shared resources and data peripherals network etc)
I depends on an intruder modelrarr there is an ldquoexternal actorrdquo1 with an attack objective in mind andable to elaborate a dedicated strategy to achieve it (6= hazards)rarr something beyond safety and fault-tolerance
rarr A possible definitionI functionnal properties = what the system should doI security properties = what it should not allow wrt the intruder model
Rk functionnal properties do matter for ldquosecurity-orientedrdquo software (firewalls etc)
1could be the user or the execution plateform itself8 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
The context computer system security
Question 1 what is a ldquocomputer systemrdquo or an execution plateform
Many possible incarnations egI (classical) computer mainframe server desktopI mobile device phone tablets audiovideo player etc
up to IoT smart cards I embedded (networked) systems inside a car a plane a
washing-machine etcI cloud computing virtual execution environmentI but also industrial networks (Scada) etcI and certainly many more
rarr 2 main characteristicsI include hardware + softwareI openconnected to the outside world
7 21
The context computer system security (ctrsquod)
Question 2 what does mean security
I a set of general security properties CIAConfidentiality Integrity Availability (+ Non Repudiation + Anonymity + )
I concerns the running software + the whole execution plateform(other users shared resources and data peripherals network etc)
I depends on an intruder modelrarr there is an ldquoexternal actorrdquo1 with an attack objective in mind andable to elaborate a dedicated strategy to achieve it (6= hazards)rarr something beyond safety and fault-tolerance
rarr A possible definitionI functionnal properties = what the system should doI security properties = what it should not allow wrt the intruder model
Rk functionnal properties do matter for ldquosecurity-orientedrdquo software (firewalls etc)
1could be the user or the execution plateform itself8 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
The context computer system security (ctrsquod)
Question 2 what does mean security
I a set of general security properties CIAConfidentiality Integrity Availability (+ Non Repudiation + Anonymity + )
I concerns the running software + the whole execution plateform(other users shared resources and data peripherals network etc)
I depends on an intruder modelrarr there is an ldquoexternal actorrdquo1 with an attack objective in mind andable to elaborate a dedicated strategy to achieve it (6= hazards)rarr something beyond safety and fault-tolerance
rarr A possible definitionI functionnal properties = what the system should doI security properties = what it should not allow wrt the intruder model
Rk functionnal properties do matter for ldquosecurity-orientedrdquo software (firewalls etc)
1could be the user or the execution plateform itself8 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Example 1 password authenticationIs this code ldquosecurerdquo
boolean verify (char[] input char[] passwd byte len) No more than triesLeft attemptsif (triesLeft lt 0) return false no authentication Main comparisonfor (short i=0 i lt= len i++)if (input[i] = passwd[i])
triesLeft-- return false no authentication
Comparison is successfultriesLeft = maxTries return true authentication is successful
functional property
verify(inputpasswdlen)hArr input[0len] = passwd[0len]
What do we want to protect Against what I confidentiality of passwd information leakage I no unexpected runtime behaviourI code integrity etc
9 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Example 2 file compression
Let us consider 2 programsI Compress to compress a file fI Uncompress to uncompress a (compressed) file c
A functional property the one we will try to validate
forallf Uncompress(Compress(f )) = f (1)
But what about uncompressing an arbitrary (ie maliciously crafted) file (eg CVE-2010-0001 for gzip)
A security property
( 6 existf Compress(f ) = c)rArr (Uncompress(c) 6 )
(uncompressing an arbitrary file should not produce unexpected crashes)
Actually (2) is much more difficult to validate than (1)
Demo make lsquopython -c rsquoprint A5000rsquolsquo
10 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Why do we need to bother about crashes
crash = consequence of an unexpected run-time errorI not trappedforeseen by the programmerI nor at the ldquoprogramming language levelrdquo
rArr part of the executionI may take place outside the program scope
(beyond the program semantic)I but can be controledexploited by an attacker (sim ldquoweird machinerdquo)
normal execution
crash
out of scope execution
possibly exploitable
runtime error
rarr may break all security properties from simple denial-of-service to arbitrary code execution
Rk may also happen silently (without any crash )
11 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Some (not standardized) definitions
Bug an error (or defectflawfailure) introduced in a SW eitherI at the specification design algorithmic levelI at the programming coding levelI or even by the compiler (or any other pgm transformation tools)
Vulnerability a weakness (for instance a bug ) that opens a security breachI non exploitable vulnerabilities there is no (known ) way for an attaker
to use this bug to corrupt the systemI exploitable vulnerabilities this bug can be used to elaborate an attack
(ie write an exploit)
Exploit a concrete program input allowing to exploit a vulnerability(from an attacker point of view )
PoC exploit assumes that existing protections are disabled(ie they can be hijacked wit other existing exploits)
Malware a piece of code ldquoinjectedrdquo inside a computer to corrupt itrarr they usually exploit existing vulnerabilities
12 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Software vulnerability examples
Case 1 (not so common )
Functional property not provided by a security-oriented componentI too weak crypto-systemI no (strong enough) authentication mechanismI etc
Case 2 (the vast majority )
Insecure coding practice in (any ) software componentapplicationI improper input validation SQL injection XSS etcI insecure shared resource management (file system network)I information leakage (lack of data encapsulation side channels)I exploitable run-time errorI etc
13 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
The intruder model
Who is the attacker I a malicious external user interacting via regular input sources
eg keyboard network (man-in-the-middle) etc
I a malicious external ldquoobserverrdquo interacting via side channels(execution time power consumption)
I another application running on the same plateforminteracting through shared resources like caches processor elements etc
I the execution plateform itself (eg when compromised )
What is heshe able to do At low levelI unexpected memory read (data or code)I unexpected memory write (data or code)
rArr powerful enough forI information disclosureI unexpectedarbitrary code executionI priviledge elevation etc
14 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Outline
Some practical information
What software security is (not) about
About software security
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Some evidences regarding cyber (un)-security
So many examples of successful computer system attacks
I the ldquofamous onesrdquo (at least one per year )Morris worm Stuxnet Heartbleed WannaCry Spectre etc
I the ldquocyber-attacksrdquo against large organizations (+ 400 in 10 years)Sony Yahoo Paypal e-Bay etc
I all the daily vulnerability alerts [have a look at these sites ]httpwwwus-certgovncashttpwwwsecurityfocuscomhttpwwwsecuritytrackercom
I etc
Why Who can we blame for that
I 6 exist well defined recipe to build secure cyber systems in the largeI permanent trade-off beetween efficiency and safetysecurity
I HW and micro-architectures (sharing is everywhere )I operating systemsI programming languages and applicationsI coding and software engineering techniques
15 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
But what about software security
Software is greatly involved in ldquocomputer system securityrdquoI it plays a major role in enforcing security properties
crypto authentication protocols intrusion detection firewall etcI but it is also a major source of security problems2
ldquo90 percent of security incidents result from exploits against defects in softwarerdquo ( US DHS)
rarr SW is clearly one of the weakest links in the security chain
Why I we do not no very well how to write secure SW
we do not even know how to write correct SWI behavioral properties canrsquot be validated on a (large) SW
impossible by hand untractable with a machineI programming languages not designed for security enforcement
most of them contain numerous traps and pitfallsI programmers feel not (so much) concerned with security
security not get enough attention in programmingSE coursesI heterogenous and nomad applications favor unsecure SW
remote execution mobile code plugins reflection etc
2outside security related code16 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Some evidences regarding software (un)-security (ctrsquod)
An increasing activity in the ldquodefender siderdquo as well
I all the daily security patches (for OS basic applications etc)
I companies and experts specialized in software securitycode audit search for 0days malware detection amp analysis etcldquobug bountiesrdquo [httpszerodiumcomprogramhtml]
I some important research effortsfrom the main software editors (eg MicroSoft Google etc)from the academic community (numerous dedicated conferences)from independent ldquoethical hackersrdquo (blogs etc)
I software verification tools editors start addressing security issueseg dedicated static analyser features
I international cooperation for vulnerability disclosure and classificationeg CERT CVECWE catalogue vulnerability databases
I government agencies to promote amp control SW securityeg ANSSI Darpa ldquoGrand Challengerdquo etc
17 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Couter-measures and protections (examples)
Several existing mechanisms to enforce SW security
I at the programming levelI disclosed vulnerabilities rarr language weaknesses databases
rarr secure coding patterns and librariesI aggressive compiler options + code instrumentation
rarr early detection of unsecure code
I at the OS levelI sandboxingI address space randomizationI non executable memory zonesI etc
I at the hardware levelI Trusted Platform Modules (TPM)I secure crypto-processorI CPU tracking mechanims (eg Intel Processor Trace)I etc
18 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Techniques and tools for assessing SW security
Several existing mechanisms to evaluate SW security
I code review
I fuzzingI run the code with ldquounexpectedrdquo inputs rarr pgm crashesI (tedious) manual check to find exploitable vulns
I (smart) testingcoverage-oriented pgm exploration techniques
(genetic algorithms dynamic-symbolic executions etc)+ code instrumentation to detect (low-level) vulnerabilities
I static analysis approximate the code behavior to detect potential vulns(sim code optimization techniques)
In practiceI only the binary code is always available and useful I combinations of all these techniques I exploitability analysis still challenging
19 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Course objectives (for the part 1)
Understand the root causes of common weaknesses in SW securityI at the programming language levelI at the execution platform level
rarr helps to better choose (or deal with) a programming language
Learn some methods and techniques to build more secure SWI programming techniques
languages coding patterns etcI validation techniques
what can(not) bring existing tools I counter-measures and protection mechanisms
20 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Course agenda (part 1)Seehttpwww-verimagimagfr~mounierEnseignementSoftware_Security
CreditsI E Poll (Radboud University)I M Payer (Purdue University)I E Jaeger O Levillain and P Chifflier (ANSSI)
21 21
Recommended