Headline
CVE-2022-31139: Release 1.7.0 · Karlatemp/UnsafeAccessor
UnsafeAccessor (UA) is a bridge to access jdk.internal.misc.Unsafe & sun.misc.Unsafe. Normally, if UA is loaded as a named module, the internal data of UA is protected by JVM and others can only access UA via UA’s standard API. The main application can set up SecurityCheck.AccessLimiter for UA to limit access to UA. Starting with version 1.4.0 and prior to version 1.7.0, when SecurityCheck.AccessLimiter is set up, untrusted code can access UA without limitation, even when UA is loaded as a named module. This issue does not affect those for whom SecurityCheck.AccessLimiter is not set up. Version 1.7.0 contains a patch.
Changelog
IMPORTANT: Fix security checking of UnsafeAccess.getInstance
Affected version: >= 1.4.0 & < 1.7.0
Add Root.MethodHandleLookup for bytecode invokeDynamic executing
Add Unsafe.getOriginalUnsafe() to get sun.misc.Unsafe / jdk.internal.misc.Unsafe
Preview api for control --enable-native-access (ModuleAccess.isEnableNativeAccess)
Make BytecodeUtil public
Add ModuleAccess.getUnnamedModule(ClassLoader)
Try to use standard api to initialize UnsafeAccessor
Test Report
https://github.com/KasukuSakura/static-assets/blob/main/unsafe-accessor-release-test-report/1.7.0.md
Related news
### Overview Affected versions have no limit to using unsafe-accessor. Can be ignored if `SecurityCheck.AccessLimiter` not setup ### Details If UA was loaded as a named module, the internal data of UA will be protected by JVM and others can only access UA via UA's standard api. Main application can setup `SecurityCheck.AccessLimiter` for UA to limit accesses to UA. Untrusted code can access UA without lmitation in affected versions even UA was loaded as a named module. ### References [The commit to fix](https://github.com/Karlatemp/UnsafeAccessor/commit/4ef83000184e8f13239a1ea2847ee401d81585fd)