software security, secure programming

23
Software security, secure programming Lecture 1: introduction Master M2 Cybersecurity & MoSiG Academic Year 2020 - 2021

Upload: others

Post on 02-May-2022

2 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 2: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 3: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 4: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 5: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 6: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 7: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 8: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 9: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 10: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 11: Software security, secure programming

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

  • Some practical information
  • What software security is (not) about
  • About software security
Page 12: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 13: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 14: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 15: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 16: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 17: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 18: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 19: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 20: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 21: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 22: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security
Page 23: Software security, secure programming

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 practical information
  • What software security is (not) about
  • About software security