Outline Transient execution covert channels (contd) OS trust and - PDF document

Outline Transient execution covert channels (cont’d) OS trust and assurance CSci 5271 Introduction to Computer Security Announcements intermission Transient Execution, OS Assurance, and Networks Brief introduction to networking Stephen McCamant University of Minnesota, Computer Science & Engineering Some classic network attacks Second half of course Outline Trusted and trustworthy Transient execution covert channels (cont’d) Part of your system is trusted if its failure can break OS trust and assurance your security Announcements intermission Thus, OS is almost always trusted Brief introduction to networking Real question: is it trustworthy? Distinction not universally observed: trusted boot, Some classic network attacks Trusted Solaris, etc. Second half of course Trusted (I/O) path Minimizing trust How do you know you’re talking to the right Kernel ✦ microkernel ✦ nanokernel software? Reference monitor concept And no one is sniffing the data? TCB size: measured relative to a policy goal Example: Trojan login screen Reference monitor ✒ TCB Or worse: unlock screensaver with root password But hard to build monitor for all goals Origin of “Press Ctrl-Alt-Del to log in” How to gain assurance Evaluation / certification Testing and review performed by an independent Use for a long time party Testing Goal: separate incentives, separate accountability Code / design review Compare with financial auditing Third-party certification Watch out for: form over substance, misplaced Formal methods / proof incentives

Orange book OS evaluation Common Criteria Trusted Computer System Evaluation Criteria International standard and agreement for IT security certification D. Minimal protection C. Discretionary protection Certification against a protection profile , and C2 adds, e.g., secure audit over C1 evaluation assurance level EAL 1-7 B. Mandatory protection Evaluation performed by non-government labs B1 ❁ B2 ❁ B3: stricter classic MLS Up to EAL 4 automatically cross-recognized A. Verified protection Common Criteria, Anderson’s view Formal methods and proof Many profiles don’t specify the right things Can math come to the rescue? OSes evaluated only in unrealistic environments Checking design vs. implementation E.g., unpatched Windows XP with no network attacks Automation possible only with other tradeoffs “Corruption, Manipulation, and Inertia” E.g., bounded size model Pernicious innovation: evaluation paid for by vendor Starting to become possible: machine-checked proof Labs beholden to national security apparatus Proof and complexity Some hopeful proof results Formal proof is only feasible for programs that are seL4 microkernel (SOSP’09 and ongoing) small and elegant 7.5 kL C, 200 kL proof, 160 bugs fixed, 25 person years If you honestly care about assurance, you want your CompCert C-subset compiler (PLDI’06 and ongoing) TCB small and elegant anyway RockSalt SFI verifier (PLDI’12) Should provability further guide design? Outline Common Criteria question What’s “common” about the Common Criteria? Transient execution covert channels (cont’d) A. Every kind of product is evaluated against the same “protection OS trust and assurance profile.” B. Anyone can perform the certification, without special government Announcements intermission approval. C. The certification applies to devices used in everyday civilian life, Brief introduction to networking rather than in government or the military. D. A single certification is recognized by the governments of many Some classic network attacks countries. Second half of course E. A single certification can be used for products from different vendors.

Midterm exam Monday Outline Transient execution covert channels (cont’d) Arrive slightly early to start exam promptly at 1pm OS trust and assurance Erasable writing instrument recommended Announcements intermission E.g., mechanical pencil with separate eraser Brief introduction to networking Open book, notes, printouts, but no electronics Some classic network attacks Rest of today’s material is not covered Second half of course The Internet Layered model (OSI) 7. Application (HTTP) A bunch of computer networks voluntarily 6. Presentation (MIME?) interconnected 5. Session (SSL?) Capitalized because there’s really only one 4. Transport (TCP) No centralized network-level management 3. Network (IP) But technical collaboration, DNS, etc. 2. Data-link (PPP) 1. Physical (10BASE-T) Layered model: TCP/IP Packet wrapping IP(v4) addressing IP and ICMP Interfaces (hosts or routers) identified by 32-bit Internet Protocol (IP) forwards individual packets addresses Packets have source and destination addresses, Written as four decimal bytes, e.g. 192.168.10.2 other options First ❦ bits identify network, ✸✷ ✲ ❦ host within Automatic fragmentation (usually avoided) network ICMP (I Control Message P) adds errors, ping Can’t (anymore) tell ❦ from the bits packets, etc. We’ll run out any year now

UDP TCP User Datagram Protocol: thin wrapper around IP Transmission Control Protocol: provides reliable bidirectional stream abstraction Adds source and destination port numbers (each 16-bit) Packets have sequence numbers, acknowledged in order Still connectionless, unreliable OK for some small messages Missed packets resent later Flow and congestion control Routing Where do I send this packet next? Flow control: match speed to slowest link Table from address ranges to next hops “Window” limits number of packets sent but not ACKed Core Internet routers need big tables Congestion control: avoid traffic jams Maintained by complex, insecure, cooperative Lost packets signal congestion protocols Additive increase, multiplicative decrease of rate Internet-level algorithm: BGP (Border Gateway Protocol) Below IP: ARP DNS Address Resolution Protocol maps IP addresses to Domain Name System: map more memorable and lower-level address stable string names to IP addresses E.g., 48-bit Ethernet MAC address Hierarchically administered namespace Based on local-network broadcast packets Like Unix paths, but backwards Complex Ethernets also need their own routing (but ✳❡❞✉ server delegates to ✳✉♠♥✳❡❞✉ server, etc. called switches) DNS caching and reverse DNS Classic application: remote login Killer app of early Internet: access supercomputers To be practical, DNS requires caching at another university Of positive and negative results Telnet: works cross-OS But, cache lifetime limited for freshness Send character stream, run regular login program Also, reverse IP to name mapping rlogin: BSD Unix Based on special top-level domain, IP address written Can authenticate based on trusting computer connection backwards comes from (Also rsh, rcp)

Outline Packet sniffing Transient execution covert channels (cont’d) OS trust and assurance Watch other people’s traffic as it goes by on network Easiest on: Announcements intermission Old-style broadcast (thin, “hub”) Ethernet Brief introduction to networking Wireless Or if you own the router Some classic network attacks Second half of course Forging packet sources TCP spoofing Forging source address only lets you talk, not listen Source IP address not involved in routing, often not Old attack: wait until connection established, then checked DoS one participant and send packets in their place Change it to something else! Frustrated by making TCP initial sequence numbers Might already be enough to fool a naive UDP unpredictable protocol But see Oakland’12, WOOT’12 for fancier attacks, keyword “off-path” ARP spoofing rlogin and reverse DNS rlogin uses reverse DNS to see if originating host is on whitelist Impersonate other hosts on local network level How can you attack this mechanism with an honest Typical ARP implementations stateless, don’t mind source IP address? changes Now you get victim’s traffic, can read, modify, resend rlogin and reverse DNS Outline Transient execution covert channels (cont’d) rlogin uses reverse DNS to see if originating host is OS trust and assurance on whitelist How can you attack this mechanism with an honest Announcements intermission source IP address? Brief introduction to networking Remember, ownership of reverse-DNS is by IP Some classic network attacks address Second half of course