![©2018TrustInSoft
5
Howto reach these levels on legacy code?
• Level 1 for free
• Level 2 automatic with TrustInSoft Analyzer: just provide all source files
May be detected by modern binary-level LTO
Reduced example fromXen
file1.c: int GlobalConfig[255] = { 0 };
file2.c: extern int *Globalconfig;
• Level 3 not easy to get because
- Soundness: false alarms, not the most important problem
- Programs contain bugs: must be fixed to give semantics](https://image.slidesharecdn.com/2018625slidesssaswv6-180704143446/85/Applying-formal-methods-to-existing-software-by-B-Monate-5-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Applying formal methods to existing software by B.Monate (20)
Ad
Recently uploaded (20)
![Download Wondershare Filmora Crack [2025] With Latest](https://cdn.slidesharecdn.com/ss_thumbnails/neo4j-howkgsareshapingthefutureofgenerativeaiatawssummitlondonapril2024-240426125209-2d9db05d-250419-250428115407-a04afffa-thumbnail.jpg?width=560&fit=bounds)
Ad
Applying formal methods to existing software by B.Monate
- 1. ©2018TrustInSoft Benjamin Monate Co-founder of TrustInSoft and CTO Applying formal methods to existing software: what can you expect? 6/27/2018
- 2. ©2018TrustInSoft 2 Sound Static Analysis aka formal methods to prove properties of software Works for Safety Critical Software • Consequences of failures are analyzed fromthe beginning • Regulation is strong: standards and associated liability • Adapted development process: specific languages/dev. cycles • Software errors mitigated with systemarchitecture àconsidering probability of failure
- 3. ©2018TrustInSoft 3 Sound Static Analysisfor Security Critical Software? • Meanings of failure probability? àadversary defies standard distributions of the software input • One single error àarbitrary corruption • Confidentiality: secrets must not escape software • Software already deployed in production: barely tested for security - Because testing security is hard: looking for behaviors that have undefined consequences but are most of the time invisible - Observing a data leak is difficult: where shall it be observed? How shall one recognize that some bits are part of a secret?
- 4. ©2018TrustInSoft 4 TrustInSoft pragmatic and incremental security Each level requires someprevious ones to bemeaningful TrustInSoft Analyzer addresses Level 2 up to Level 5 Confidence Level Property Tool Guaranteed properties Level 1 Each compilation unit compiles Compilers with warnings Statictypingand syntacticcompliance Level 2 Integrity of link Sound SourceLinker Consistency of compilationunits (ODR/static inline/weak) Level 3 Only defined behaviors Sound StaticAnalyzer Absenceof undefined behaviors/Integrity Compilers optimizations makes the consequences more and more dangerous Level 4 Dataflowintegrity Sound StaticAnalyzer Absenceof unwanted data flows/Confidentiality Level 5 Functional correctness Sound Functional Verification Programfulfills its functional specification
- 5. ©2018TrustInSoft 5 Howto reach these levels on legacy code? • Level 1 for free • Level 2 automatic with TrustInSoft Analyzer: just provide all source files May be detected by modern binary-level LTO Reduced example fromXen file1.c: int GlobalConfig[255] = { 0 }; file2.c: extern int *Globalconfig; • Level 3 not easy to get because - Soundness: false alarms, not the most important problem - Programs contain bugs: must be fixed to give semantics
- 6. ©2018TrustInSoft 6 Methodology toward Level 3 security Do not explore all execution paths at once, but • Explore simple path: rely on existing test-suite • Fix all discovered bugs - Unliketesting: detect invisibleundefined behaviors àInvisiblebut may hidesecurity bugs thanks to compiler optimization/platform specificities - No need to befully deterministic: external functions/hardwareare stubbed - Useanexistingtest to reach somedifficult-to-reach programpoints (after SSL certificatevalidation) and theninvent newtests by mutating the input data that do not changetheinitial paths (fuzzing, manual testing) - Generalizethetests progressively àfix bugs one after the other - Maybe one reaches a state where all behaviors are covered àBut if onedoes not, thesecurity is still vastly improved, step-by-step
- 7. ©2018TrustInSoft 7 Howlong does it take to get a proof of absence of undefined behaviors? • Major industrial question: ROI, Time To Market, Total Cost of Ownership • Important but flawed question: - It takes the time that one needs to fix all the discovered bugs - No one knows howto evaluate this soundly • Cyber-security is incremental - Soundness does not mean: “all questions answered” - Soundness does mean: “some questions answered definitively” Not necessarily “the” whole question
- 8. ©2018TrustInSoft 8 Examples: tooling funded for zero false positive and zero false negative source code analysis Hundreds of security bugs discovered: most of themfixed upstream • Initial analysis: existing test-suites • Further analysis: AFL fuzzing • Next steps: generalized input to reach more behaviors Invalid memory accesses, signed overflows, uninitialized data, double free, strict aliasing violations, constant execution time… OpenSSL, Amazon S2N, Google Libwebp, expat, libpng, SQLite, musl, libjpg, libsodium, LibreSSL, tiny ssh, libxml, zlib, ntpd, libbzip2, dpdk, nova, libksba
- 9. ©2018TrustInSoft 9 Examples: subtle bug in Google’s libwebp • Invalid pointer computation: invisible UB • Followed by invalid pointer comparison - result depends on memory layout - If the result is wrong, out-of-bound access occurs • LLVMASan statistically uses the memory layout without consequences • TrustInSoft Analyzer’s soundness means: all memory layouts are explored
- 10. ©2018TrustInSoft 10 Full Level 3 is reachable Proof of absence of UBs for some configurations of mbed TLS Read the full technical report at https: //trust-in-soft.com/polarssl-verification-kit/
- 11. ©2018TrustInSoft 11 Good news for cyber-security • These examples are the most difficult software to analyze - Huge legacy, multi-purpose code bases - No developer was involved in the analysis: only bug reports - Time to convince developers/maintainers that fixing issues is important • And still: it works! Security is improved: fewer bugs and unmodified dev. process • In the industry, this is much simpler!
- 12. ©2018TrustInSoft 12 Level 4 : Dataflowintegrity Example: look for the sources of randomnumbers in OpenSSL Explicit security property: Random generators seeds are acceptable - Customer knows what "acceptable" means - Tools can extract the origin of the data: sound means exhaustive Findings: a dozen of sources are used, including the private certificate Customer conclusion: we must configure the stack to avoid this Classical security analysis: define attack surfaces and implement proper mitigations This works onthesourcecode, if security expressed interms of programs behaviors
- 13. ©2018TrustInSoft 13 Level 5: full specifications for all functions Kind of a Grail for programcorrectness • We support this usage • Impacts the dev. Cycle: - Produce specifications - Check specifications àsoftware developed to make it provable maybe with dedicated languages/methodology • Adopted only for very specific parts of very specific safety/security critical software
- 14. ©2018TrustInSoft 14 Conclusion • Soundness of tools is a definitive improvement for security • Do not try to reach the highest integrity levels instantly • Stopping in the middle of any level is worth it àone reduces its hidden technical debt • Difference with unsound tools àeach step is a definitive improvement for security àWhen it is done, it is for real