Skip to content

Latest commit

 

History

History
98 lines (76 loc) · 7.57 KB

mitigations.md

File metadata and controls

98 lines (76 loc) · 7.57 KB

Mitigation Strategies Analysis for termux/termux-app

Mitigation Strategy: Strictly Limit Shared Storage and Enforce Scoped Storage

  • Mitigation Strategy: Strictly Limit Shared Storage and Enforce Scoped Storage

    • Description:

      1. Identify Data Sensitivity: Categorize all data as "highly sensitive," "sensitive," or "non-sensitive."
      2. Private Internal Storage: Store all "highly sensitive" and "sensitive" data in the application's private internal storage (Context.getFilesDir(), Context.getCacheDir()). This is inaccessible to Termux.
      3. Scoped Storage for Non-Sensitive Data (If Necessary): If "non-sensitive" data must be in shared storage, use the Storage Access Framework (SAF).
        • User-Initiated Actions: Only access shared storage via explicit user actions (e.g., "Save As").
        • ACTION_CREATE_DOCUMENT and ACTION_OPEN_DOCUMENT: Use Intents with these actions for user-mediated file selection.
        • Persistent Permissions (If Needed): Use takePersistableUriPermission() for long-term access, and releasePersistableUriPermission() when done.
        • Avoid Direct File Paths: Use URIs from the SAF, not hardcoded paths.
      4. Avoid Legacy Storage Permissions: Do not request READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE unless absolutely necessary and clearly justified to the user.

    • Threats Mitigated:

      • Unauthorized Access to Application Data via Termux: (Severity: High) - Prevents Termux from directly accessing data in shared storage without explicit user permission via SAF.
      • Data Exfiltration (via Termux): (Severity: High) - Makes it significantly harder for a malicious Termux script to steal data.
      • Data Modification (via Termux): (Severity: High) - Prevents unauthorized modification of application data by Termux.

    • Impact:

      • Unauthorized Access: Risk reduced from High to Low (with correct implementation).
      • Data Exfiltration: Risk reduced from High to Low.
      • Data Modification: Risk reduced from High to Low.

    • Currently Implemented:

      • Authentication tokens: SharedPreferences with MODE_PRIVATE (private storage).
      • User profile data: Encrypted SQLite database in the private data directory.
      • User-selected image uploads: SAF is used.

    • Missing Implementation:

      • Cached web content: Currently in getExternalFilesDir(). Must be moved to getCacheDir() (private cache). This is a direct Termux-related vulnerability on older Android versions.

Mitigation Strategy: Secure Inter-Process Communication (IPC)

  • Mitigation Strategy: Secure Inter-Process Communication (IPC)

    • Description:

      1. Identify IPC Mechanisms: List all IPC used (Intents, Content Providers, Bound Services, Broadcast Receivers).
      2. Explicit Intents: For internal communication, always use explicit Intents (specify the target component's class name).
      3. Permission-Protected Content Providers/Services: If exposing these:
        • Custom Permissions: Define custom permissions in AndroidManifest.xml with protectionLevel="signature".
        • Enforce Permissions: In the ContentProvider or Service, check permissions with checkCallingPermission() or checkCallingOrSelfPermission(). This specifically blocks Termux, which has a different signature.
      4. Intent Filter Review: For implicit Intents:
        • Minimize Intent Filters: Make filters as specific as possible.
        • exported Attribute: Set android:exported="false" if external access is not needed. If true, ensure strong permission checks.
      5. Input Validation: Validate all data received via IPC as untrusted, even with permission checks. This is crucial to prevent injection attacks even if Termux somehow bypasses initial checks.

    • Threats Mitigated:

      • IPC Exploitation (by Termux): (Severity: Medium) - Prevents Termux from sending malicious Intents or interacting with exposed components.
      • Data Leaks via IPC (to Termux): (Severity: Medium) - Reduces the risk of data leaks through insecure IPC.
      • Privilege Escalation (Indirectly, via Termux): (Severity: Low) - Reduces the attack surface.

    • Impact:

      • IPC Exploitation: Risk reduced from Medium to Low.
      • Data Leaks via IPC: Risk reduced from Medium to Low.
      • Privilege Escalation: Risk remains Low, but the attack surface is smaller.

    • Currently Implemented:

      • Internal activity communication: Explicit Intents.
      • No exposed Content Providers.
      • Bound Service (music playback): Protected with a custom permission (com.example.app.permission.BIND_MUSIC_SERVICE, protectionLevel="signature").

    • Missing Implementation:

      • Broadcast Receiver (network connectivity): Uses an implicit Intent filter (android.net.conn.CONNECTIVITY_CHANGE). Review the filter for overbreadth. Consider a dynamically registered receiver. This is a potential, though indirect, Termux-related vulnerability if a malicious Termux script could send crafted connectivity change broadcasts.

Mitigation Strategy: Minimize Dependency on Termux:API and Implement Strict Permission Checks

  • Mitigation Strategy: Minimize Dependency on Termux:API and Implement Strict Permission Checks

    • Description:

      1. Avoid Termux:API if Possible: If core functionality doesn't require Termux:API, remove dependencies.
      2. Identify Required APIs: If unavoidable, list only the necessary APIs.
      3. Explicit Permission Requests: Before any Termux:API call, check if the user granted the corresponding Android permission to your application using ContextCompat.checkSelfPermission(). Do not assume permissions granted to Termux apply to your app.
      4. User Education: Clearly explain in the UI and documentation:
        • That the app interacts with Termux:API.
        • Which device features are accessed.
        • The potential risks.
        • How to manage Termux:API permissions.
      5. Handle Permission Denials Gracefully: Implement error handling for denied permissions, with informative messages.

    • Threats Mitigated:

      • Abuse of Termux:API (by malicious Termux scripts): (Severity: High) - Prevents Termux from using your app to access device features without explicit user consent through your app.
      • Data Leakage via Termux:API: (Severity: High) - Reduces the risk of data leaks.
      • Unauthorized Device Control (via Termux:API): (Severity: High) - Prevents Termux from controlling device features through your app.

    • Impact:

      • Abuse of Termux:API: Risk reduced from High to Low (with correct implementation).
      • Data Leakage: Risk reduced from High to Low.
      • Unauthorized Device Control: Risk reduced from High to Low.

    • Currently Implemented:

      • The application does not use or depend on Termux:API.

    • Missing Implementation:

      • N/A - Fully implemented by not using Termux:API.