2015 SOAAP

Security-Oriented Analysis of Application Programs (SOAAP)[^c1].

  • LLVM-based tool;
  • uses source code annotations for compartmentalization hypotheses.

Able to help with:

  • creating new compartmentalizations for complex applications;
  • discover design faults in existing compartmentalized applications.

Challenges

Reasoning about the compartmentalization tradeoffs is difficult:

  • Information about past vulnerabilities is not easily accessible;
  • Call graphs of compartmentalized applications are extremely complex;
  • Simple control-flow analysis cannot follow manually encoded cross-domain actions – such as those via IPC;
  • reasoning about information flow;
  • failures caused by compartmentalization are hard to debug and testing;
  • performance impacts are difficult to predict and control.

Identifying a spot in the compartmentalization space is difficult:

  • Knowing compartmentalization effects without implementation is difficult: performance, security.

This work:

  • a security profiling tool, e.g. help to determine whether a particular compartmentalization was ‘worth it’.
  • a security evaluation tool, e.g. ensure refactorings do not move vulnerable code to a more privileged context.

Contribution

  • framework: isolation + controlled communication; compart, spaces; design patterns;
  • SOAAP: LLVM-based tool; annotated compart. hypotheses;
  • Evaluation: OpenSSH, Chromium; fetch, Okular;

History of Compartmentalization

Karger 1: access control, trojan horse, capability systems;

Provos 2: OpenSSH; Kilpatrick 3: Chromium;

Compartmentalization threat model:

  • attackers gain total control of compromised compartments as a result of poorly crafted C code (or other program weaknesses) being exposed to malicious input;
  • ADDED: software supplychain vulnerabilities involving explicitly trojaned software without the need for malicious input – e.g., back doors.

Three Underpinnings

  • a strong TCB, able to protect compartmentalization itself;
  • compartment isolation (implemented by TCB), provides strong prevention of interference between isolated program instances;
  • controlled communication, allows safe communication between compartments – subject to suitable policies;

Isolation:

OS Process model + MMU; + access controls (chroot, Linux seccomp, SELinux, Mac OS X, Capsicum)

Workflow

Boundaries by annotation

Reusable/persistent sandbox:

__soaap_sandbox_persistent("dec2")
void dec2(int ifd, int ofd){
    // secret key
    char key[256];
    read_stdin("password", key);
    // ...
    char *tmp = tmp_file();
    int tfd = open(tmp, O_RDWR);
    // ...
    read(ifd, buffer, buffer_size);
    // ...
    if(l_flag){ // list contents
     // ...
    }else{
     // ... // decompress tmp to output file
    }
}

// + annotate to create compartment at the start of main(), via fork()

Data access analysis

Sandbox access global variables -> report to human

to allow, use __soaap_var_read("dec2") iint l_flag = 0;

  • data consistency bug can be discovered. (such as l_flag being written after compartment is created.)

Information leak detection

Annotate the private information:

char key[256] __soaap_private;

SOAAP will detect if this can leak from any external library functions.

Discover privilege usage

use platform descriptors to reason about sandbox restrictions.

  • chroot() –> allow all system calls

  • seccomp –> only read(), write(), sigreturn(), exit();

  • file descriptors –> Capsicum enforce capability on them;

SOAAP able to model Capsicum behavior.

use __soaap_fd_permit(read) to annotate the file descriptor to grant read permission.

Incoperate known vulnerabilities

Annotate the known CVE, SOAAP will evaluate the security risk (privileges being held by attackers) if got exploited.

__soaap_vuln_pt(“CVE-xxx-xxxx”)

Data flow analysis

may, must, flow sensitive, flow insensitive. different precisions.

tracking sensitive data/file descriptors: define-use chains.

Sandbox sensitive: data-flow within sandbox and between sandbox are distinguished, even if they contain overlapping code.

Function call target: function pointers, polymorphism, in C/C++. Infer targets by tracking assignments, also explicit annotate callees.

C++: AST & vtable in IR –> class hierarchy analysis (CHA) –> targets of virtual method call: all method definitions in the class hierachy rooted at the receiver object’s static type. (Receiver: callee object)

