1 / 36

Satisfiability Modulo Theories and Network Verification

Satisfiability Modulo Theories and Network Verification. Nikolaj Bjørner Microsoft Research Formal Methods and Networks Summer School Ithaca, June 10-14 2013. Lectures. Wednesday 2:00pm-2:45pm : An Introduction to SMT with Z3 Thursday 11:00am-11:45am Algorithmic principles of SAT/SMT

kevork
Télécharger la présentation

Satisfiability Modulo Theories and Network Verification

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Satisfiability Modulo Theoriesand Network Verification Nikolaj Bjørner Microsoft Research Formal Methods and Networks Summer School Ithaca, June 10-14 2013

  2. Lectures Wednesday2:00pm-2:45pm: An Introduction to SMT with Z3 Thursday 11:00am-11:45am Algorithmic principles ofSAT/SMT Friday9:00am-9:45am Theories, Solvers and Applications

  3. source is (evil) subverting 8/

  4. is open shared source http://z3.codeplex.com/

  5. Z3 architecture - new Tactics SMT-LIB SMT (legacy core) Arrays Bit-Vectors Record & replay Lin-arithmetic Recursive Datatypes Free (uninterpreted) functions OCaml Quantifier instantiation And-then SAT core for Bit-vectors .NET Or-else R: Non-linear real arithmetic C Try-for Floating point arithmetic Java Par-or Horn clauses Python Par-then Simplification

  6. Some Microsoft Tools based on Testing Analysis Synthesis Program Verification Auditing Type Safety Over-Approximation Under-Approximation HAVOC BEK SLAyer SAGE

  7. Cool tools using Sledge Hammer ESBMC PUG ScalaZ3 MetiTarski KeYmaera Jeves

  8. Testing

  9. Hunting for Security Bugs Old introduction slide to SAGE & Pex State today: Pex is mature & Moles in VS2012 SAGE actively used internally at Microsoft • Two main techniques used by “black hats”: • Code inspection (of binaries) and Blackbox fuzz testing • Blackbox fuzz testing: • A form of blackbox random testing • Randomly fuzz (=modify) a well-formed input • Grammar-based fuzzing: rules that encode how to fuzz • Heavily used in security testing • At MS: various internal tools • Conceptually simple yet effective in practice… • Has been instrumental in weeding out 1000’s of bugs during development and test

  10. Method: Dynamic Test Generation Run program with random inputs. Gather constraints on inputs. Use constraint solver to generate new inputs. Combination with randomization: DART Godefroid-Klarlund-Sen-05,… • Input x, y • Z := x + y z == hash(x) • Return z • error(); Can’t statically generate value for x that satisfy “z==hash(x)” But we can solve for y in: x + y = hash(x)

  11. Fuzzing and Test Case Generation SAGE Internal. For Security Fuzzing Runs on x86 instructions External. For Developers Runs on .NET code Try it on: http://pex4fun.com Finding security bugs before the hackers black hat

  12. Fuzzing and Test Case Generation Dr. Strangelove? Bug: ***433 “2/29/2012 3:41 PM Edited by ***** SubStatus -> Local Fix I think the fuzzers are starting to become sentient. We must crush them before it is too late. In this case, the fuzzer figured out that if [X was between A and B then Y would get set to Z triggering U and V to happen……] ….. And if this fuzzer asks for the nuclear launch codes, don’t tell it what they are …” SAGE Internal. For Security Fuzzing Runs on x86 instructions External. For Developers Runs on .NET code Try it on: http://pex4fun.com Finding security bugs before the hackers black hat

  13. SAGE by numbers 100s CPU-years - largest dedicated fuzz lab in the world 100s apps - fuzzed using SAGE 100s previously unknown bugs found Billion+ computers updated with bug fixes Millions of $ saved for Users and Microsoft 10s of related tools (incl. Pex), 100s DART citations 3+ Billion constraints - largest usage for any SMT solver Adapted from [Patrice Godefroid, ISSTA 2010]

  14. VerificationIt is cooleasyfunattractive Program Verification Auditing Type Safety HAVOC SLAyer

  15. Building Verve Kernel.cs Source file Verification tool Compilation tool C# compiler Verified Nucleus.bpl (x86) Kernel.obj (x86) 9 person-months Boogie/Z3 TAL checker Translator/ Assembler Linker/ISO generator Verve.iso Safe to the Last Instruction / Jean Yang & Chris Hawbliztl PLDI 2010

  16. Validation SecGuru: Automatic Validation of Network Connectivity Restrictions Karthick Jayaraman, Charlie Kaufman, and RamanathanVenkatapathy Nikolaj Bjørner

  17. Network Policies: Complexity, Challenge and Opportunity Human errors > 4 x DOS attacks Several devices, vendors, formats • Net filters • Firewalls • Routers Challenge in the field • Do devices enforce policy? • Ripple effect of policy changes Arcane • Low-level configuration files • Mostly manual effort • Kept working by “Masters of Complexity”

  18. A Data-center Architecture Policy Policy Policy Policy Policy Policy Policy Policy

  19. A Data-center Architecture Defense in Depth = Crypto + Policies - outside IP can be spoofed Efficient and Flexible Defense by Policy only - inside IP cannot be spoofed Policy Policy Policy Policies (Access Control Lists) matter Policy Policy Policy Policy Policy

  20. Network PoliciesWhat they look like in routers Defense in Depth = Crypto + Policies - outside IP can be spoofed Efficient and Flexible Defense by Policy only - inside IP cannot be spoofed Policy Policy Policy Policy Policy Policy Policy Policy

  21. A Need for Automating Policy Configuration Constantly growing New clusters – “same” policy, but different addresses Constantly changing Hardware – capacity, semanticsNew Services – selectivelyexposedPatches – to live site incidents Bare metallow-level format of routers are also used for policy configurations

  22. Towards automation:Checking Policy Configuration with SecGuru Constantly growing New clusters – enforce and check that new policies are instances of a master template (the intent) Constantly changing Hardware – capacity, semanticsNew Services – check effect of new rules Patches – check for regressions

  23. Towards automation:Checking Policy Configuration with SecGuru Enforce and check that policies are instances of a master template (the intent) Rules<X> X := A Rules<A> Rules on Router

  24. Towards automation:Checking Policy Configuration with SecGuru Enforce and check that policies satisfy contracts Rules<X> X := A Rules<A> X := A Does policy satisfy contracts? Contracts<X> Contracts<A> X := A

  25. Policies as Bit-Vector Formulas IP, Port, and Protocol: bit vectors Policy: Bit-vector logic

  26. Policies as Bit-Vector Formulas IP, Port, and Protocol: bit vectors Policy: Bit-vector logic

  27. Two uses of SecGuru

  28. Two uses of SecGuru

  29. Two uses of SecGuru Semantic diff between policies • Is If not, print • Traffic accepted by , but not . Models for • Traffic accepted by , but not . • Models for

  30. Two uses of SecGuru Semantic diff between policies

  31. All-BVSAT: A compact model enumeration Really naïve model enumeration: • To generate the model, negate all the models seen so far • … models Smarter model enumeration in SecGuru using All-BVSAT (idea): • Find initial • Maximize bounds : • Maximize next bounds:

  32. All-BVSAT: A compact model enumeration Maximize bounds: Result is a cube: dstIp srcPort srcIp

  33. All-BVSAT: A compact model enumeration More succinct: Maximize multiplebounds Result is a multi-cube: dstIp dstIp srcPort srcIp srcIp

  34. Long ago in a network far away, the rebel Hassel forces began to claim that networking was a separate planet and required separate verification engines . . . Early attempts to colonize networking using weapons from the Verification Empire such as Datalog, Bounded Model Checking, and SAT solvers resulted in these weapons blowing up... All this, till a few soldiers in the Imperial Army took aim at the problem...

  35. Do old-school tools apply to Network Verification? • Experiments by Nuno Lopes, March-May 2013 • Queries over Stanford Network + Extensions • Observation: Datalog is OK to express network queries. • Query tools tried out. • Datalog + Hassel algebra • PDR engine • Hardware model checkers (ABC, IIMC, IC3) • Bounded model checking. Two encodings. • Symbolic simulation Very preliminary finding: PDR ~ Hassel, others work on small (Stanford) network. Hardware tools chocked.

  36. Summary An Introduction to SMT with Z3 Algorithmic principles ofSAT/SMT Theories, Solvers and Applications

More Related