[GH-ISSUE #3438] apktool: no warning when the launcher is vulnerable to CVE-2024-21633 #1283

Closed
opened 2026-10-16 21:03:45 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @GovinduSasanka on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3438

apktool before 2.9.2 can write decoded resources outside the output directory when it decodes a crafted APK (CVE-2024-21633). REA reads the launcher version (src/apktool/ApktoolConfiguration.ts) but never compares it to that fix. A user decoding an untrusted APK with an old distro apktool gets no signal.

Refusing old versions would break Debian/Ubuntu's packaged 2.7.0, which docs/apktool-resource-analysis.md uses for verification. So the proposal is a limitation on inspect_apktool_client and decode_android_resources results when the version parses as older than 2.9.2, not a refusal.

Reviewed at fa4b828. A PR follows.

Originally created by @GovinduSasanka on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3438 apktool before 2.9.2 can write decoded resources outside the output directory when it decodes a crafted APK (CVE-2024-21633). REA reads the launcher version (`src/apktool/ApktoolConfiguration.ts`) but never compares it to that fix. A user decoding an untrusted APK with an old distro apktool gets no signal. Refusing old versions would break Debian/Ubuntu's packaged `2.7.0`, which docs/apktool-resource-analysis.md uses for verification. So the proposal is a **limitation** on `inspect_apktool_client` and `decode_android_resources` results when the version parses as older than 2.9.2, not a refusal. Reviewed at fa4b828. A PR follows.
Author
Owner

@morluto commented on GitHub (Oct 17, 2026):

Fixed in 63696d277, adapting the Apktool policy from #3440 with Govindu Sasanka credited.

The version owner now parses once and produces compatibility and CVE-2024-21633 limitation facts. Both inspection and decoding reuse them; completed Evidence retains the warning through cancellation/cleanup failure. Reported spelling, exact dirty-release handling, other prereleases and version-only error diagnostics are preserved. The warning explicitly distinguishes upstream version guidance from unknown engine contents/backports and makes no general safety claim for newer versions.

Validation: 194 focused tests across 15 files, final 87 source checks, static/docs/commit/push checks, two source reviews; five controls fail on the clean previous commit. Twelve actual stdio MCP workflows (full discovery, inspection, decode) and four built CLI controls used tiny authored launchers. Control-version Evidence/catalog stay equal; old-version results differ only in the advisory limitations and Evidence IDs. Text/structured parity and digest/metadata/string/count/coverage assertions pass. Measured runtime snapshot hashes match the pre-hook snapshot; committed ASTs differ only in formatting.

Warm medians baseline/candidate, two alternating repeats each plus separate first processes: old-version MCP elapsed 3.451/3.681s, CPU 4.398/4.778s, sampled family RSS 1270/1350 MB; control-version elapsed 2.982/3.108s, CPU 3.935/4.273s, RSS 1272/1352 MB. Full discovery plus two replies: cl100k estimates 804858→805279 for the deliberate warning, 804860 unchanged for the control. These samples establish no speedup or attributable performance regression; cache state was not flushed, and PPID sampling can miss transient/reparented processes.

No real Apktool/JVM, native Windows, vulnerable APK/exploit, true cold, large-inventory or whole-agent-cost verification. Heavy profiling/stress remained stopped.

Remaining advisory work is tracked in #4818: Windows applicability and the later regression need their own verified ranges; source/advisory metadata discrepancies remain explicit. That work does not alter this original CVE-specific result.

<!-- gh-comment-id:6235508344 --> @morluto commented on GitHub (Oct 17, 2026): Fixed in 63696d277, adapting the Apktool policy from #3440 with Govindu Sasanka credited. The version owner now parses once and produces compatibility and CVE-2024-21633 limitation facts. Both inspection and decoding reuse them; completed Evidence retains the warning through cancellation/cleanup failure. Reported spelling, exact dirty-release handling, other prereleases and version-only error diagnostics are preserved. The warning explicitly distinguishes upstream version guidance from unknown engine contents/backports and makes no general safety claim for newer versions. Validation: 194 focused tests across 15 files, final 87 source checks, static/docs/commit/push checks, two source reviews; five controls fail on the clean previous commit. Twelve actual stdio MCP workflows (full discovery, inspection, decode) and four built CLI controls used tiny authored launchers. Control-version Evidence/catalog stay equal; old-version results differ only in the advisory limitations and Evidence IDs. Text/structured parity and digest/metadata/string/count/coverage assertions pass. Measured runtime snapshot hashes match the pre-hook snapshot; committed ASTs differ only in formatting. Warm medians baseline/candidate, two alternating repeats each plus separate first processes: old-version MCP elapsed 3.451/3.681s, CPU 4.398/4.778s, sampled family RSS 1270/1350 MB; control-version elapsed 2.982/3.108s, CPU 3.935/4.273s, RSS 1272/1352 MB. Full discovery plus two replies: cl100k estimates 804858→805279 for the deliberate warning, 804860 unchanged for the control. These samples establish no speedup or attributable performance regression; cache state was not flushed, and PPID sampling can miss transient/reparented processes. No real Apktool/JVM, native Windows, vulnerable APK/exploit, true cold, large-inventory or whole-agent-cost verification. Heavy profiling/stress remained stopped. Remaining advisory work is tracked in #4818: Windows applicability and the later regression need their own verified ranges; source/advisory metadata discrepancies remain explicit. That work does not alter this original CVE-specific result.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#1283
No description provided.