Skip to content

Latest commit

 

History

History
62 lines (49 loc) · 7.21 KB

File metadata and controls

62 lines (49 loc) · 7.21 KB

Threat Model Analysis for tiann/kernelsu

  • Description: An attacker distributes a modified version of KernelSU (e.g., a trojanized APK or a malicious update server) that appears legitimate but contains malicious code. The attacker might use social engineering to convince the user to install it, or they might exploit a vulnerability in an application's update mechanism if that application is responsible for installing KernelSU.
    • Impact: Complete device compromise. The attacker gains full root access and can steal data, install malware, or brick the device.
    • Affected Component: KernelSU Core (the main KernelSU installation package).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Developer: If (and only if) the application installs KernelSU, download it only from the official GitHub repository (https://github.com/tiann/kernelsu). Verify the downloaded package's checksum against the official checksum published on the GitHub releases page. Use HTTPS for all downloads. Implement robust update mechanisms with code signing and integrity checks. If the application does not install KernelSU, this is not a direct threat to the application itself.
      • User: Only install KernelSU from the official source. Be wary of any requests to install KernelSU from third-party websites or app stores.
  • Description: An attacker creates a malicious KernelSU module that masquerades as a legitimate module (e.g., by using a similar name or icon). The attacker might distribute this module through a third-party repository or social engineering.
    • Impact: Varies depending on the module's malicious actions. Could range from data theft to denial of service to complete device compromise.
    • Affected Component: KernelSU Modules (specifically, the malicious module).
    • Risk Severity: High to Critical (depending on the module's capabilities)
    • Mitigation Strategies:
      • Developer: If the application directly interacts with or relies on specific modules, hardcode the expected module IDs and verify their signatures before interacting with them. Do not rely on user input or external sources for module identification. Implement a strict allowlist of permitted modules. If the application does not interact with specific modules, this is primarily a user-level threat.
      • User: Only install modules from trusted sources (e.g., the official KernelSU module repository, if one exists, or well-known, reputable developers). Carefully review the permissions requested by a module before installing it.
  • Description: An attacker who has already gained root access through another vulnerability (unrelated to KernelSU) modifies the installed KernelSU core files or configuration to maintain persistence, bypass security checks, or inject further malicious code.
    • Impact: Persistent root compromise, even if the original vulnerability is patched. The attacker can maintain control of the device.
    • Affected Component: KernelSU Core (installed files and configuration).
    • Risk Severity: High
    • Mitigation Strategies:
      • Developer: This is primarily a defense-in-depth measure. While difficult to prevent completely if the attacker already has root, consider implementing periodic integrity checks of critical KernelSU files (e.g., using checksums). This can help detect tampering after it has occurred. This is not a primary mitigation, but a detection mechanism. This is a low-priority mitigation for the application developer, as it assumes a prior root compromise.
      • User: Regularly update KernelSU to benefit from security patches. Be vigilant about device security in general to prevent initial root compromise.
  • Description: A malicious or poorly written KernelSU module accesses sensitive data handled by the application (or other applications) and sends it to a remote server controlled by the attacker.
    • Impact: Data breach. Sensitive user data, application data, or system data is stolen.
    • Affected Component: KernelSU Modules (the malicious or vulnerable module).
    • Risk Severity: High
    • Mitigation Strategies:
      • Developer: If the application relies on specific KernelSU modules, thoroughly audit their source code (if available) for any suspicious network activity or data handling practices. Limit the data accessible to modules through careful API design and permission management. If the application does not interact with specific modules, this is primarily a user-level threat.
      • User: Only install modules from trusted sources. Monitor network activity for unusual connections.
  • Description: KernelSU itself, like any complex software, may contain vulnerabilities. An attacker could craft an exploit targeting a specific KernelSU vulnerability to gain root access or escalate privileges.
    • Impact: Complete device compromise.
    • Affected Component: KernelSU Core (the vulnerable component within KernelSU).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Developer: Monitor security advisories related to KernelSU. Encourage users to update to the latest version promptly. The application developer has limited direct control over this threat.
      • User: Keep KernelSU updated to the latest version. Subscribe to security mailing lists or forums related to KernelSU to stay informed about potential vulnerabilities.
  • Description: An attacker gains physical access to the device, or compromises a system component with sufficient privileges, and modifies a legitimate, pre-installed KernelSU module to inject malicious code. This differs from "Module Spoofing" as it targets an existing module, not a newly installed one.
    • Impact: Varies depending on the modified module's original function and the injected code. Could range from data theft to complete device compromise.
    • Affected Component: KernelSU Modules (specifically, a tampered pre-installed module).
    • Risk Severity: High
    • Mitigation Strategies:
      • Developer: If the application relies on specific pre-installed modules, implement integrity checks (e.g., checksum verification) at runtime to detect modifications. This is challenging to do reliably, but can provide an additional layer of defense. If the application does not interact with specific modules, this is primarily a user-level threat.
      • User: Regularly check for updates to pre-installed modules. Be aware of the risks of physical device compromise.