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 des débordements de tampon et d'autres problèmes pouvant ê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 mémoire tampon, les erreurs d'utilisation après libération et d'autres problèmes de corruption de mémoire, ce qui entraîne des plantages ou l'exécution de code arbitraire. De plus, si une faille existe dans le composant de code natif, cela peut 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) pour atténuer les failles telles que les dépassements de tampon, les dépassements d'entiers et les attaques de chaîne de format. Privilégiez les bibliothèques comme Abseil, réputées pour leur qualité et leur sécurité. Dans la mesure du possible, envisagez d'adopter des langages à mémoire sécurisée comme 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, pour é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 large éventail de failles en activant des mécanismes de protection tels que la protection de la pile (Canary), la relocation read-only (RELRO), la protection de l'exécution des données (NX) et les exécutables indépendants de la position (PIE). Pratiquement, les options de compilation du NDK Android activent déjà toutes ces protections par défaut.

Pour vérifier la mise en œuvre 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 jouissent d'une bonne réputation dans la communauté de développement. Des ressources telles que l'index du SDK Google Play peuvent vous aider à identifier des bibliothèques réputées et fiables. Assurez-vous de mettre à jour les bibliothèques vers les dernières versions et recherchez de manière proactive les failles connues qui les concernent à l'aide de ressources telles que les bases de données d'Exploit-DB. Une recherche sur le 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