为何Codeforces、LeetCode等在线评测平台不允许Java提交自定义类加载器

在线评测平台允许自定义类加载器的风险 #

• 沙箱权限逃逸：OJ的JVM实例默认会通过安全管理器限制提交代码的权限，比如禁止读写本地磁盘、禁止执行系统命令、禁止访问网络。而自定义ClassLoader可以绕开双亲委派机制加载恶意构造的字节码，篡改或绕过安全管理器的校验逻辑，甚至调用Runtime.exec()执行恶意Shell指令，轻则导致评测机资源被占用，重则泄露平台敏感数据、损坏服务器文件系统。
• 静态代码检测绕过：攻击者可以将恶意逻辑加密后存到代码常量中，提交时静态检测无法识别风险，运行时由自定义类加载器解密字节码后加载执行，实现攻击行为的隐式触发。
• 服务可用性破坏：自定义类加载器可以无限制生成并加载大量无用类，占满JVM方法区内存，触发OOM故障，导致当前JVM实例甚至整台评测机无法处理其他用户的提交任务。
• 评测结果篡改：自定义类加载器可以优先加载和JDK核心类、OJ评测判题类同名的恶意字节码，篡改核心逻辑，比如修改题目输出结果、绕过时间/内存限制校验，实现作弊。

defineClass()的可用替代方案 #

如果是合法的动态生成类加载场景，可以使用以下方案替代自行实现类加载器调用defineClass()的操作：

• 使用MethodHandles.Lookup.defineClass()：Java 9及以上版本提供的官方API，无需自定义类加载器，即可在当前Lookup对象对应的类的访问权限上下文中定义新类，默认遵循双亲委派规则，不会触发安全机制的额外拦截（仅在无动态类定义权限的环境才会被拦截），适合普通动态字节码生成场景。
• 使用字节码生成框架封装能力：ASM、Byte Buddy、CGLIB等常用字节码操作框架已经封装了类定义、类加载的逻辑，用户只需配置字节码生成规则，框架会自动调用当前上下文的类加载器完成类的加载，无需手动调用defineClass()。
• Instrumentation.redefineClasses()：适合已有类的热更新场景，不过该API需要在JVM启动时通过-javaagent参数挂载代理获取权限，普通OJ环境不会开放该能力。

需要注意的是，以上替代方案本质还是动态类定义操作，在Codeforces、LeetCode这类严格限制权限的OJ环境中，依然会被安全管理器拦截抛出java.security.AccessControlException，只有在本地开发或自行配置的开放权限JVM环境中可以正常使用。

内容的提问来源于stack exchange，提问作者Shallow Frank