Evaluation

FreeBSD 10.1. Intel 4-core Xenon E5-1620 3.6GHz CPU, 64GB of RAM, 500GB SSD. Hyper-threading disabled. (?)

Use Capsicum as sandboxing platform.

  1. Fetch in two parts: URL/HTTP header parsing; TLS via OpenSSL.

    • URL parsing. Annotate fetchParseURL() with __soaap_sandbox_persistent; password filed in url struct with __soaap_classify.

    • Networking

    • code: fetch_c

    • code: libfetch_c

  2. Okular: 80KLoC separated + 4MLoC external libraries analyzed.

    • modular structure with rendering plugins (renders) for each doc format;
    • plugin interface as compartment boundary;
    • code on [github]()

  3. OpenSSH: maintance is hard for the style of separation in OpenSSH

  4. Chromium: scalability of SOAAP is good.

least privilege, Saltzer and Schroeder’s 1975 article, The Protection of Information in Computer Systems[^c38saltzer].

privilege separation. Trojan horse mitigation 1, Karger’s 1987 article. lays the conceptual groundwork for privilege separation.

OpenSSH2, Kilpatrick’s Privman3

User-level application compartmentalization in Java 4, Chromium 5, Capsicum6. Focus on intra-application security concerns rather than system privileges.

Interfaces between separated components. Cryptographic security APIs7,

compositional vulnerabilities among server and client sides of OpenSSL and JSSE. Beurdouche et al. 8

Assisted compartmentalization

Privtrans9, code oriented view, program annotation, dividing operation between privileged and unprivileged.

Wedge10, programmer provided memory type information.

Harris et al.’s secure programming by parity games 11 reasons about the defense characteristics of Capsicum compartmentalization, representing policies as automata.

programs in modern browser architectures. In EuroSys ’09: Proceedings of the 4th ACM European Conference on Computer Systems (2009), ACM.

and Schemers, R. Going beyond the sandbox: An overview of the new security architecture in the Java Development Kit 1.2. In Proceedings of the Symposium on Internet Technologies and Systems (1997), USENIX.

  1. Karger, P. A. Limiting the damage potential of discretionary trojan horses. In Proceedings of the IEEE Symposium on Security and Privacy (1987), IEEE. ↩
  2. Provos, N., Friedl, M., and Honeyman, P. Preventing privilege escalation. In Proceedings of the 12th USENIX Security Symposium (2003), USENIX. ↩
  3. Kilpatrick, D. Privman: A Library for Partitioning Applications. In Proceedings of USENIX Annual Technical Conference (2003), USENIX. ↩
  4. Gong, L., Mueller, M., Prafullchandra, H., ↩
  5. Reis, C., and Gribble, S. D. Isolating web ↩
  6. Watson, R. N. M., Anderson, J., Laurie, B., and Kennaway, K. Capsicum: Practical capabilities for UNIX. In Proceedings of the 19th USENIX Security Symposium (2010), USENIX. ↩
  7. Anderson, R., Bond, M., Clulow, J., and Skorobogatov, S. Cryptographic processors-a survey. Proceedings of the IEEE 94, 2 (Feb 2006), 357–369. ↩
  8. Beurdouche, B., Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Kohlweiss, M., Pironti, A., Strub, P.-Y., and Zinzindohoue, J. K. A Messy State of the Union: Taming the Composite State Machines of TLS. In Proceedings of the IEEE Symposium on Security and Privacy (2015). ↩
  9. Brumley, D., and Song, D. Privtrans: automatically partitioning programs for privilege separation. Usenix SP, 2014. ↩
  10. Bittau, A., Marchenko, P., Handley, M., and Karp, B. Wedge: Splitting Applications into Reduced-Privilege Compartments. Usenix NSDI. 2008. ↩
  11. Harris, W. R., Farley, B., Jha, S., and Reps, T. Secure Programming as a Parity Game. Tech. Rep. 1694, University of Wisconsin Madison, July 2011. ↩
Created Jan 14, 2020 // Last Updated Jul 10, 2021

If you could revise
the fundmental principles of
computer system design
to improve security...

... what would you change?