Finally, an easy security layer for Java
JarLock is a super easy way to add a powerful layer of protection to applications running on the Java Virtual Machine.
JarLock is a super easy way to add a powerful layer of protection to applications running on the Java Virtual Machine.
Create an allow list of network connections, block everything else.
Block the creation of processes within your application.
Easily block dangerous Java APIs such as Java Serialization / Deserialization, JNDI, and more.
You don't need to be a programmer to add JarLock to a Java application.
Select the security features you'd like to apply to your Java Application, and download the configuration.
jarlock.properties FileJARLOCK_LOG_ENABLED=true
JARLOCK_LOG_VERBOSE=true
JARLOCK_BLOCK_ENABLED=true
JARLOCK_BLOCK_CLASSES=lucee.runtime.functions.other.CFusionEncrypt,CFusionDecrypt,javax.accessibility.AccessibleTextSequence
JARLOCK_BLOCK_PACKAGES=lucee.runtime.functions.csrf,lucee.runtime.functions.orm
JARLOCK_BLOCK_JAVA_SERIALIZATION=true
JARLOCK_BLOCK_JAVA_DESERIALIZATION=true
JARLOCK_TRUSTED_SOURCES=*/WEB-INF/cftags/*,flex.server.j2ee.cache.DependencyChecker,com.adobe.internal.pdfm.util.FontSetBuilder,*iif.cfm,runwar.Server$MonitorThread,runwar.Server$OpenBrowserTask,runwar.Start
JARLOCK_BLOCK_PROCESS_CREATION=true
JARLOCK_BLOCK_PROCESS_DESTROY=true
JARLOCK_BLOCK_PROCESS_ENUMERATION=true
JARLOCK_BLOCK_RUNTIME_EXIT=true
JARLOCK_BLOCK_TOOLPROVIDER=true
JARLOCK_ALLOW_SOCKET_LISTEN=127.0.0.1:8311,127.0.0.1:50311,0.0.0.0:1243
JARLOCK_ALLOW_SOCKET_CONNECT=127.0.0.1:8311,httpbin.org,foundeo.com
JarLock was born in the wake of the 2021 Log4J vulnerability aptly known as Log4Shell. We wanted an easy way to apply security boundaries to our Java Applications. We didn't use JNDI, so why should we suffer from obscure and vulnerable uses of it in a popular third party library? Further it was hard to know which applications included the vulnerable classes, it would have been nice to be able apply a configuration to block vulnerable classes throughout the JVM.
It's true Java does come with a powerful SecurityManager, but many have found it difficult to deploy, difficult to configure, and poor in performance. To make matters worse the SecurityManager has been deprecated as of Java 17 (see JEP 411) in 2011, and is slated to be removed from Java all together via JEP 486 (in Java 24).
The Java Module System is a great step forward, but many of the powerful features of the JVM live within the java.base module.
Often exploited features such as Java Deserialization, executing processes, networking are all implemented within the java.base module, so every module has implicit access to these apis.
Some exploited features, such as JNDI do live within their own module (java.naming), and it is possible to create your own jvm runtime image that excludes such modules. In practice most
do not create a custom runtime, and JarLock can be used to protect those.
Finally, even though the module system does prevent a third party lib from using modules besides java.base that it does not
explicitly declare. This doesn't often protect the end user. Consider that the log4j's module definition requires java.naming which opens a read edge to the JNDI API.
Using JarLock we can provide an off switch to the APIs which our applications do not require.
Download Now