The impact of programming language theory on computer security
Download
1 / 22

The Impact of Programming Language Theory on Computer Security - PowerPoint PPT Presentation


  • 87 Views
  • Uploaded on

The Impact of Programming Language Theory on Computer Security. Drew Dean Computer Science Laboratory SRI International. What I’m not Talking About. Cryptographic Protocol Verification See, e.g., Computer Security Foundations Workshop Type Systems for Non-Interference See, e.g., POPL.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' The Impact of Programming Language Theory on Computer Security' - mills


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
The impact of programming language theory on computer security

The Impact of Programming Language Theory on Computer Security

Drew Dean

Computer Science Laboratory

SRI International


What i m not talking about
What I’m not Talking About Security

  • Cryptographic Protocol Verification

    • See, e.g., Computer Security Foundations Workshop

  • Type Systems for Non-Interference

    • See, e.g., POPL


Much of security is
Much of security is: Security

  • “Program P exactly implements Specification S and no more.”

  • For this talk, we assume that the specification is correct


Security tripos
Security Tripos Security

Correctness

wrt critical

requirements

No undefined user

mode behavior

Proper system call use


Correctness wrt security
Correctness wrt Security Security

  • No system that misses security checks can be secure

    • Program Verification

    • Architectural Support

      • Stack inspection

      • Security Passing Style [WAF]


Program verification
Program Verification Security

  • Obvious connections

    • Lambda calculus, Curry-Howard

    • Hoare Logic


Architectural support
Architectural Support Security

  • Stack Inspection

    • Access control based on endorsement of code: answers “Who called me?”

    • Designed to prevent untrusted code from bypassing access controls, while allowing higher level code to assert that it knows what it’s doing


Stack inspection example
Stack Inspection Example Security

  • Applet wants to use the Helvetica font

  • May require JVM to read a file

  • Solution:

    • Font handling code checks arguments

    • If successful, asserts privilege

    • Attempts to read file

      • Which notes that font code (privileged) has asserted everything’s OK


Stack inspection critique
Stack Inspection: Critique Security

  • Exposes call stack

    • Tail call elimination painful

    • Function inlining also painful

    • Goodbye, Church-Rosser, goodbye!


Security passing style
Security Passing Style Security

  • Wallach, Appel, Felten, TOSEM 9/00

  • A la CPS, pass security context as an extra (implicit) argument

  • Restores tail call elimination and function inlining

  • Doesn’t restore Church-Rosser


Observation
Observation Security

  • SPS is in closer analogy to CPS than its authors say

  • Shivers: “Threads are paths through continuation space”

  • Continuations are the right semantic object to attach permissions to

  • Would a dependent type system work out?


Properly using system calls
Properly Using System Calls Security

  • If a program handles its own security, e.g., ftpd, it better use system calls correctly

  • Many programs don’t

    • Wu-ftpd

    • Sendmail


How can plt help
How Can PLT help? Security

  • Joint work with David Wagner and Hao Chen, UC Berkeley

  • Given a program, morph control flow graph into an automaton that accepts language of system calls


Ieee s p 2001
IEEE S&P 2001 Security

  • Take automaton, check runtime trace of system calls for anomaly detection

  • (Most of) Benefits of specification-based intrusion detection without needing the non-existent spec


Current work
Current Work Security

  • Take abstracted specification, throw it and library of security “best practices” (and known attacks) at (custom) model checker

  • But this requires understanding system calls

  • Usually the POSIX spec is reasonable

  • But not for set*uid()


Understanding set uid
Understanding set*uid Security

  • Absolutely necessary for writing secure setuid Unix programs

  • Linux, FreeBSD, Solaris all subtly different

    • Even if all POSIX compliant

  • Kernel code unreadable

  • Reverse engineer formal model

  • Will appear at USENIX Security 2002


No undefined user mode behavior
No Undefined User-mode Behavior Security

  • Buffer overflows are still a problem in 2002

  • PL people think this is stupid

    • It is

  • Like it or not, most of the world codes in C or unsafe C++


Not just buffer overflows
Not Just Buffer Overflows Security

  • Any corruption of program state can cause vulnerability

    • Nearly science fiction attack based on a C program double freeing a pointer


Observation1
Observation Security

  • Memory comes in two colors

    • Storage of variables

    • Compiler/runtime support


Partition property
Partition Property Security

  • “All variables only refer to memory locations that the compiler has mapped to program variables, not compiler/runtime support (e.g., return addresses, temporaries for evaluating expressions, memory management overhead, etc.)”


Partition properties
Partition Properties Security

  • Note that this is weaker than non-interference

    • Values obviously depend on program values

  • Stronger than some forms of memory & type safety

  • Should be a theorem of modern (safe) languages


Conclusions
Conclusions Security

  • This was a brief survey of a wide field

  • “and no more” is hard to implement

  • Hopefully, breaking it down helps

Correctness

wrt critical

requirements

No undefined behavior

Proper system call use


ad