Presentation Transcript

1. Secure your native code Marc SchönefeldJava Vulnerability Team
2. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
3. Graphic Section Divider
4. Agenda JNI development The threat model Self-assessment Crash analysis Platform-specific mitigations
5. JNI development
6. Native Methods Leaving the wonderful world of Java ... Not all programming tasks (like hardware access) can be solved with using Java alone The Java Native Interface (JNI) allows integration of native code (ASM,C, C++) Native methods in a DLL are connected to a Java method definition with the native keyword Find more details about JNI: http://docs.oracle.com/javase/7/docs/technotes/guides/jni/
7. Security rule Nr. 1 for JNI If possible, avoid it ... Only use JNI when absolutely necessary Identify an alternative, implemented in 100% Java first Writing/deploying/maintaining native libraries burdens your entire development chain In terms of security, there is no implicit built-in safety (sandbox) Attackers like native code, because that is what they expect to fail first
8. JNI Development The workflow Java methods are defined and compiled Native headers are generated Native code is implemented and compiled/linked The native library is linked by the JVM during runtime
9. JNI Development publicclassCHelloWorld { static{ System.loadLibrary("hello"); } // static initializer publicnativevoidprintHelloWorld(); publicstaticnativevoidprintNative(String str); publicstaticvoid main(String[] a) { if(a.length>0) { printNative(a[0]); } else{ newCHelloWorld().printHelloWorld(); } } } // CHelloWorld Native language stubs are attributed with nativekeyword Implementation is provided in a native library Native library is linked with System.loadLibrary The Java Code
10. JNI Development /* DO NOT EDIT THIS FILE - it is machine generated */ #include <jni.h> /* Header for class CHelloWorld */ #ifndef _Included_CHelloWorld #define _Included_CHelloWorld #ifdef __cplusplus extern "C" { #endif /* Class: CHelloWorld * Method: printHelloWorld * Signature: ()V */ JNIEXPORT void JNICALL Java_CHelloWorld_printHelloWorld (JNIEnv *, jobject); /* Class: CHelloWorld * Method: printNative * Signature: (Ljava/lang/String;)V */ JNIEXPORT void JNICALL Java_CHelloWorld_printNative(JNIEnv *, jclass, jstring); #ifdef __cplusplus } #endif #endif JDK tool javah generates native prototypes from methods marked with nativekeyword jni.h contains the definitions required for JNI development Native prototype headers
11. JNI Development #include "CHelloWorld.h" #include <stdio.h> JNIEXPORT void JNICALL Java_CHelloWorld_printHelloWorld (JNIEnv *env, jobjectobj) { printf("Hello World\n"); } JNIEXPORT void JNICALL Java_CHelloWorld_printNative(JNIEnv * env, jclassjcl, jstringjavaString) { booleanisCopy; constchar *nativeString = (*env)->GetStringUTFChars(env,javaString, &isCopy); printf(isCopy==1?"1":"0"); printf("/"); printf(nativeString); printf("\n"); if (isCopy) { (*env)->ReleaseStringUTFChars(env, javaString,nativeString); } } JNI methods are implemented using generated prototypes JNICALL and JNIEXPORT are translated to the platform counterpart declarations Memory is explicitly allocated and released (Welcome to C) Native implementation
12. JNI Development Workflow Sample JNI Makefile JNI=/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/include/ JNIOSX=/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/include/darwin libhello.jnilib: printHelloWorld.cCHelloWorld.h cc -I${JNI} -I${JNIOSX} -shared -o libhello.jnilibprintHelloWorld.c CHelloWorld.h: CHelloWorld.class javah -verbose CHelloWorld CHelloWorld.class: CHelloWorld.java javac CHelloWorld.java
13. JNI threat model
14. Secure Coding Antipatterns C/C++ vs. Java C/C++ antipatterns enable memory exploits (heap & buffer overflows) Java runtime environment safely manages memory performs automatic checks on access within array bounds Has no explicit pointer arithmetic The Java runtime environment often executes untrusted code Must protect against access to unauthorized resources Results in a different set of coding antipatterns than C/C++ C/C++ antipatterns still relevant for JNIdevelopment
15. JNI Runtime Threat model Native function are capable of bypassing the Java security architecture. Action of native code is not checked against the security policy or visibility declarations For example it is possible that JNI-Code alters the values of normally immutable classes such as java.lang.Integer It can also be used to read and modify (e.g. private key data) from arbitrary private fields Native methods are prone to heap, buffer- and integer overflows
16. JNI Runtime Native vulnerabilities Vulnerability = bypass security checks enforced by the JRE Via JNI by exploiting a C/C++ related flaw Buffer overflow Stack buffer overflow/smashing Heap Corruption Double free Caused by Programming bug in native code, or Missing checks in the Java layer (instrumentation via parameter injection)
17. Securing JNI JNI coverage in Secure Coding Guidelines Java Secure Coding Guidelines Guideline 5-3: Define wrappers around native methods Guideline 9-9: Safely invoke standard APIs that perform tasks using the immediate caller's class loader instance (loadLibrary) CWE CWE-111: Direct Use of Unsafe JNI CERT SEC08-J. Define wrappers around native methods
18. Securing JNI How can JNI code be protected from the Java side? Java Secure Coding Guidelines to the rescue Do not pass native pointers back to the user, if necessary give out handles and manage them Avoid calling native API from deserialization Be prepare for multithreaded usage (avoid deadlocks and race conditions) Do not mutate immutable Java objects Wherever possible, check parameters on the Java side first
19. Guideline 5-3: Define wrappers around native methods Use proper checks (Risk of memory corruption) public class CRC32 { privatestaticnativeupdateBytes(int,byte[],int,int); public void update(byte[] b, int off, intlen) { if (b == null) { throw new NullPointerException(); } if (off<0 || len<0 || off+len>b.length) { thrownewArrayIndexOutOfBoundsException();} crc = updateBytes(crc, b, off, len); }
20. Guideline 5-3: Define wrappers around native methods Be careful, use proper checks (risk of memory corruption) CRC32 c = new java.util.zip.CRC32 (); c.update (new byte []{1,2,3} ,0 ,3); But also: c.update (new byte [0],4,Integer. MAX_VALUE-3);
21. Guideline 5-3: Define wrappers around native methods Be careful, use proper checks (risk of memory corruption) CRC32 c = new java.util.zip.CRC32 (); c.update (new byte []{1,2,3} ,0 ,3); But also: c.update (new byte [0],4,Integer. MAX_VALUE-3); An unexpected exception has been detected in native code outside the VM. Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0 x6D3220A4 Function= Java_java_util_zip_ZipEntry_initFields+0x288 Library=c:\java\1.4.1\01\jre\bin\zip.dll Current Java thread : at java.util.zip.CRC32.updateBytes(Native Method ) at java.util.zip.CRC32.update(CRC32.java:53) at CRCCrash.main(CRCCrash.java :3) [... lines omitted ...] Local Time = Mon Mar 17 14:57:47 2003 Elapsed Time = 3 # # The exception above was detected in native code outside the VM # # Java VM : Java HotSpot(TM ) Client VM (1.4.1_01 -b01 mixed mode) #
22. Guideline 5-3: Define wrappers around native methods Use proper checks (Risk of memory corruption) public class CRC32 { privatestaticnativeupdateBytes( int, byte[], int,int); public void update(byte[] b, int off, intlen) { if (b == null) {throw new NullPointerException(); } if (off<0 || len<0 || off>b.length-len) { thrownewArrayIndexOutOfBoundsException();} crc = updateBytes(crc, b, off, len); }
23. Guideline 9-9: Safely invoke loadLibrary Loading native libraries securely System.loadLibrary("/com/foo/MyLib.so") uses the immediate caller's class loader to find and load the specified library. (Loading libraries enables a caller to make native method invocations) Do not invoke this method on behalf of untrusted code, since untrusted code may not have the ability to load the same library using its own class loader instance. Do not invoke loadLibrary using inputs provided by untrusted code, and do not propagate objects that are returned by these methods back to untrusted code.
24. Native code and the security manager How to interact with the Java security model JNI can surpass security manager checks and perform actions forbidden by a policy Violate immutability Access to files, even if forbidden by the policy Opening sockets, even if forbidden by the policy and more Avoid putting loadLibrary in a privileged block This would allow untrusted callers to trigger native library initializations Instead require a policy with the loadLibrarypermission granted
25. Secure JNI: Isolation Keep native code minimal, simple, and isolated Native methods should be private Java wrappers should validate input Keep native pointers private Treat them as read-only within Java, do not pass them to the user Do not expose methods to the user that allocate or free memory
26. Secure JNI: Isolation Security vulnerability in Java Media Framework (2.1.1c)
27. Secure JNI: Isolation --- com_sun_xyz_NBA_211c_ 200x-05-18 22:04:30.000000000 +0200 +++ com_sun_xyz_NBA_211e_ 200x-05-18 22:03:42.000000000 +0200 @@ -1,8 +1,8 @@Compiled from "NBA.java" -public class com.sun.xyz.NBA extends java.lang.Object{ - public long data; - public int size;- public java.lang.Class type; +public final class com.sun.xyz.NBA extends java.lang.Object{ + private long data; + private int size; + private java.lang.Class type; private native void nDeallocate(long); private native void nCopyToNative(long, long, int);
28. Secure JNI: Input Validation Revalidate at language boundaries If possible, re-validate input on the native side Java types are signed: check for array indices < 0 “-Xcheck:jni” option can help catch issues Be careful of types passed to native code – they are all pointers of the same native type
29. Secure JNI: Exception / Error Checking Be prepared for failure, and let the code degrade gracefully Native code has no exception support Those must be checked for explicitly Calls to Java methods may return exceptions Be prepared to react to failing conditions Asynchronous exceptions, e.g., It is necessary to check for exceptions in long loops Error checking: GetFieldId() and others can return null Have a white list of conditions to react on
30. Secure JNI: Native Security Issues Avoid violating Java access control rules, e.g., private, final Avoid violating the security model: native side does not enforce access control (e.g. package.access) All standard C/C++ security issues apply Take care with user supplied data (e.g., arguments, files, images) Terminating Unicode strings: Windows expects double 0 marker
31. Secure JNI: Avoid Denial of Service 5 minutes uptime are not enough, aim for 24/7 Manage resources carefully, keep malloc and free balanced Track and release resources, locks, etc. Check especially in error and exception handling paths Asynchronous exceptions – as mentioned previously
32. Self assessment
33. Static Analysis Manually checking source code does not scale, add automation to it Check automatically for patterns that could cause problems Verify that arrays are accessed within bounds Verify that exceptions are used safely Verify that mallocs and frees are balance to prevent memory leaks Warn against whether obsolete/restricted functions are used Check for proper usage patterns of language constructs Check that variables are initialized and declared functions are used Examples: (Sp)lint, Cppcheck, Fortify SCA, compiler warnings Also watch out for abandoned Copy & Paste sources
34. Compiler warnings Watch out for warnings, they are there to prevent disasters printHelloWorld.c:15:9: warning: format string is not a string literal (potentially insecure) [-Wformat-security] printf(nativeString); ^~~~~~~~~~~~
35. Dynamic Analysis Some problems are not easily detectable in source code Runtime instrumentation on the OS level allows inspection Debug heaps can check proper balance of malloc/free Resource inspection tools assist debugging interaction with the OS platform (procmon, fuser, fs_usage) Put stress on shared resources Prevent security impact of race conditions and resource exhaustions with proper test cases Generate edge cases (fuzzing) Enhance your functional test suite with "unexpected input" test cases
36. Multi-Threading test Test appropriate Synchronization to access shared values in memory byte sharedArray= new byte[1000]; BlockingQueueq = new ArrayBlockingQueue(limit);ex = new ThreadPoolExecutor(limit, limit, 300, TimeUnit.SECONDS, q);for (inti = 0; i < limit; i++) {try {ex.execute(new RunnableObject(i, sharedArray)); }catch (Throwable e) {}; }[..]ex.shutdown(); public class RunnableObject implements Runnable{SomeVulnerableNativeWrappersvnw; public void run() { svnw.doSomethingNativeWithSharedArray(passedSharedArray);
37. Fuzzing Peter Oehlert: Violating Assumptions with Fuzzing. IEEE Security & Privacy 3(2): 58-62 (2005) "A highly automated testing technique that covers numerous boundary cases using invalid data (from files, network protocols, API calls, and other targets) as application input to better ensure the absence of exploitable vulnerabilities. The name comes from modem applications’ tendency to fail due to random input caused by line noise on “fuzzy” telephone lines".
38. Fuzzing A history of Fuzzing 1990 Barton Miller, University of Wisconsin-Madison http://pages.cs.wisc.edu/~bart/fuzz/ Testing approach Different from traditional software testing where functional requirements are tested goal is to detect misbehavior, the less misbehavior the less vulnerabilities Black box fault injection No internal knowledge necessary Feeding (partial) random input to applications Low effort testing, typically automated test setup Initial focus on stability, if application crashes or hangs, the test fails 2000+ caught up by security researchers Ilja von Sprundel, ActiveX (2005); Charlie Miller, iOS (2009); ...
39. Fuzzing workflow
40. Fuzzing Native code testing Find bugs within native parsers written in C code Images, Colorprofiles and Sound files Fonts (Truetype, Type1, OpenType) Media processing JNI has no bounds checking, nor implicit memory management Native Buffer overflows Native Heap corruption Overwrite of Standard Exception Handlers (SEH on windows)
41. Fuzzing Important parameters Seed (-s) The source of randomness used for a particular testcase Example: Long value, new Random(42) Ratio (-r) The density of fuzzed bytes in relation to total size of input file Example: Double value between 0 and 1, practical are values like 0.01 or 0.001 Range (--bytes) A block within an input file supposed to be fuzzed Example: Integer range between 0 and the file size, could be used to skip the fuzzing of an invariant file header
42. Fuzzing parameters Variables to influence fuzzing (in practice for bit flipping) ] echo "AAAAAAAAAAAAAAAAAAAA" | zzuf -s 1 -r 0.01 "AAAAAAAAA▒AAAAAAAAAA" ] echo "AAAAAAAAAAAAAAAAAAAA" | zzuf -s 2 -r 0.01 &AAAAAAaAAAAAAAAASAAA" ] echo "AAAAAAAAAAAAAAAAAAAA" | zzuf -s 3 -r 0.01 "AAACAAAAAAAAAAAAAAAA" ] echo "AAAAAAAAAAAAAAAAAAAA" | zzuf -s 4 -r 0.1 0AEEIAI@@CCAAQ▒AQSAaA" ] echo "AAAAAAAAAAAAAAAAAAAA" | zzuf -s 4 -r 0.1 --bytes=10- "AAAAAAAAACAAQ▒AQSAaA"
43. FuzzingStandalone Mutation-based Implementations Zzufhttp://caca.zoy.org/wiki/zzuf Author: Sam Hocevar, License: DWTFYWTPL , Version 0.13 Included with most Linux distribution and also in Macports Xor Bit flip fuzzing transparent proxy Highly configurable fuzz parameters (seed, ratio, range, ... ) foriin{1..100};do zzuf -s$i -r 0.001--bytes=0-256< infile.txt >/tmp/s$i.bin java –jar bla.jar /tmp/s$i.bin done Issues: Fuzzed file not reproducible reliable when the JVM is launched by zzuf
44. Fuzzing Frameworks CERT Basic Fuzzing Framework 2.5 https://www.cert.org/blogs/certcc/2010/05/cert_basic_fuzzing_framework.html Written by CERT @ Carnegie Mellon University For Linux (Debian) and OSX Windows variant, Failure Observation engine (FOE) Bit-Level, Byte-Level, Copy, Drop/Insert and other mutation strategies Post-crash analysis modules for auto-bucketing Bundles useful scripts and vulnerable open source code samples
45. Fuzzing Frameworks Peach Fuzzing Platform http://peachfuzzer.com/ Author: Michael Eddington, Version 3, MIT license Fuzzing performed based on several high level concepts Modeling, Publishers, Fuzzing Strategy, Mutators, Agents, Monitors and Loggers Default implementation for those concepts is feature rich Extensible with custom plugins Describes file/protocol formats in XML-based PIT files Fuzzing Coverage depends on the quality of the PIT file in other words: What's not described in the PIT file cannot be fuzzed
46. A JNI vulnerability found by fuzzing Selected Example: CVE-2009-0793 OpenJDK contained a DoS-vulnerability in a 3rd-party library A vulnerability was discovered in the handling of ICC color profiles, causing a null pointer deference, typically crashing with SEGV Method used: foriin {1..100} ; do echo $i ; zzuf-s$i -r 0.004 <test.icc >/tmp/i$i.icc; java -Djava.awt.headless=true DisplayICC/tmp/i$i.icc; done
47. Fuzzing Standalone fuzzers and the JRE Standalone fuzzers can have issues when fuzzing Java programs Often due to shared resources (/dev/random, file handles) Memory issues when Java executable is launched from the fuzzer Design your test cases to run headless, avoid GUI effects Prevents app not shutting down avoids slower startup times Heisenbugs, cases that only crash when run under the fuzzer Try to decouple the processes use the fuzzer only to prepare the input file, then run the Java program
48. A Java Fuzzer staticint[] pot= new int[]{1,2,4,8,16,32,64,128}; publicstaticRetValfuzz(byte[] arr, intseed, doubleratio) { Random rand = new Random(seed); RetValr = newRetVal(); intsize = arr.length; intsize8= size * 8; intanz = (int) (size * ratio) ; r.changes= anz; r.b= arr.clone(); if(ratio!= 0.0) { for (inti = 0 ; i < anz; i++) { int pos = rand.nextInt(size8-1); intposby = pos / 8 ; intposbt = pos % 8; byte od = r.b[posby]; bytenewod = (byte) (od ^ pot[posbt]); r.b[posby]=newod; } } returnr; } To save JRE reload time it is helpful to do the fuzzing in Java A bit-mutation algorithm is easy to implement A Java implementation
49. A Java Fuzzer In-JVM fuzzing Works on byte[] – Buffers Emulates zzuf range and ratio parameters Only restart of JVM when crash happened (save time) Create standalone reproducer to isolate test cases Works also in non-headless mode
50. Fuzzing Summary Fuzzing is a powerful technique to detect potential vulnerabilities in native code The hs_err_pid crash log eases discussion about severity and fix worthiness Fuzzing tests easily be applied by developers for self-assessment of assumptions made in their components to switch perspectives to think like an attacker to run fuzzing tests first, before the bad guys do when defining functional tests, think about fuzzing tests, too Ideally use a build with debuginfo http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html Optimized code may behave different
51. Crash analysis
52. Post-crash actions Collecting and analyzing crash information CrashWrangler(OSX)https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20390 gives „exploitable: yes/no“ notice by checking registers and crash instructions easies discussion about security relevance of a discovered issue !MSEC.exploitable(Windows) http://msecdbg.codeplex.com/ Plugin for the Windbg debugger on Windows analyses registers and crash instruction to predict exploitability CERT Triage Tools for Linux http://www.cert.org/vuls/discovery/triage.html Extension for the GNU Debugger (GDB) Classifies application bugs by severity Can be wrapped for batch execution
53. Post-crash analysis Settings to collect better information Helpful flags for post crash analysis -Xcheck:jni, -verbose:jni -XX:OnError="cp reproducer.bin %p.file" -XX:+ShowMessageBoxOnError, -XX:ErrorFile= ... More in the JVM Troubleshooting Guide http://www.oracle.com/technetwork/java/javase/toc-135973.html For easy reproducibility bundle the fuzzed file, a standalone executable jar and the crash information in hs_err_pid*.log Don‘t be afraid of Heisenbugs
54. JVM Runtime flags Perform additional checks for JNI functions with -Xcheck:jni Causes the JVM to perform additional validation on arguments passed to JNI functions. It can help to locate and diagnose a large number of such problems. This is not guaranteed to find all invalid arguments or even diagnose logic bugs in the application code.
55. JVM Runtime flags Perform additional checks for JNI functions with -Xcheck:jni (continued) Enables logging of JNI. When a JNI or native method is resolved, the JVM prints a trace message to the application console (standard output). Prints a trace message when a native method is registered using the JNI_RegisterNative function. Can be useful in diagnosing issues with applications that use native libraries.
56. JVM Runtime flags Perform additional checks for JNI functions with -Xcheck:jni(continued) … [Dynamic-linking native method java.util.zip.ZipFile.read ... JNI] [Dynamic-linking native method java.util.zip.Inflater.getBytesWritten ... JNI] [Dynamic-linking native method java.util.zip.Inflater.reset ... JNI] [Dynamic-linking native method java.io.UnixFileSystem.getLength ... JNI] [Dynamic-linking native method java.lang.ClassLoader.defineClass1 ... JNI] [Dynamic-linking native method CHelloWorld.printSomething ... JNI] <some program output> Checked JNI functions are being used to validate JNI usage
57. Platform specific mitigations Windows: Prevention Compile/Link Flags http://technet.microsoft.com/en-us/security/dd285253.aspx /GS (stack buffer overrun protection) /DYNAMICBASE (Address Space Layout Randomization, KB2639308) /NXCOMPAT (Data Execution Prevention, non-executable memory) /SAFESEH (secure exception handlers) Detection Tools EMET http://support.microsoft.com/kb/2458544 Checkbins.py https://code.google.com/p/chrome-browser/source/browse/trunk/src/tools/checkbins/checkbins.py
58. Defending the heap Detecting for Heap-based bugs Heap Spraying A preparation technique for the heap to create landing zones when control runs wild due to attacker-based input Use heap spraying with scribble values to detect whether your library can be exploited (like finding 0x30303030 in EIP register) Use a debug heap (GuardMalloc, Pageheap) Also check heap sanity from the Java layer preclaim heap with large arrays and fill with known values (-javaagent) check those heap references (allocated arrays) for mutations in a thread
59. Platform specific mitigations Windows: Analysis tools Windbg Gflags, !analyze, !exploitable Sysinternals tools
60. Platform specific mitigations Windbghttp://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx Debugger, Part of debugging tools for windows 32 and 64 bit Debugging in user space and kernel mode Allows to integrate plugin that evaluate register values and stack information (!exploitable, !analyze,!heap)
61. Platform specific mitigations Windbg Heap Checking flags Gflags Gflag is a command within Windbg to activate additional heap checks !gflag +soe , Stop on exceptions !gflag +hpa, Turn on PageHeap Perform every heap allocation on its own page. Detect out of bounds memory errors immediately at first dereference More flags at: http://msdn.microsoft.com/en-us/library/windows/hardware/ff549596%28v=vs.85%29.aspx
62. Platform specific mitigations Sysinternaltools http://technet.microsoft.com/en-us/sysinternals/bb896653 Help to monitor the actions triggered by a native library Process Monitor Process Explorer Handles DebugView
63. Platform specific mitigations Linux: Prevention Platform NX via ExecShield,Policy-based excution via SELinux Address Space Layout Randomization Heap protection (GLIBc), double free checks, pointer encryption (glibc) Flags: Stack protection (­fstack­protector) ld ­z relro gcc … ­D_FORTIFY_SOURCE=2 ld ­pie / gcc ­fPIE Check hardening papers in the references
64. Platform specific mitigations
65. Platform specific mitigations Linux: Runtime analysis Gcc emits helpful warnings Valgrind(comes with most Linux distributions) runtime checks CERT exploitable tool _MALLOC_CHECK for glibc heap checking
66. Platform specific mitigations OSX: Prevention and Analysis Address Space Layout Randomization Application sandboxing Digital signatures for binaries Memory leak detection with the leaks tool Heap Tracing/Debugging with GuardMalloc https://developer.apple.com/library/Mac/documentation/Performance/Conceptual/ManagingMemory/ManagingMemory.html
67. Check List Easy to remember items
68. Summary Keep your native code safe If possible avoid JNI Keep native code as short as possible Keep native code private, wrap with sanity check methods For the target OS use the recommend compile/link flags Check stability in stressful runtime scenarios (multithreading,fuzzing)
69. References More Reading … The JNI Specification http://docs.oracle.com/javase/7/docs/technotes/guides/jni/ Books Essential JNI The Java Native Interface: Programmer's Guide and Specification Hardening GCC chain http://cansecwest.com/csw08/csw08-holtmann.pdf http://wiki.debian.org/Hardening#User_Space http://multimedia.cx/eggs/heroic-defender-of-the-stack/
70. Q&A
71. The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract.It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.