JNDI (“Java Naming and Directory Interface”) is a Java JDK API representing an abstract directory service such as DNS, a file system or LDAP. Critically, JNDI allows Java objects to be serialized and deserialized on the wire in implementing systems. This means that if a Java application is allowed to perform a JNDI lookup over some transport protocol then the server it connects to can execute arbitrary attacker-defined code. See this Black Hat talk for more information.
This checker bans usage of every API in the Java JDK that can result in
deserialising an unsafe object via JNDI. The list of APIs is generated from
static callgraph analysis of the JDK, rooted at javax.naming.Context.lookup
and is as follows:
javax.naming.Context.lookupjavax.jdo.JDOHelper.getPersistenceManagerFactoryjavax.jdo.JDOHelperTest.testGetPMFBadJNDIjavax.jdo.JDOHelperTest.testGetPMFBadJNDIGoodClassLoaderjavax.jdo.JDOHelperTest.testGetPMFNullJNDIjavax.jdo.JDOHelperTest.testGetPMFNullJNDIGoodClassLoaderjavax.management.remote.JMXConnectorFactory.connectjavax.management.remote.rmi.RMIConnector.connectjavax.management.remote.rmi.RMIConnector.findRMIServerjavax.management.remote.rmi.RMIConnector.findRMIServerJNDIjavax.management.remote.rmi.RMIConnector.RMIClientCommunicatorAdmin.doStartjavax.naming.directory.InitialDirContext.bindjavax.naming.directory.InitialDirContext.createSubcontextjavax.naming.directory.InitialDirContext.getAttributesjavax.naming.directory.InitialDirContext.getSchemajavax.naming.directory.InitialDirContext.getSchemaClassDefinitionjavax.naming.directory.InitialDirContext.modifyAttributesjavax.naming.directory.InitialDirContext.rebindjavax.naming.directory.InitialDirContext.searchjavax.naming.InitialContext.doLookupjavax.naming.InitialContext.lookupjavax.naming.spi.ContinuationContext.lookupjavax.naming.spi.ContinuationDirContext.bindjavax.naming.spi.ContinuationDirContext.createSubcontextjavax.naming.spi.ContinuationDirContext.getAttributesjavax.naming.spi.ContinuationDirContext.getSchemajavax.naming.spi.ContinuationDirContext.getSchemaClassDefinitionjavax.naming.spi.ContinuationDirContext.getTargetContextjavax.naming.spi.ContinuationDirContext.modifyAttributesjavax.naming.spi.ContinuationDirContext.rebindjavax.naming.spi.ContinuationDirContext.searchjavax.sql.rowset.spi.ProviderImpl.getDataSourceLockjavax.sql.rowset.spi.ProviderImpl.getProviderGradejavax.sql.rowset.spi.ProviderImpl.getRowSetReaderjavax.sql.rowset.spi.ProviderImpl.getRowSetWriterjavax.sql.rowset.spi.ProviderImpl.setDataSourceLockjavax.sql.rowset.spi.ProviderImpl.supportsUpdatableViewjavax.sql.rowset.spi.SyncFactory.enumerateBindingsjavax.sql.rowset.spi.SyncFactory.getInstancejavax.sql.rowset.spi.SyncFactory.initJNDIContextjavax.sql.rowset.spi.SyncFactory.parseJNDIContextA small subset of these are banned directly. The rest are banned indirectly by
banning the lookup(), bind(), rebind(), getAttributes(),
modifyAttriutes(), createSubcontext(), getSchema(),
getSchemaClassDefinition() and search() methods on any subclass
(implementer) of javax.naming.Context. The indirect ban is necessary due to
these methods being vulnerable in previously noted subclasses in the JDK. If
they were not banned at the Context level, a cast to Context would make the
vulnerable call invisible to static analysis.
Suppress false positives by adding the suppression annotation @SuppressWarnings("BanJNDI") to the enclosing element.