db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "JavaRoutineSecurity" by DanDebrunner
Date Wed, 13 Dec 2006 19:28:16 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by DanDebrunner:
http://wiki.apache.org/db-derby/JavaRoutineSecurity

------------------------------------------------------------------------------
   * JREBUG - Security bug exists in the JRE allowing user code to access resources. Typically
the assumption for Derby to be secure is that it is operating in a secure environment which
includes JRE's virtual machine and its class libraries.
   * CPBUG - Security bug exists in the application or framework code on the classpath (CP).
Most likely a higher probability than a security bug in the JRE, typically would be caused
by some path to a privileged block that allowed malicious code to exploit permissions granted
to the application or framework code.
   * DERBYBUG - Security bug exists in Derby's engine or network code. Most likely a higher
probability than a security bug in the JRE, typically would be caused by some path to a privileged
block that allowed malicious code to exploit permissions granted to the Derby's code. Since
the Derby code is the database engine it's guaranteed to have permissions to access the database
files and thus potential exists for security holes that allow an application to access the
data bypassing database level security.
-  * JARBUG - Security bug exists in the application code in an installed jar (DBCP, SQLJAR).
Most likely a higher probability than a security bug in the JRE, typically would be caused
by some path to a privileged block that allowed malicious code to exploit permissions granted
to the application's installed jar.
+  * APPJARBUG - Security bug exists in the application code in an installed jar (DBCP, SQLJAR).
Most likely a higher probability than a security bug in the JRE, typically would be caused
by some path to a privileged block that allowed malicious code to exploit permissions granted
to the application's installed jar.
  
  == Assumptions ==
  
@@ -127, +127 @@

  === Risks ===
  
   * Any user can create a Java routine directly against a public static method in JRE, CP
or DERBY and thus can exploit '''potential''' security risks described by JREBUG, CPBUG or
DERBYBUG.
-  * Any user can create a Java routine against a public static method in DBCP and thus can
exploit any '''potential''' security risks within the jar.
+  * Any user can create a Java routine against a public static method in DBCP and thus can
exploit any '''potential''' security risks described by APPJARBUG.
-  * Installed jars can contain (malicious) code that can exploit '''potential''' security
risks described by JREBUG, CPBUG or DERBYBUG.
+  * Installed jars can contain (malicious) code that can exploit '''potential''' security
risks described by JREBUG, CPBUG, DERBYBUG or APPJARBUG.
  === Improving Java Routine Security in 10.3 onwards ===
  To reduce the '''potential''' security risks these steps could be taken:
  || '''What''' || '''Jira''' || '''Description''' ||

Mime
View raw message