Une applet Java "simple" s'exécute dans un contexte de sécurité très restreint et n'est en mesure d'utiliser que le CPU, la RAM (jusqu'à une certaine limite), afficher son interface, recevoir les événements clavier/souris et communiquer en http/s avec son serveur d'origine - celui depuis lequel l'applet a été téléchargée.
Pour faire plus, il faut signer l'applet et de fournir un fichier de permissions. L'utilisateur se voit alors demander s'il fait confiance à l'entité à l'origine de la signature - bien sûr s'offre à lui le choix "oui ou non" - mais sur quoi le cerveau lambda va-t-il cliquer par défaut sans même lire ?
L'exploit dont on parle permet de court-circuiter cette contrainte de signature et l'applet s'exécute alors sans SecurityManager comme s'il s'agissait d'une application Java "de bureau" avec l'accès à toutes les ressources: systèmes de fichiers, réseau, possibilité d'exécuter du code natif… Mais cette exécution reste sous l'identité de l'utilisateur qui exécutait le navigateur et la JVM. Difficile donc de faire le rapprochement avec les setuid/setgid qui permettent de passer root.
Voilà, donc l'exploit peut servir de porte d'entrée pour un vers, un virus ou un rootkit - qui devra obligatoirement profiter d'une autre faille au niveau du système d'exploitation pour élever son niveau de privilège du "simple utilisateur" qui tournait le navigateur vers "administrateur".
Bien sûr, désinstaller Java est l'option idéale pour ceux: dont le système n'est pas à jour, qui se loggue en root pour naviguer sur internet, qui ont une règle sudo ALL=(ALL) NOPASSWD, mais à mon avis ça ne les protège pas plus outre mesure.
Sinon ironie à part, mon opinion est clairement qu'un utilisateur Linux dont le poste est à jour et qui n'a pas tout le temps son accès sudo autorisé (attention à l'expiration du mot de passe !) n'a pas grand chose à craindre de ce genre d'exploit sauf peut-être si l'attaquant code un effacement récursif complet du répertoire home… mais bon, les backups sont là pour survivre à ce genre d'épreuves qui forgent le caractère.
# Quelques précisions nécessaires
Posté par Yves Martin . En réponse au journal Java ça pue c'est trop libre.. Évalué à -3.
Une applet Java "simple" s'exécute dans un contexte de sécurité très restreint et n'est en mesure d'utiliser que le CPU, la RAM (jusqu'à une certaine limite), afficher son interface, recevoir les événements clavier/souris et communiquer en http/s avec son serveur d'origine - celui depuis lequel l'applet a été téléchargée.
Pour faire plus, il faut signer l'applet et de fournir un fichier de permissions. L'utilisateur se voit alors demander s'il fait confiance à l'entité à l'origine de la signature - bien sûr s'offre à lui le choix "oui ou non" - mais sur quoi le cerveau lambda va-t-il cliquer par défaut sans même lire ?
L'exploit dont on parle permet de court-circuiter cette contrainte de signature et l'applet s'exécute alors sans
SecurityManagercomme s'il s'agissait d'une application Java "de bureau" avec l'accès à toutes les ressources: systèmes de fichiers, réseau, possibilité d'exécuter du code natif… Mais cette exécution reste sous l'identité de l'utilisateur qui exécutait le navigateur et la JVM. Difficile donc de faire le rapprochement avec les setuid/setgid qui permettent de passerroot.Voilà, donc l'exploit peut servir de porte d'entrée pour un vers, un virus ou un rootkit - qui devra obligatoirement profiter d'une autre faille au niveau du système d'exploitation pour élever son niveau de privilège du "simple utilisateur" qui tournait le navigateur vers "administrateur".
Bien sûr, désinstaller Java est l'option idéale pour ceux: dont le système n'est pas à jour, qui se loggue en
rootpour naviguer sur internet, qui ont une règle sudoALL=(ALL) NOPASSWD, mais à mon avis ça ne les protège pas plus outre mesure.Sinon ironie à part, mon opinion est clairement qu'un utilisateur Linux dont le poste est à jour et qui n'a pas tout le temps son accès sudo autorisé (attention à l'expiration du mot de passe !) n'a pas grand chose à craindre de ce genre d'exploit sauf peut-être si l'attaquant code un effacement récursif complet du répertoire
home… mais bon, les backups sont là pour survivre à ce genre d'épreuves qui forgent le caractère.