Discussion :

[Stéphane le calme]

Avast désactive mondialement son interpréteur JavaScript après avoir été prévenu de la présence d'une vulnérabilité,
qui aurait pu servir à lancer une attaque RCE

Tavis Ormandy est un white hat hacker qui est actuellement employé par Google au sein de son équipe Project Zero. Il a signalé à Avast une vulnérabilité dans l'un de ses émulateurs qui, en théorie, aurait pu être utilisée à mauvais escient pour une exécution de code à distance. Pour être plus précis, il a découvert qu’AvastSvc.exe, le processus principal de l’antivirus Avast qui s’exécute en tant que Système, contient une implémentation JavaScript/DOM complète sans sandbox.

« Ce service charge le moteur antivirus de bas niveau et analyse les données non fiables reçues de sources telles que le minifiltre du système de fichiers ou le trafic réseau intercepté.

« Bien qu'il soit hautement privilégié et traite les entrées non fiables par conception, il n'est pas dans un sandbox et a une faible couverture d'atténuation. Toutes les vulnérabilités de ce processus sont critiques et facilement accessibles aux attaquants distants.

« Alors .. ce n’est peut-être pas génial qu'il embarque un interpréteur JavaScript personnalisé .... ???? »

Il y a quelque jour, Tavis a proposé un shell interactif qui vous permet de tester l'interpréteur sous Linux pour analyser la vulnérabilité.

Building

Voici comment l'essayer, installez d'abord les dépendances.

Ubuntu

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ sudo apt install libreadline-dev:i386 libc6-dev-i386 gcc-multilib

Fedora

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ sudo yum install readline-devel.i686 glibc-devel.i686 libgcc.i686

Rendu à ce stade, vous pouvez cloner son référentiel.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ git clone https://github.com/taviso/avscript.git
$ cd avscript
$ git submodule update --init –recursive

Si tout semble correct, procédez au build et avscript devrait être prêt.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ make

Reproduire les vulnérabilités sous Windows

Tavis note que, pour des raisons de performances, Avast n'interprète pas tous les fichiers JavaScript rencontrés, il utilise une heuristique pour déterminer s'il est nécessaire. Il a trouvé que l'ajout du fichier javascript.txt inclus dans son référentiel est suffisant pour toujours déclencher l'heuristique.

Par exemple, si vous avez trouvé une vulnérabilité et que vous souhaitez la reproduire sur Windows, vous devez d'abord procéder comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ cat yourtestcase.js javascript.txt > ReproForWindows.js

Vérifiez maintenant qu'il fait toujours ce que vous attendez, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ ./avscript ReproForWindows.js
main(): File ReproForWindows.js` loaded, about to initialize interpreter...
Segmentation fault (core dumped)

Processus protégé

Le service Avast est un processus protégé, ce qui signifie que le débogage depuis l'espace utilisateur est délicat. Si vous avez configuré kd, vous pouvez simplement l'annuler, puis le débogage dans l'espace utilisateur fonctionne correctement.

Une solution rapide et facile qui fonctionne sur 32 bits est de le faire (notez que PatchGuard ne le permettra pas sur x64, mais vous pouvez faire quelque chose de similaire avec les commandes de point d'arrêt).

« Il existe également un paramètre sous "Dépannage" appelé "Activer l'autodéfense" qui doit être désactivé. Je crois que ce paramètre désactive le raccordement d'OpenProcess() dans le SSDT, où ils mettent normalement leur propre processus sur liste noire.

Vous devrez peut-être désactiver temporairement les "shields" dans l'interface utilisateur d'Avast pendant que vous vous connectez afin que les opérations du système de fichiers ne se bloquent pas lorsque le service est suspendu ».

La réaction d'Avast

Le 11 mars, Avast a annoncé qu'il avait décidé de désactiver cet émulateur à l'échelle mondiale : « Aujourd'hui, pour protéger nos centaines de millions d'utilisateurs, nous avons désactivé l'émulateur. La désactivation de l'émulateur n'affectera pas la fonctionnalité de notre produit AV, qui est basé sur plusieurs couches de sécurité ».

Les réactions n'ont pas tardé. L'utilisateur David I. Vadavidiv a répondu à la déclaration d'Avast en disant : « vos ingénieurs ont placé un interpréteur JS sans bac à sable, exécutant du code non approuvé par conception, dans votre processus AvastSvc.exe hautement privilégié. Ce n'est pas un bogue malheureux, facilement ignoré, c'est la preuve d'une incompétence totale concernant l'architecture de sécurité de base ».

Un autre s'est demandé : « s'il peut être désactivé instantanément sans affecter la fonctionnalité, pourquoi était-il là en premier lieu ? »

Un autre répondant au pseudonyme Todd Ross a écrit : « donc, quelqu'un trouve une vulnérabilité RCE, dans du code qui ne prétend en aucune façon limiter les capacités d'Avast, et vous pouvez la désactiver automatiquement à l'échelle mondiale ? En quoi n'êtes-vous pas un malware ? Cela ressemble à une porte dérobée flagrante pour moi ».

Et un autre de demander : « avoir une fonctionnalité qui peut être contrôlée avec un serveur est malveillant, mais avoir la possibilité d'analyser chaque fichier de votre système de fichiers en arrière-plan avec / sans le consentement de l'utilisateur ne l'est pas ? »

Source : Tavis Ormandy, Avast