La vulnérabilité de Log4j affecte-t-elle les utilisateurs d'Android ?

Déclaration du blogue de sécurité de Google sur la vulnérabilité de Log4j à partir de 2021-12-17 :

Android n'a pas connaissance d'un quelconque impact sur la plate-forme ou l'entreprise Android. Pour l'instant, aucune mise à jour n'est nécessaire pour cette vulnérabilité spécifique, mais nous encourageons nos clients à s'assurer que les dernières mises à jour de sécurité sont appliquées à leurs appareils.

Réponse originale/Information de base pour le contexte :

Q : Qu'est-ce que la vulnérabilité de Log4j (également connue sous le nom de Log4Shell) ?

JNDI est l'interface Java Naming and Directory. Il ne s'agit pas d'une application, mais d'une bibliothèque ou d'un service permettant la configuration de l'exécution. Log4j est une bibliothèque commune utilisée dans les applications serveur. Certaines chaînes, lorsqu'elles sont utilisées avec la version v2.x de la bibliothèque Log4j, peuvent invoquer l'API JNDI, ce qui peut entraîner une fuite d'informations sensibles et faciliter ainsi d'autres attaques. En fait, il s'agit d'une variante de la désinfection des entrées, sauf dans un utilitaire de journalisation qui, pour certaines raisons, a activé une fonction utile mais dangereuse.

Q : Assainissement de l'entrée ?

Vous avez probablement entendu parler de ce qu'on appelle Attaques par injection SQL où une chaîne spécialement conçue peut modifier les commandes données au moteur de la base de données. Exemple :

Ici, Robert '); DROP TABLE Students; -- peut être inséré dans cette requête insert into Students (id, name) values (42, $name) . Lorsque le logiciel se substitue directement $name avec le nom, cela devient cette requête/commande : insert into Students (id, name) values (42, Robert '); DROP TABLE Students; --) (insérer, puis supprimer le tableau, tout le reste est commenté).

Les développeurs doivent désinfecter l'entrée c'est-à-dire qu'il faut vérifier toutes les valeurs dangereuses possibles. Les développeurs peuvent par exemple échapper à la ' dans le nom avant de le substituer. Les développeurs utilisant SQL peuvent également utiliser des instructions préparées, dans lesquelles aucune substitution n'est effectuée.

Dans le cas de la vulnérabilité de Log4j, les développeurs s'attendaient à ce que la bibliothèque Log4j enregistre les valeurs de l'application/du serveur, y compris les chaînes d'entrée, en s'attendant à ce que ces chaînes soient en texte clair et ne puissent pas invoquer les API.

Q : Le système d'exploitation Android est-il vulnérable ?

R : Pas par cette vulnérabilité particulière - Android OS, bien que certaines parties soient écrites en Java, utilise sa propre bibliothèque de journalisation. Android OS n'utilise pas non plus le protocole/service JNDI et isole chaque application dans sa propre sandbox. Cela signifie que cet exploit JNDI particulier ne peut pas être utilisé sur Android, histoire a montré qu'Android n'est pas exempt de bogues et d'exploits, ce qui se traduit par une sécurité accrue à chaque version.

Q : Les applications Android sont-elles vulnérables ?

A : Cela dépend - Les applications Android peuvent soit exister uniquement sur un appareil, soit servir d'interface à un service en nuage. Les applications Android ont sans aucun doute leurs propres bogues. Sur les anciens appareils, les applications pouvaient accéder au logcat global, où des applications mal écrites peuvent afficher les noms d'utilisateur/mots de passe/autres clés, ce qui, bien qu'utile pour le débogage, n'est pas bon dans une application de production. Depuis Android 4.1, les applications Android ne peuvent accéder qu'à leurs propres journaux. .

Les serveurs dont dépendent les applications mobiles sont une autre histoire, comme l'ont souligné les médias.

Q : Mais qu'en est-il des applications Android qui utilisent Log4j ?

R : Sur un appareil, un développeur doit vraiment faire des efforts. à ajouter dans Log4j séparément. Comme vu aquí Log4j nécessite des classes Java, ce qu'Android ne prend pas en charge. Et bien qu'il existe un port pour Android il est basé sur Log4j version 1.x qui est EOL, il semble que cette version ait eu ses propres problèmes ce qui dissuaderait les développeurs Android. Alternativement, un développeur Android peut utiliser slf4j pour Android ou autre cales d'enregistreur activement développées en plus de la fonction de journalisation native du cadre Android.

Références :

Qu'est-ce que JNDI ? Quelle est son utilisation de base ? Quand est-il utilisé ?

https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/

Bandes dessinées de xkcd :  327