surajmall opened a new pull request, #437:
URL: https://github.com/apache/jackrabbit-filevault/pull/437
## Summary
FileVault's `InstallHookProcessor` loads and **instantiates** a package's
`InstallHook` classes **before** the admin-session authorization check runs for
hook-bearing packages. `ZipVaultPackage.prepareExtract` calls
`hooks.registerHooks(...)` (which constructs the hook instances) and only
afterwards calls `checkAllowanceToInstallPackage(...)`, which performs the
`hasHooks()` admin check.
As a result, a non-admin session (e.g. a standard `dam-users` /
`content-authors` author) that can reach the Package Manager install for a
hook-bearing package triggers the attacker-supplied hook **constructor** inside
the JVM, before the intended rejection (`"Package extraction requires admin
session as it has a hook (userid '…' not allowed)"`) is returned. The rejection
is cosmetic — arbitrary Java bytecode has already executed (CWE-94 / RCE).
Internal reference: GRANITE-74250 (CVSS 9.9).
## Fix
1. Add `InstallHookProcessor.hasHooks(Archive)` — a `default` method that
detects whether an archive declares install hooks (hook jar entries and
`installhook.{name}.class` properties) **without loading or instantiating any
class**.
2. In `ZipVaultPackage.prepareExtract`, enforce the hook authorization check
(`checkHookAllowance`) using `hooks.hasHooks(archive)` **before**
`registerHooks(...)`. Only authorized sessions proceed to register (and thereby
instantiate) hooks.
3. Retain the existing post-registration `hasHooks()` check in
`checkAllowanceToInstallPackage` as defense in depth.
4. Bump the `org.apache.jackrabbit.vault.packaging` package export version
`2.15.0 → 2.16.0` (new default interface method).
The change is binary-compatible (the new interface method is a `default`
method).
## Verification
Reproduced and verified on a local AEM 6.6 LTS instance running
`org.apache.jackrabbit.vault` 3.8.0:
- **Before:** non-admin install of a hook-bearing package returned the "not
allowed" rejection, but a benign marker written by the hook constructor
confirmed the hook executed.
- **After:** the same attack returns the rejection and the hook constructor
does **not** execute (no marker).
- **Regression:** admin install of a hook-bearing package still succeeds.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
