[ale] Linux: Secure and Limits? - somewhat off topic

[Jacob Langseth]

Frank Zamenski scribed:
> for also having a low aptitude for). What are 'buffer overflows' and how are
> these exploited? Not looking to cause mischief, that's below my ethical

[ http://www.dfw.net/~aleph1/FAQ ]

                             BugTraq
                     Frequently Asked Questions
[...]

2.0 Application/Local Host Vulnerabilities

2.0 Buffer Overflows

2.0.0 What are buffer overflows?

  Buffer overflows have become the most common security vulnerability
  found in unix operating systems today. They are the results of the lack of
  a good string or buffer data type in C and the missused of the standard C
  library's string functions. It is obvious we have learned little from history.
  This is the same attack method used by the Internet Worm ten years ago to
  infect machines via fingerd.

  The most common type of buffer overflow is a stack buffer overflow. A stack
  buffer overflow exploit attempts to overflow the buffer of a privileged
  program to inject his machine code into the program's address space and
  overwrite the return address on the stack of some function. When this
  function returns it will jump to the intruder's code.

  The are also data buffer overflows in which the attacker instead of
  overwriting some funciton return address is modifies some data structure
  in the hopes to modify the priveleged program's behavior.

2.0.1 How to I stop buffer overflow attacks?

  The have been a large number of proposed solutions to fix buffer overflows.

    - Fix the offending code. Do not write code with buffer overflows.

      Pros: The obvious and correct solution. It fixes all stack and data
      buffer overflows.

      Cons: It may not be always possible to fix the problem (binary only
      programs). It might not be possible to audit the code (time or
      resource constraints). The code audit may miss some problems.
      Programmers will make mistakes.


      The are runtime debugging tools that can assist you in detecting some
      buffer overflows and other memory management related problems. For 
      example:

        * Purify (commercial)
          < http://www.pureatria.com/products/purify/ >
        * ElectricFence

      The are static source code analysis tools that can assist you in
      detecting security vulnerabilities. For example:

        * SLINT (commercial)
          < http://www.l0pht.com/slint.html >

    - Write programs in a language that supports bounds checking (in other
      words not C). This is a rather religous issue. These are some of the 
      arguments against using other languages and their rebutal:

      * You can write secure programs in any language (including C).
        You can write insecure programs in any language (including C).

        True, but event the best programmers make mistakes and most of
        the software you will want/need to run will not be writen by the
        best programmers.

      * The are security vulnerabilities other than buffer overflows (which
        also affect bounds checking compilers/languages).

        True, but we must fix vulnerabilities one at a time. Buffer overflows
        compose the largest segment of security vulnerabilities reported today.
        They are the best place to start.

      * Other languages have security vulnerabilities that C does not.

        True. For example initialization of global constructors in a 
        privileged state om object oriented languages. You should weight
        the risks of each language and select the appropiate one.

      * Other alternatives are not as fast as C.

        You should values security over performance. Not all applications
        are performance sensitive. Processor performance has been increasing
        at an exponential rate for years. Compilers for bounds checking
        languages can usually optimize bounds checks as well as make use
        of hardware bound checking features.

        This arguments is also used against C compilers that generate
        bounds checking code.

      * The are no good open source alternatives.

        This is indeed a problem although the are some alternatives.
        For example the GNAT Ada 95 compiler and the Kaffe Java JIT
        compiler.

      * The are not many libraries available for other languages.

        This is also a problem. Such libraries would have to be
        developed for other languages or bindings into the C libraries
        would have to be made. Of curse this last options is just adds
        a wrapper around possibly unsecure code. Then again any new
        libraries would not be as mature and will likely contain their
        own security problems. Catch 22.

      * You should audit the code instead of changing the language.

        See the cons about fixing and auditing code above.

      * Requires recoding all privileged programs.

  - Use a C compiler that supports bounds checking.

    Pros: This solution stops all stack and data buffer overflows.

    Cons: Only a couple of rough patches for GCC are known to support
    this feature. The patches are not being maintained and they are known
    to impose a very high performance penalty to programs compiled using
    them. Requires recompiling.

    < http://www-dse.doc.ic.ac.uk/~rj3/bounds-checking.html >
    < http://fox.doc.ic.ac.uk/~phjk/BoundsChecking.html >
    < ftp://dse.doc.ic.ac.uk/pub/misc/bcc >

  - Mark the stack non-executable. The most common stack buffer overlow
    exploits place code on the stack to be executed. By marking the
    stack non-executable we stop the execution of this code.

    Pros: Marking the stack non-executable is supported under most 
    architectures. Only requires kernel support. Stops stack overflows 
    exploits that place the code to execute on the stack. Does not
    require recompiling.

    Cons: It may break some software that places code on the stack.
    Does not stop data overflow exploits or stack overflow exploits that
    execute code in segments other than the stack.

    Linux:

      To mark the stack as non-executable apply the patch at
      < http://www.false.com/security/linux-stack/ > and recompile
      the kernel with the option CONFIG_SECURE_STACK  turned on.

    Solaris:

      To mark the stack non-executable on SPARCs (non-sun4/sun4c) under
      versions of Solaris earlier than 2.6 use the script in appendix A.

      Under Solaris 2.6 and later running on sun4m, sun4d or sun4u machines
      add this line to /etc/system and reboot:

        * Turn off executable stack
        set noexec_user_stack=1

        * Log attempted exploits
        set noexec_user_stack_log=1

  - Verify the stack integrity during function return. By placing randimly
    generated guard numbers around the return address during a function
    call we can verify they have no changed during function return.

    Pros: Only requires changes to the compiler or changes to the source
    to check the stack frame before each return. Stops all stack buffer
    overflow exploits. Programs are binary compatible with  non-protected
    libraries.

    Cons: Does not address data buffer overflows exploits. Requires 
    recompiling.

    This is technique is used by StackGuard.
    < http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ >

    Similarly, Alexandre Snarskii created patches for FreeBSD's libc to
    check the integrity of the stack during certain buffer overflow prone
    library calls.
    < ftp://ftp.lucky.net/pub/unix/local/libc-letter >

  - Use two separate stacks. One for local variables and one for return 
    addresses. Stack buffer overflow exploits overwrite the return address
    by writing past the end of a buffer on the same stack as it. By placing
    the return address on a separate stack they can no longer overwrite it.

    Pros: Stops stack based buffer overflow exploits.

    Cons: Requires both compiler and kernel support. It breaks binary
    compatability with existing libraries. Does not address data buffer
    overflow exploits. Requires recompiling.

    This is the technique used by a patch for egcs developed by Serge Orlov
    <sorlov at con.mcst.ru>.
    < http://www.ipmce.su/~sorlov/security.html >

  - Allocate local variables on the heap. Stack overflow exploits overwrite
    the return address by writing past the end of a buffer on the same
    stack as it. By placing the local variables on the heap the exploit
    can no longer overwrite the return address.

    Pros: Stops stack based buffer overflow exploits. Only requires compiler
    support.

    Cons: It breaks binary compatability with existing libraries. It
    is very slow. Does not address data buffer overflow exploits. Requires
    recompiling.

  - Randomize the stack address. As part of a standard stack overflow the
    attacker must guess the address of the code to execute. The code is
    normally placed on the stack by the attacker via the same buffer
    he is overflowing to overwrite the return address. By randomizing the
    stack address during each execve the attacker no longer has good idea
    of where his code will be placed.

    Pros: Only requires kernel support. Does not require recompiling.

    Cons: Dos not address stack buffer overflow exploits that execute
    code not on the stack. Does not address data buffer overflow exploits.

    < http://www.greenend.org.uk/rjk/random-stack.text >

2.0.2 References

  "Buffer Overruns, whats the real story?" by Lefty
  < http://reality.sgi.com/nate/machines/security/stack.nfo.txt >

  "Compromised - Buffer - Overflows, from Intel to SPARC Version 8" by Mudge
  < http://www.l0pht.com/advisories/bufitos.pdf >
  < http://www.l0pht.com/advisories/buf.ps >
  
  "Defating Solar Designer's Non-executable Stack Path" by Rafal Wojtczuk
  BugTraq mailing list, 30 Jan 1998. 
  < http://www.geek-girl.com/bugtraq/1998_1/0153.html >

  "Getting around non-executable stack (and fix)" by Solar Designer
  BugTraq mailing list, 10 Aug 1997.
  < http://www.geek-girl.com/bugtraq/1997_3/0281.html >

  "Finding and Exploiting Programs with Buffer Overflows" bu Prym
  < http://reality.sgi.com/nate/machines/security/buffer.txt >

  "How to write Buffer Overflows" by Mudge
  < http://www.l0pht.com/advisories/bufero.html >

  "Multi-stack allocator: another way to prevent stack smashing attacks."
  BugTraq mailing list, 27 Oct 1998.
  < http://www.geek-girl.com/bugtraq/1998_4/0221.html > 

  "Smashing the Stack for Fun and Profit" by Aleph One
  Phrack Issue 49, File 14
  < http://www.fc.net/phrack/files/p49/p49-14 >

  "Stack Smashing Vulnerabilities in the UNIX Operating System" by Nate Smith
  < http://reality.sgi.com/nate/machines/security/nate-buffer.ps >

  "StackGuard: Automatic Adaptive Detection and Prevention of Buffer
   Overflow Attacks" by C. Cowan, C. Pu, D. Majer, H. Hilton, J. Walpole,
   P. Bakke, S. Beattie, A. Grier, P. Wagle, Q. Zhang
  < http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/usenixsc98_html/ >
  < http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/usenixsc98.ps.gz >

  "The Tao of Windows Buffer Overflows" by Dildog
  cDc File 351
  < http://www.cultdeadcow.com/cDc_files/cDc-351/ >

2.0.3 Misc

  It has also been noted that many hardware architectures support bounds
  checking in hardware but that these features are rarely used by software.
  Examples of hardware support is the segmented memory model and the Intel
  BOUND instruction.

>>>>