ProactiveSecurityRoadmap1

Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2006-06-03 20:49:47 →
Size: 10108
Editor: c-68-33-112-13
Comment: Step 1
← Revision 2 as of 2006-06-03 20:57:42 → ⇥
Size: 10328
Editor: c-68-33-112-13
Comment: Patent expiring?
Deletions are marked like this. Additions are marked like this.
Line 108: Line 108:
  * The last patent appears to expire 20 June 2006, which is about 17 days from the time of this writing. I don't think we care anymore; but we should really take a closer look and make sure other patents don't exist.

Proactive Security Roadmap 1

Status

Introduction

Establish a first-step strategy for implementing proactive security features in Ubuntu.

Rationale

As stated in :UbuntuDownUnder/BOFs/ProactiveSecurityRoadmap, We want to reduce the risk of security holes in Ubuntu systems by reducing the number of potential attack vectors and find general solutions for preventing common classes of vulnerabilities. This confines the impact of actual vulnerabilities to a minimum.

Visuals: [http://img306.imageshack.us/img306/4461/basicexploitattacktree3hi.png Normal] vs. [http://img306.imageshack.us/img306/3024/protectedexploitattacktree7mg.png Protected] (protections: address randomization; position independent executables; memory protection policy; stack smash protector)

Scope and Use Cases

  • We will patch the Ubuntu kernel to provide enhanced control over address space layout randomization.
  • We will implement SELinux policy to supply enhanced enforcement of protections currently available to make reasonable security guarantees possible.
  • We will implement position independent executables to close a potential attack vector which would allow common attacks to evade address space layout randomization protection, which is also needed before reasonable security guarantees are possible.
  • We may implement heap base randomization by porting it from Fedora Core and RHEL, which is also needed to make reasonable security guarantees possible.

  • We will implement stack protection utilizing the facilities available in mainline gcc 4.1, including FORTIFY_SOURCE and the stack smash protector derived from ProPolice. This gives effective protection, but no real guarantees.

  • Users may find that some programs need fixes as a result of these protections, and so we will provide a method to disable SELinux policy at runtime. Policy updates can later be issued to adjust protections per-binary as a work-around until these programs are fixed.
  • Users may find some programs need fixes as a result of FORTIFY_SOURCE and the stack protector. This normally indicates a security hole or bug in these programs; but may indicate a bug in gcc. The only way to deal with this is to fix the bug or rebuild the program without the protection.

Implementation Plan

Data Preservation and Migration

Does not apply here.

Packages Affected

Kernel:

  • Add heap randomization as from Fedora Core/RHEL.
    • This can break some things. Notably, Emacs was reported to break on Fedora from this.
  • Patch the kernel for adjustable address space randomization

    • Adjustments would cause the area over which these segments are randomized to be of size PERIOD * 2^n, where PERIOD is 16 for the stack and 4096 for the heap and mmap() base.

      • Large order randomization as used in PaX could be activated this way.
      • Smaller order randomization could be used to avoid breakage without outright disabling entropy on fragile programs.
    • A patch should be sent to the linux kernel mailing list for inclusion.
    • This could be deployed without any real run-time changes and still allow developers to test high-order ASLR.
    • Initial knobs can be system-wide via kernel command line parameters

      • heap-rand=n: Give n bits of randomization for the heap.

      • stack-rand=n: Give n bits of randomization for the stack.

      • mmap-rand=n: Give n bits of randomization for the stack.

    • Future control knobs would include per-architecture entropy and per-policy through SELinux.

SELinux Policy:

  • Hide memory addresses from map files
    • This prevents information leakage about other tasks' memory space layout, which would otherwise be useful to local attackers for nullifying the protections given by address space layout randomization

    • Probably can show these if the process reading is owned by current->euid (AND in the same SELinux security context?), since the process will have the same privileges anyway.

    • We can gain the same effect by hiding other users' (and contexts?) process directories from /proc.

  • Employ a strict memory protection policy across the system.
    • execstack: Prevent processes from making their stack executable.
    • execheap: Prevent processes from making their heap executable.
    • execmem: Prevent processes from making anonymous mappings, shared memory, and writable file mappings executable.
    • execmod: Prevent processes from making the .text segments from libraries and the main executable writable. This applies as a file permission; the others are per executable process.
  • Disable problematic protections only for the specific packages which they affect.

gcc:

  • Activate FORTIFY_SOURCE and -fstack-protector to provide stack smash protection to all code.
  • Activate PIE compilation for all binaries
    • Incurs approximately 6% performance overhead in the main executable on i386
      • 0.99% overhead from PIC (position independent code, the type used in position independent executables)
      • -fomit-frame-pointer gives a 5% performance increase; this is lost in any PIC
    • Overhead on other platforms is negligible, i.e. 0.02% on x86-64
    • Performance overhead only affects run time in the main executable

      • Profiling via oprofile shows this accounts for 5-10% of code run on the system ever (mostly Xorg), so overall real overhead is 0.3-0.6%

      • Profiling of individual processes needs to be done to get a better view.
      • Most heavy lifting such as encoding/decoding audio/video, compression/decompression, and screen painting happens in libraries anyway, which are not affected by PIE
  • Disable these protections in specific cases
    • Some packages break with PIE or SSP or FORTIFY_SOURCE
    • Any breakage due to PIE needs to be reported to package upstream
    • Any breakage due to SSP or FORTIFY_SOURCE needs to be examined
      • May indicate a security hole or bug in the package, which needs to be reported upstream and fixed
      • May indicate a bug in gcc, which needs to be reported upstream; work-around by disabling the protection for affected packages

Outstanding Issues

  • Brute forcing ASLR is possible for fast-respawning daemons or fork()ing daemons like Apache.
    • Brute forcing relies on doing hundreds or thousands of attacks per second.
    • Wide distributions of attacks also suffer from this.
      • If it takes 256 tries to exploit i.e. a Gaim bug, and 1024 users are running Gaim and get attacked once, 4 will be exploited.
    • There are some potential ways to deal with this, which should be researched and developed in the future.
  • Low vs High entropy address randomization is a heavily debated topic, and implementation may be subject to politics.
    • High entropy on i386 and other 32-bit tends to break a few things that try to mmap() 2 gig ranges in one big chunk etc.

    • Low entropy is easily brute forcable, but [http://www.stanford.edu/~blp/papers/asrandom.pdf so is our best bet on i386].

  • We want to support SELinux out of the box.

    • There is a [wiki:SELinux separate BoF] about this topic. It should be noticed that Secure Computing recently reaffirmed his patent right on SELinux "Type Enforcement" technology. They allow to use SELinux freely on anything but firewalls, vpn and authentification servers etc. See [http://www.securecomputing.com/pdf/Statement_of_Assurance.pdf SSC Statement of assurance] and [http://lwn.net/Articles/6267/ LWN article]. What's our position in regard to this patent ?

    • The last patent appears to expire 20 June 2006, which is about 17 days from the time of this writing. I don't think we care anymore; but we should really take a closer look and make sure other patents don't exist.

    • We should later evaluate RSBAC or GRsecurity as potentials SELinux alternatives for ACL. See. [http://gentoo-wiki.com/Access_Control_Comparison_Table Gentoo's ACL Comparison Table]

  • The SELinux memory protections are going to break a few packages, and these need to disable those protections for themselves.
    • Java
    • Mono
    • Qemu
    • All 3D apps if the nVidia GLX library is being used
      • We should put 3D apps in their own role and disable these SELinux protections by default for it
      • Users should be able to quickly enable the protections if they are using a Mesa/DRI driver; Fedora Core 5 has a tool for quick configuration of SELinux policy by checking/unchecking policy rules.
  • The SELinux memory protections rely on a working NX bit, which is not available on most i386.
    • The NX bit emulation from Exec Shield could be ported; but it will only protect the stack, and can not be guaranteed to stay in effect due to design limitations.
    • i386 with an NX bit--including newer processors and i386 on x86-64--has a real NX bit that is put to use.
  • We can diagram protections logically, mathematically, and graphically to show whether or not they give security guarantees and what those guarantees are; however, we probably do not want to commit ourselves to those guarantees, at least not without waiting a few years for all of the experts to give their comments on it.

Comments

JohnMoser: GrSecurity has a rudimentary but good brute force deterrance scheme, which makes fork() enter a queue that gets one execution per 30 seconds when called if a PaX kill or segmentation fault is encountered in a child fork() process with the same executable image. This causes one fork() to occur every 30 seconds. As expected, this is a hugely visible denial-of-service attack; but hey, we're making broken code safe, it's not going to be pretty so don't try. Obviously this DoS can only occur if an already existing security hole is attacked, so clean programs are unaffected. It may be possible to devise a less intrusive model that is almost as effective.

ProactiveSecurityRoadmap1 (last edited 2008-08-06 16:27:51 by localhost)