User Tools

Site Tools


an_empirical_security_study_of_the_native_code_in_the_jdk

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
an_empirical_security_study_of_the_native_code_in_the_jdk [2013/10/15 02:33]
yann created
an_empirical_security_study_of_the_native_code_in_the_jdk [2014/01/09 00:38]
yann
Line 1: Line 1:
-====== ​Abstract ​======+====== ​Tan, G. & Croft, J. An empirical security study of the native code in the JDK. Proceedings of the 17th Security Symposium, USENIX Association,​ 2008, 365-377 ​====== 
 + 
 + 
 +===== Abstract ​=====
  
 It is well known that the use of native methods in Java defeats Java's guarantees of safety and security, which is why the default policy of Java applets, for example, does not allow loading non-local native code. However, there is already a large amount of trusted native C/C++ code that comprises a significant portion of the Java Development Kit (JDK). We have carried out an empirical security study on a portion of the native code in Sun's JDK 1.6. By applying static analysis tools and manual inspection, we have identified in this security-critical code previously undiscovered bugs. Based on our study, we describe a taxonomy to classify bugs. Our taxonomy provides guidance to construction of automated and accurate bug-finding tools. We also suggest systematic remedies that can mediate the threats posed by the native code. It is well known that the use of native methods in Java defeats Java's guarantees of safety and security, which is why the default policy of Java applets, for example, does not allow loading non-local native code. However, there is already a large amount of trusted native C/C++ code that comprises a significant portion of the Java Development Kit (JDK). We have carried out an empirical security study on a portion of the native code in Sun's JDK 1.6. By applying static analysis tools and manual inspection, we have identified in this security-critical code previously undiscovered bugs. Based on our study, we describe a taxonomy to classify bugs. Our taxonomy provides guidance to construction of automated and accurate bug-finding tools. We also suggest systematic remedies that can mediate the threats posed by the native code.
  
-====== Comments ======+===== Comments ===== 
 //​Yann-Gaël Guéhéneuc,​ 2013/​10/​15//​ //​Yann-Gaël Guéhéneuc,​ 2013/​10/​15//​
  
Line 20: Line 24:
 Some of the bug patterns require fairly complex scenarios, for example the use of reflection to modify private fields. Although an attacker could try to perform modify private fields, it is unclear how often such scenario really could and would occur in practice. Yet, the authors provide some directions to fix the bug patterns. However, some of these solutions are ad hoc and leave doubt as their efficiency, like the use of indirection tables of pointers to avoid an attacker changing a Java integer value used as a pointer. Indeed, what would prevent the very same attacker to change the content of the indirection table? The authors nonetheless point at interesting direction, like the use of software fault isolation. Some of the bug patterns require fairly complex scenarios, for example the use of reflection to modify private fields. Although an attacker could try to perform modify private fields, it is unclear how often such scenario really could and would occur in practice. Yet, the authors provide some directions to fix the bug patterns. However, some of these solutions are ad hoc and leave doubt as their efficiency, like the use of indirection tables of pointers to avoid an attacker changing a Java integer value used as a pointer. Indeed, what would prevent the very same attacker to change the content of the indirection table? The authors nonetheless point at interesting direction, like the use of software fault isolation.
  
-The conclusion is that many bug patterns exist, probably more than discussed in the paper, but that their current detection are at best ad hoc. It would be interesting to study how to describe and detect systematically (1) missing bound checks, (2) missing JNI release memory calls, (3) missing access controls to private Java fields/​methods from the C/C++ code, etc. Also, tools supporting multi-language systems are necessary because most tools "​analyze C code alone, without consideration how the Java side interact ​with the C side". The tools should handle **real** programming languages, not some "​well-defined subset of C such as Cminor"​ because then they become useless with real code.+The conclusion is that many bug patterns exist, probably more than discussed in the paper, but that their current detection are at best ad hoc. It would be interesting to study how to describe and detect systematically (1) missing bound checks, (2) missing JNI release memory calls, (3) missing access controls to private Java fields/​methods from the C/C++ code, etc. Also, tools supporting multi-language systems are necessary because most tools "​analyze C code alone, without consideration how the Java side interacts ​with the C side". The tools should handle **real** programming languages, not some "​well-defined subset of C such as Cminor"​ because then they become useless with real code.
an_empirical_security_study_of_the_native_code_in_the_jdk.txt · Last modified: 2019/10/06 20:37 (external edit)