Je peux donc essayer de faire un petit résumé. La faille impose que l'attaquant contrôle déjà un processus sur l'ordinateur cible. Alors la faille permet d'envoyer du code et de l'exécuter dans un autre processus. J'imagine que c'est restreint aux processus du même utilisateur, bien que la documentation de la fonction QueueUserAPC ne dise rien à ce sujet.
Alors quel est l'intérêt ? S'il s'agit d'autoriser un processus à exécuter du code dans un autre processus du même utilisateur, il paraît a priori limité. Mais si des permissions fines ont été réglées sur les processus, ce qui paraît plausible, alors il peut être intéressant de transmettre le code à exécuter à un processus qui a des permissions plus larges. Cela est expliqué par les auteurs ici :
For example, let’s say an attacker was able to persuade a user to run a malicious executable, evil.exe. Any kind of decent application level firewall installed on the computer would block that executable’s communication. To overcome this issue, evil.exe would have to find a way to manipulate a legitimate program, such as a web browser, so that the legitimate program would carry out communication on behalf of evil.exe.
Il s'agit bien d'un défaut de conception ici, mais je pense qu'il serait tout de même possible pour Microsoft de le corriger. Une possibilité serait de limiter la fonction QueueUserAPC par défaut au processus courant, et de ne l'autoriser vers d'autres processus que si le processus courant a été spécialement autorisé à cela (par exemple un débugueur).
Linux n'a pas d'équivalent à ma connaissance de QueueUserAPC. Les signaux sont un mécanisme beaucoup plus rudimentaire et difficile à exploiter (on envoie un numéro de signal, mais c'est le processus cible qui choisit quel code à exécuter en fonction du signal, au lieu de se laisser dicter docilement un pointeur de fonction...).
[^] # Re: Ca veut dire quoi "être prêt pour le desktop" ?
Posté par Antoine . En réponse au journal ON Y EST ENFIN !. Évalué à 3.
Je ne suis pas PasBillPasGates, mais j'ai parcouru la description technique : https://breakingmalware.com/injection-techniques/atombombing-brand-new-code-injection-for-windows/
Je peux donc essayer de faire un petit résumé. La faille impose que l'attaquant contrôle déjà un processus sur l'ordinateur cible. Alors la faille permet d'envoyer du code et de l'exécuter dans un autre processus. J'imagine que c'est restreint aux processus du même utilisateur, bien que la documentation de la fonction QueueUserAPC ne dise rien à ce sujet.
Alors quel est l'intérêt ? S'il s'agit d'autoriser un processus à exécuter du code dans un autre processus du même utilisateur, il paraît a priori limité. Mais si des permissions fines ont été réglées sur les processus, ce qui paraît plausible, alors il peut être intéressant de transmettre le code à exécuter à un processus qui a des permissions plus larges. Cela est expliqué par les auteurs ici :
Il s'agit bien d'un défaut de conception ici, mais je pense qu'il serait tout de même possible pour Microsoft de le corriger. Une possibilité serait de limiter la fonction QueueUserAPC par défaut au processus courant, et de ne l'autoriser vers d'autres processus que si le processus courant a été spécialement autorisé à cela (par exemple un débugueur).
Je note que la technique générale ne semble pas nouvelle, cf. DLL Injection using QueueUserAPC publié en 2013.
Linux n'a pas d'équivalent à ma connaissance de QueueUserAPC. Les signaux sont un mécanisme beaucoup plus rudimentaire et difficile à exploiter (on envoie un numéro de signal, mais c'est le processus cible qui choisit quel code à exécuter en fonction du signal, au lieu de se laisser dicter docilement un pointeur de fonction...).