Utilisation de code natif

Catégorie OWASP : MASVS-CODE : qualité du code

Présentation

Les applications Android peuvent tirer parti du code natif écrit dans des langages tels que C et C++ pour des fonctionnalités spécifiques. Toutefois, lorsqu'une application utilise Java Native Interface (JNI) pour interagir avec ce code natif, elle s'expose potentiellement à des failles telles que les dépassements de tampon et d'autres problèmes qui peuvent être présents dans l'implémentation du code natif.

Impact

Malgré des impacts très positifs tels que l'optimisation des performances et l'obscurcissement, l'utilisation de code natif dans les applications Android peut avoir des conséquences négatives sur la sécurité. Les langages de code natif tels que C/C++ ne disposent pas des fonctionnalités de sécurité de la mémoire de Java/Kotlin, ce qui les rend vulnérables aux failles telles que les dépassements de tampon, les erreurs d'utilisation après libération et d'autres problèmes de corruption de la mémoire, entraînant des plantages ou l'exécution de code arbitraire. De plus, si une faille existe dans le composant de code natif, elle peut potentiellement compromettre l'ensemble de l'application, même si le reste est écrit de manière sécurisée en Java.

Stratégies d'atténuation

Conseils de développement et de codage

  • Consignes de codage sécurisé : pour les projets C/C++, respectez les normes de codage sécurisé établies (par exemple, CERT, OWASP) afin d'atténuer les failles telles que les dépassements de tampon, les dépassements d'entiers et les attaques par chaîne de format. Privilégiez les bibliothèques telles qu'Abseil, reconnues pour leur qualité et leur sécurité. Dans la mesure du possible, envisagez d'adopter des langages sécurisés en mémoire tels que Rust, qui offrent des performances comparables à celles de C/C++.
  • Validation des entrées : validez rigoureusement toutes les données d'entrée reçues de sources externes, y compris les entrées utilisateur, les données réseau et les fichiers, afin d'éviter les attaques par injection et d'autres failles.

Renforcer les options de compilation

Les bibliothèques natives utilisant le format ELF peuvent être renforcées contre un éventail de failles en activant des mécanismes de protection tels que la protection de la pile (Canary), la relocalisation en lecture seule (RELRO), la prévention de l'exécution des données (NX) et les exécutables indépendants de la position (PIE). Les options de compilation NDK Android activent déjà toutes ces protections par défaut.

Pour vérifier l'implémentation de ces mécanismes de sécurité dans un binaire, vous pouvez utiliser des outils tels que hardening-check ou pwntools.

Bash

$ pwn checksec --file path/to/libnativecode.so
    Arch:     aarch64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

Vérifier que les bibliothèques tierces ne sont pas vulnérables

Lorsque vous choisissez des bibliothèques tierces, privilégiez celles qui ont une solide réputation dans la communauté des développeurs. Des ressources telles que l'index des SDK Google Play peuvent vous aider à identifier des bibliothèques fiables et réputées. Assurez-vous de maintenir les bibliothèques à jour avec les dernières versions et recherchez de manière proactive les failles connues qui leur sont associées à l'aide de ressources telles que les bases de données d'Exploit-DB. Une recherche Web à l'aide de mots clés tels que [library_name] vulnerability ou [library_name] CVE peut révéler des informations de sécurité critiques.

Ressources