Secure Coding in C and C++ for Automotive

Secure Coding in C and C++ for AutomotiveSECC-CCPPACYCydrillCY-SECC-CCPPA1.0<ul> <li>Getting familiar with essential cyber security concepts</li><li>Learning about security specialties of the automotive sector</li><li>Identify vulnerabilities and their consequences</li><li>Learn the security best practices in C and C++</li><li>Input validation approaches and principles</li><li>Managing vulnerabilities in third party components</li><li>Understanding security testing methodology and approaches</li><li>Getting familiar with common security testing techniques and tools</li></ul>General C/C++ development<ul> <li>Automotive Sector</li><li>C/C++ developers</li></ul><ul> <li>Cyber security basics</li><li>Buffer overflow</li><li>Memory management hardening</li><li>Common software security weaknesses</li><li>Using vulnerable components</li><li>Security testing</li><li>Wrap up</li></ul>DAY 1 Cyber security basics <ul> <li>What is security?</li><li>Threat and risk</li><li>Cyber security threat types</li><li>Consequences of insecure software <ul> <li>Constraints and the market</li><li>The dark side</li></ul></li><li>Categorization of bugs <ul> <li>The Seven Pernicious Kingdoms</li><li>SEI CERT Secure Coding Guidelines</li></ul></li><li>Coding standards in automotive <ul> <li>ISO 26262</li><li>MISRA C 2012</li><li>MISRA C++ 2008</li><li>AUTOSAR C++14 and the future</li><li>CERT C Coding Standard</li><li>CERT C++ Coding Standard</li></ul></li><li>Cyber security in the automotive sector <ul> <li>Software security in the automotive world</li><li>Threats and trends in automotive</li><li>Self-driving car threats</li><li>The CAN bus and security</li><li>Case study – controlling the CAN bus through the infotainment system</li></ul></li></ul>Buffer overflow <ul> <li>Assembly basics and calling conventions <ul> <li>ARM assembly essentials</li><li>Registers and addressing</li><li>Basic ARM64 instructions</li><li>ARM calling conventions <ul> <li>The calling convention</li><li>The stack frame</li><li>Calling convention implementation on ARM64</li><li>Stacked function calls</li></ul></li></ul></li><li>Memory management vulnerabilities <ul> <li>Memory management and security</li><li>Vulnerabilities in the real world</li><li>Mapping to MISRA</li><li>Buffer security issues</li><li>Buffer overflow on the stack <ul> <li>Buffer overflow on the stack – stack smashing</li><li>Exploitation – Hijacking the control flow</li><li>Lab – Buffer overflow 101, code reuse</li><li>Exploitation – Arbitrary code execution</li><li>Injecting shellcode</li><li>Lab – Code injection, exploitation with shellcode</li></ul></li><li>Buffer overflow on the heap <ul> <li>Unsafe unlinking</li><li>Case study – Heartbleed</li></ul></li><li>Pointer manipulation <ul> <li>Modification of jump tables</li><li>Overwriting function pointers</li></ul></li></ul></li><li>Best practices and some typical mistakes <ul> <li>Unsafe functions</li><li>Dealing with unsafe functions</li><li>Lab – Fixing buffer overflow</li><li>What’s the problem with asctime()?</li><li>Lab – The problem with asctime()</li><li>Using std::string in C++</li></ul></li></ul>DAY 2 Buffer overflow <ul> <li>Some typical mistakes leading to BOF <ul> <li>Unterminated strings</li><li>readlink() and string termination</li><li>Manipulating C-style strings in C++</li><li>Malicious string termination</li><li>Lab – String termination confusion</li><li>String length calculation mistakes</li><li>Off-by-one errors</li><li>Allocating nothing</li></ul></li></ul>Memory management hardening <ul> <li>Mapping to MISRA</li><li>Securing the toolchain <ul> <li>Securing the toolchain in C and C++</li><li>Compiler warnings and security</li><li>Using FORTIFY_SOURCE</li><li>Lab – Effects of FORTIFY</li><li>AddressSanitizer (ASan) <ul> <li>Using AddressSanitizer (ASan)</li><li>ASan changes to the prologue</li><li>ASan changes to memory read/write operations</li><li>ASan changes to epilogue</li></ul></li><li>Stack smashing protection <ul> <li>Detecting BoF with a stack canary</li><li>Argument cloning</li><li>Stack smashing protection on various platforms</li><li>SSP changes to the prologue and epilogue</li><li>Lab – Effects of stack smashing protection</li></ul></li></ul></li><li>Runtime protections <ul> <li>Runtime instrumentation</li><li>Address Space Layout Randomization (ASLR) <ul> <li>ASLR on various platforms</li><li>Lab – Effects of ASLR</li><li>Circumventing ASLR – NOP sleds</li><li>Heap spraying</li></ul></li><li>Non-executable memory areas <ul> <li>The NX bit</li><li>Write XOR Execute (W^X)</li><li>NX on various platforms</li><li>Lab – Effects of NX</li><li>NX circumvention – Code reuse attacks <ul> <li>Return-to-libc / arc injection</li></ul></li><li>Return Oriented Programming (ROP) <ul> <li>Lab – ROP demonstration</li><li>Protection against ROP</li></ul></li></ul></li></ul></li></ul>Common software security weaknesses <ul> <li>Security features <ul> <li>Authentication <ul> <li>Authentication basics</li><li>Multi-factor authentication</li><li>Authentication weaknesses – spoofing</li><li>Case study – Hacking the Mitsubishi Outlander PHEV hybrid</li></ul></li><li>Password management <ul> <li>Inbound password management <ul> <li>Storing account passwords</li><li>Password in transit</li><li>Lab – Is just hashing passwords enough?</li><li>Dictionary attacks and brute forcing</li><li>Salting</li><li>Adaptive hash functions for password storage</li><li>Password policy <ul> <li>NIST authenticator requirements for memorized secrets</li></ul></li><li>Case study – The Ashley Madison data breach <ul> <li>The dictionary attack</li><li>The ultimate crack</li><li>Exploitation and the lessons learned</li></ul></li><li>Password database migration</li></ul></li><li>Outbound password management <ul> <li>Hard coded passwords</li><li>Best practices</li><li>Lab – Hardcoded password</li><li>Protecting sensitive information in memory <ul> <li>Challenges in protecting memory</li><li>Heap inspection</li><li>Compiler optimization challenges</li><li>Lab – Zeroization challenges</li><li>Sensitive info in non-locked memory</li></ul></li></ul></li></ul></li><li>Authorization <ul> <li>Access control basics</li><li>File system access control <ul> <li>Improper file system access control</li><li>Ownership</li><li>chroot jail</li><li>Using umask()</li><li>Linux filesystem</li><li>LDAP</li></ul></li></ul></li></ul></li></ul> DAY 3 Common software security weaknesses <ul> <li>Input validation <ul> <li>Input validation principles <ul> <li>Blacklists and whitelists</li><li>Data validation techniques</li><li>What to validate – the attack surface</li><li>Attack surface in automotive</li><li>Where to validate – defense in depth</li><li>How to validate – validation vs transformations</li><li>Output sanitization</li><li>Encoding challenges</li><li>Validation with regex</li><li>Mapping to MISRA</li></ul></li><li>Injection <ul> <li>Injection principles</li><li>Injection attacks</li><li>Code injection <ul> <li>OS command injection <ul> <li>Lab – Command injection</li><li>OS command injection best practices</li><li>Avoiding command injection with the right APIs</li><li>Lab – Command injection best practices</li><li>Case study – Shellshock</li><li>Lab – Shellshock</li><li>Case study – Command injection in Jeep Cherokee</li></ul></li><li>Process control – library injection <ul> <li>DLL hijacking</li><li>Lab – DLL hijacking</li></ul></li></ul></li></ul></li><li>Integer handling problems <ul> <li>Representing signed numbers</li><li>Integer visualization</li><li>The MISRA essential type model</li><li>Integer promotion</li><li>Composite expressions and type conversion</li><li>Integer overflow</li><li>Lab – Integer overflow</li><li>Signed / unsigned confusion</li><li>Lab – Signed / unsigned confusion</li><li>Integer truncation</li><li>Lab – Integer truncation</li><li>Case study – WannaCry</li><li>Best practices <ul> <li>Upcasting</li><li>Precondition testing</li><li>Postcondition testing</li><li>Using big integer libraries</li><li>Best practices in C</li><li>Lab – Handling integer overflow on the toolchain level in C/C++</li><li>Best practices in C++</li><li>Lab – Integer handling best practices in C++</li></ul></li></ul></li><li>Other numeric problems <ul> <li>Security issues with bitfields</li><li>Division by zero</li><li>Working with floating-point numbers</li></ul></li><li>Files and streams <ul> <li>Path traversal</li><li>Path traversal-related examples</li><li>Lab – Path traversal</li><li>Link and shortcut following</li><li>Virtual resources</li><li>Path traversal best practices</li><li>Lab – Path canonicalization <ul> <li>Format string issues</li><li>The problem with printf()</li><li>Lab – Exploiting format string</li></ul></li></ul></li></ul></li></ul>DAY 4 Common software security weaknesses <ul> <li>Time and state <ul> <li>Mapping to MISRA</li><li>Race conditions <ul> <li>Race condition in object data members</li><li>File race condition <ul> <li>Time of check to time of usage – TOCTTOU</li><li>Lab – TOCTTOU</li><li>Insecure temporary file</li></ul></li><li>Potential race conditions in C/C++ <ul> <li>Race condition in signal handling</li><li>Forking</li><li>Bit-field access</li></ul></li></ul></li></ul></li><li>Errors <ul> <li>Error and exception handling principles</li><li>Mapping to MISRA</li><li>Error handling <ul> <li>Returning a misleading status code</li><li>Error handling in C</li><li>Error handling in C++</li><li>Using std::optional safely</li><li>Information exposure through error reporting</li></ul></li><li>Exception handling <ul> <li>In the catch block. And now what?</li><li>Empty catch block</li><li>Exception handling in C++</li><li>Lab – Exception handling mess</li></ul></li></ul></li><li>Code quality <ul> <li>Data handling <ul> <li>Type mismatch</li><li>Lab – Type mismatch</li><li>Initialization and cleanup <ul> <li>Constructors and destructors</li><li>Initialization of static objects</li><li>Lab – Initialization cycles</li></ul></li><li>Unreleased resource <ul> <li>Array disposal in C++</li><li>Lab – Mixing delete and delete[]</li></ul></li></ul></li><li>Control flow <ul> <li>Incorrect block delimitation</li><li>Dead code</li><li>Leftover debug code</li><li>Backdoors, dev functions and other undocumented functions</li><li>Using if-then-else and switch defensively</li></ul></li><li>Signal handling <ul> <li>Signal handlers</li><li>Best practices</li></ul></li><li>Object oriented programming pitfalls <ul> <li>Inheritance and object slicing</li><li>Implementing the copy operator</li><li>The copy operator and mutability</li><li>Mutability <ul> <li>Mutable predicate function objects</li><li>Lab – Mutable predicate function object</li></ul></li></ul></li><li>Memory and pointers <ul> <li>Memory and pointer issues</li><li>Pointer handling pitfalls</li><li>Alignment</li><li>Null pointers <ul> <li>NULL dereference</li><li>NULL dereference in pointer-to-member operators</li></ul></li><li>Pointer usage in C and C++ <ul> <li>Use after free</li><li>Lab – Use after free</li><li>Lab – Runtime instrumentation</li><li>Double free</li><li>Memory leak</li><li>Smart pointers and RAII</li><li>Smart pointer challenges</li><li>Incorrect pointer arithmetics</li></ul></li></ul></li><li>File I/O <ul> <li>Working with file descriptors, structures and objects</li><li>File reading and writing</li><li>File access functions and methods</li></ul></li></ul></li></ul>Using vulnerable components <ul> <li>Assessing the environment</li><li>Hardening</li><li>Vulnerability management <ul> <li>Patch management</li><li>Bug bounty programs</li><li>Vulnerability databases</li><li>Vulnerability rating – CVSS</li><li>Lab – Finding vulnerabilities in third-party components</li><li>DevOps, the build process and CI / CD</li><li>Insecure compiler optimization</li></ul></li></ul>Security testing <ul> <li>Security testing vs functional testing</li><li>Manual and automated methods</li><li>Security testing techniques and tools <ul> <li>Code analysis <ul> <li>Security aspects of code review</li><li>Static Application Security Testing (SAST)</li><li>Lab – Using static analysis tools</li></ul></li><li>Dynamic analysis <ul> <li>Security testing at runtime</li><li>Penetration testing</li><li>Stress testing</li><li>Dynamic analysis tools <ul> <li>Dynamic Application Security Testing (DAST)</li></ul></li><li>Fuzzing <ul> <li>Fuzzing techniques</li><li>Fuzzing – Observing the process</li></ul></li></ul></li></ul></li></ul>Wrap up <ul> <li>Secure coding principles <ul> <li>Principles of robust programming by Matt Bishop</li><li>Secure design principles of Saltzer and Schröder</li></ul></li><li>And now what? <ul> <li>Software security sources and further reading</li><li>C and C++ resources</li><li>Links to automotive coding standards</li></ul></li></ul>- Getting familiar with essential cyber security concepts - Learning about security specialties of the automotive sector - Identify vulnerabilities and their consequences - Learn the security best practices in C and C++ - Input validation approaches and principles - Managing vulnerabilities in third party components - Understanding security testing methodology and approaches - Getting familiar with common security testing techniques and toolsGeneral C/C++ development- Automotive Sector - C/C++ developers- Cyber security basics - Buffer overflow - Memory management hardening - Common software security weaknesses - Using vulnerable components - Security testing - Wrap upDAY 1 Cyber security basics - What is security? - Threat and risk - Cyber security threat types - Consequences of insecure software - Constraints and the market - The dark side - Categorization of bugs - The Seven Pernicious Kingdoms - SEI CERT Secure Coding Guidelines - Coding standards in automotive - ISO 26262 - MISRA C 2012 - MISRA C++ 2008 - AUTOSAR C++14 and the future - CERT C Coding Standard - CERT C++ Coding Standard - Cyber security in the automotive sector - Software security in the automotive world - Threats and trends in automotive - Self-driving car threats - The CAN bus and security - Case study – controlling the CAN bus through the infotainment system Buffer overflow - Assembly basics and calling conventions - ARM assembly essentials - Registers and addressing - Basic ARM64 instructions - ARM calling conventions - The calling convention - The stack frame - Calling convention implementation on ARM64 - Stacked function calls - Memory management vulnerabilities - Memory management and security - Vulnerabilities in the real world - Mapping to MISRA - Buffer security issues - Buffer overflow on the stack - Buffer overflow on the stack – stack smashing - Exploitation – Hijacking the control flow - Lab – Buffer overflow 101, code reuse - Exploitation – Arbitrary code execution - Injecting shellcode - Lab – Code injection, exploitation with shellcode - Buffer overflow on the heap - Unsafe unlinking - Case study – Heartbleed - Pointer manipulation - Modification of jump tables - Overwriting function pointers - Best practices and some typical mistakes - Unsafe functions - Dealing with unsafe functions - Lab – Fixing buffer overflow - What’s the problem with asctime()? - Lab – The problem with asctime() - Using std::string in C++ DAY 2 Buffer overflow - Some typical mistakes leading to BOF - Unterminated strings - readlink() and string termination - Manipulating C-style strings in C++ - Malicious string termination - Lab – String termination confusion - String length calculation mistakes - Off-by-one errors - Allocating nothing Memory management hardening - Mapping to MISRA - Securing the toolchain - Securing the toolchain in C and C++ - Compiler warnings and security - Using FORTIFY_SOURCE - Lab – Effects of FORTIFY - AddressSanitizer (ASan) - Using AddressSanitizer (ASan) - ASan changes to the prologue - ASan changes to memory read/write operations - ASan changes to epilogue - Stack smashing protection - Detecting BoF with a stack canary - Argument cloning - Stack smashing protection on various platforms - SSP changes to the prologue and epilogue - Lab – Effects of stack smashing protection - Runtime protections - Runtime instrumentation - Address Space Layout Randomization (ASLR) - ASLR on various platforms - Lab – Effects of ASLR - Circumventing ASLR – NOP sleds - Heap spraying - Non-executable memory areas - The NX bit - Write XOR Execute (W^X) - NX on various platforms - Lab – Effects of NX - NX circumvention – Code reuse attacks - Return-to-libc / arc injection - Return Oriented Programming (ROP) - Lab – ROP demonstration - Protection against ROP Common software security weaknesses - Security features - Authentication - Authentication basics - Multi-factor authentication - Authentication weaknesses – spoofing - Case study – Hacking the Mitsubishi Outlander PHEV hybrid - Password management - Inbound password management - Storing account passwords - Password in transit - Lab – Is just hashing passwords enough? - Dictionary attacks and brute forcing - Salting - Adaptive hash functions for password storage - Password policy - NIST authenticator requirements for memorized secrets - Case study – The Ashley Madison data breach - The dictionary attack - The ultimate crack - Exploitation and the lessons learned - Password database migration - Outbound password management - Hard coded passwords - Best practices - Lab – Hardcoded password - Protecting sensitive information in memory - Challenges in protecting memory - Heap inspection - Compiler optimization challenges - Lab – Zeroization challenges - Sensitive info in non-locked memory - Authorization - Access control basics - File system access control - Improper file system access control - Ownership - chroot jail - Using umask() - Linux filesystem - LDAP DAY 3 Common software security weaknesses - Input validation - Input validation principles - Blacklists and whitelists - Data validation techniques - What to validate – the attack surface - Attack surface in automotive - Where to validate – defense in depth - How to validate – validation vs transformations - Output sanitization - Encoding challenges - Validation with regex - Mapping to MISRA - Injection - Injection principles - Injection attacks - Code injection - OS command injection - Lab – Command injection - OS command injection best practices - Avoiding command injection with the right APIs - Lab – Command injection best practices - Case study – Shellshock - Lab – Shellshock - Case study – Command injection in Jeep Cherokee - Process control – library injection - DLL hijacking - Lab – DLL hijacking - Integer handling problems - Representing signed numbers - Integer visualization - The MISRA essential type model - Integer promotion - Composite expressions and type conversion - Integer overflow - Lab – Integer overflow - Signed / unsigned confusion - Lab – Signed / unsigned confusion - Integer truncation - Lab – Integer truncation - Case study – WannaCry - Best practices - Upcasting - Precondition testing - Postcondition testing - Using big integer libraries - Best practices in C - Lab – Handling integer overflow on the toolchain level in C/C++ - Best practices in C++ - Lab – Integer handling best practices in C++ - Other numeric problems - Security issues with bitfields - Division by zero - Working with floating-point numbers - Files and streams - Path traversal - Path traversal-related examples - Lab – Path traversal - Link and shortcut following - Virtual resources - Path traversal best practices - Lab – Path canonicalization - Format string issues - The problem with printf() - Lab – Exploiting format string DAY 4 Common software security weaknesses - Time and state - Mapping to MISRA - Race conditions - Race condition in object data members - File race condition - Time of check to time of usage – TOCTTOU - Lab – TOCTTOU - Insecure temporary file - Potential race conditions in C/C++ - Race condition in signal handling - Forking - Bit-field access - Errors - Error and exception handling principles - Mapping to MISRA - Error handling - Returning a misleading status code - Error handling in C - Error handling in C++ - Using std::optional safely - Information exposure through error reporting - Exception handling - In the catch block. And now what? - Empty catch block - Exception handling in C++ - Lab – Exception handling mess - Code quality - Data handling - Type mismatch - Lab – Type mismatch - Initialization and cleanup - Constructors and destructors - Initialization of static objects - Lab – Initialization cycles - Unreleased resource - Array disposal in C++ - Lab – Mixing delete and delete[] - Control flow - Incorrect block delimitation - Dead code - Leftover debug code - Backdoors, dev functions and other undocumented functions - Using if-then-else and switch defensively - Signal handling - Signal handlers - Best practices - Object oriented programming pitfalls - Inheritance and object slicing - Implementing the copy operator - The copy operator and mutability - Mutability - Mutable predicate function objects - Lab – Mutable predicate function object - Memory and pointers - Memory and pointer issues - Pointer handling pitfalls - Alignment - Null pointers - NULL dereference - NULL dereference in pointer-to-member operators - Pointer usage in C and C++ - Use after free - Lab – Use after free - Lab – Runtime instrumentation - Double free - Memory leak - Smart pointers and RAII - Smart pointer challenges - Incorrect pointer arithmetics - File I/O - Working with file descriptors, structures and objects - File reading and writing - File access functions and methods Using vulnerable components - Assessing the environment - Hardening - Vulnerability management - Patch management - Bug bounty programs - Vulnerability databases - Vulnerability rating – CVSS - Lab – Finding vulnerabilities in third-party components - DevOps, the build process and CI / CD - Insecure compiler optimization Security testing - Security testing vs functional testing - Manual and automated methods - Security testing techniques and tools - Code analysis - Security aspects of code review - Static Application Security Testing (SAST) - Lab – Using static analysis tools - Dynamic analysis - Security testing at runtime - Penetration testing - Stress testing - Dynamic analysis tools - Dynamic Application Security Testing (DAST) - Fuzzing - Fuzzing techniques - Fuzzing – Observing the process Wrap up - Secure coding principles - Principles of robust programming by Matt Bishop - Secure design principles of Saltzer and Schröder - And now what? - Software security sources and further reading - C and C++ resources - Links to automotive coding standards4 Tage3000.003000.003000.003000.003000.003000.003000.003000.003000.003000.003000.00