Comment dois-je déboguer l'erreur «Impossible de saisir le clavier. Un client malveillant peut espionner votre session. »

J'exécute une installation d'Ubuntu 14.04 que j'ai installée plus de 6 mois. Il y a environ une semaine, j'ai commencé à recevoir un message d'erreur:

Could not grab keyboard. A malicious client may be eavesdropping on your session.

Je ne l'ai jamais vu en revenant à mon ordinateur après avoir été absent pendant un bon moment (généralement la nuit). Plusieurs fois, il a empêché l'écran de se verrouiller après le délai défini (j'ai commencé à le verrouiller activement avant de partir).

J'utilise un clavier USB (Kinesis Advantage) directement connecté à un port USB sur la carte mère. J'utilise une souris sans fil ELECOM .

Je vais essayer de déconnecter le dongle de la souris avant de partir. Sinon, comment pourrais-je identifier s'il y a un client malveillant qui suit mes frappes ou s'il s'agit d'un problème de connectivité?

Voici comment résoudre votre mystère. L'objectif est davantage d'enseigner aux utilisateurs "comment pêcher" en utilisant les utilitaires standard d'Ubuntu pour fouiller dans les détails de tout processus sur leur système.

Étape # 1 (pour la curiosité principalement): identifiez le programme qui vous donne cette erreur:

# -- You may need to search under more dirs, YMMV
#    List files (incl. binaries) which contain the warning string

$ sudo grep -ral 'malicious client may be eavesdropping' /usr /bin /lib
/usr/lib/openssh/gnome-ssh-askpass

Dans mon env, le seul programme qui contient cette chaîne d'avertissement dans son binaire est gnome-ssh-askpass. Je pourrais rechercher s'il y a un bug déposé sur ce programme particulier, et même télécharger sa source apt-get source ssh-askpass-gnome(notez que le nom du package est différent du nom du programme) pour une inspection plus approfondie.

Cependant, je soupçonne que la cause profonde n'est pas un problème en gnome-ssh-askpass. Puisqu'il vous gnome-ssh-askpassdemande votre phrase secrète, ses développeurs ont simplement choisi de faire preuve de prudence lorsqu'ils ne saisissent pas le clavier, d'assumer le pire des cas et de faire en sorte que le message sonne de manière ultra-paranoïaque. Mais notez que taper votre mot de passe ou mot de passe dans une boîte de dialogue de site Web aléatoire par accident n'est probablement pas une bonne idée, donc en ce sens, les gnome-ssh-askpassdéveloppeurs ont fait le bon appel.

Récemment, de plus en plus de sites Web ont commencé à pratiquer l'affichage d'une fenêtre contextuelle, à effacer tout le reste en dehors de la boîte de dialogue contextuelle et à saisir activement le focus. Cela pourrait être la cause principale de l' gnome-ssh-askpasséchec de la saisie du clavier. Si votre navigateur est ouvert sur un tel site, fermer le navigateur ou s'éloigner du site Web agressif peut vous aider. Si cela est la cause, vous pourriez être intéressé par un paramètre de bureau empêchant les processus individuels de saisir le focus complet (bureau complet). Dans KDE par exemple, ce paramètre se trouve sous ( Paramètres système -> Comportement de la fenêtre -> Focus -> Prévention du vol de focus ). Si vous vous sentez vraiment paranoïaque, je recommanderais de le régler sur Highou Extreme. Bien sûr, cela peut également empêchergnome-ssh-askpasslui-même de saisir le clavier, ou plus précisément: saisir la Xmise au point.

Étape # 2: Identifiez les processus suspects:

Sachant que sous Unix, les périphériques apparaissent comme des fichiers uder /dev, la question suivante est de savoir quel périphérique représente "le clavier" dans la hiérarchie du système de fichiers. Nous pouvons utiliser l' lsofutilitaire (liste des fichiers ouverts) pour cela.

# look for processes holding devices open, filter out some common ones:
$ sudo lsof | grep /dev | grep -vE '/(null|urandom|zero)'

Notez que la plupart des processus qui maintiennent les périphériques ouverts dans un environnement de bureau typique maintiennent /dev/pts/<N>(un pseudo tty ) ouvert. Ce sont les "appareils" qui nous intéressent.

Dans un bureau graphique Linux typique, les processus ne parlent pas directement au clavier. Au lieu de cela, le Xprogramme (Xorg) contrôle tous les événements du clavier via un périphérique /dev/input/event<N>. Xutilise un gestionnaire d'événements (evdev) qui, entre autres, gère les événements du clavier. Vous pouvez également le vérifier en consultant le Xjournal: /var/log/Xorg.0.logoù keyboardest mentionné.

Les événements du clavier sont transmis du Xgestionnaire d'événements au processus sur lequel le pointeur de la souris se concentre à tout moment via l'entrée standard du processus qui est ouverte /dev/pts/<N>. Strictement parlant: un processus ne "saisit pas le clavier", le clavier est tenu par X, le processus n'a (ou n'attrape) que le "focus" ou l'attention, Xdonc Xpeut lui transmettre des événements de clavier via un descripteur de fichier stdin ouvert sur /dev/pts/<N>.

Étape # 3: quel processus le focus Xorg à un moment donné?

Comment comprendre quel processus a le focus à un moment donné? Voici une question askubuntu répondant à ceci:

découvrez l'application sous la souris

Le résumé de la réponse consiste à exécuter un script comme celui-ci dans un terminal tout en naviguant avec la souris:

#!/bin/bash
# Print the process tree of the window currently in focus.
# prereqs:
#   sudo apt-get install xdotool psmisc

while true; do
   pstree -spaul $(xdotool getwindowpid "$(xdotool getwindowfocus)")
   sleep 2
done

Étape # 4: approfondissez l'activité du processus

Une fois que vous avez identifié un processus suspect, la dernière étape consiste à enquêter sur ce processus individuel. Pour cela, vous pouvez vous tourner vers le système de /procfichiers Linux ( man 5 proc).

Presque tout ce que vous voudrez peut-être savoir sur un processus est disponible sous /proc. En fait, des programmes comme lsof(lister les fichiers ouverts), des débogueurs qui examinent l'état du processus et des utilitaires de listage de processus comme psou top, tous s'appuient sur /procce qui est rempli par le noyau, pour les données.

En utilisant, procvous pouvez trouver où le programme exécutable du processus se trouve sur le disque (par exemple, tout programme en dehors des répertoires système standard, en particulier s'il essaie de se cacher sous un nom "ne faites pas attention à moi" , peut être suspect) et en utilisant un débogueur ou un traceur d'appels système, vous pouvez examiner ce qu'ils font exactement au niveau des appels système (même si vous n'avez pas leur code source).

Les étapes 2 et 3 devraient vous donner tous les identifiants de processus PIDqui peuvent potentiellement lire votre clavier. Pour chacun de ces PIDS (notons chacun comme $pid), vous pouvez:

Mappez $ pid à sa ligne de commande complète:

cat /proc/$pid/cmdline

Mappez $ pid à son exécutable sur disque:

ls -l /proc/$pid/exe

Mappez $ pid à son répertoire de travail actuel:

ls -l /proc/$pid/cwd

Mapper $ pid à son environnement d'origine

cat /proc/$pid/environ | tr '\000' '\012'

Tracez $ pid (et ses enfants-procs) activité d'appel système en temps réel:

strace -f -p $pid

(Il y a plus: voir man 5 proc)

Si vous voyez un processus inconnu qui réagit à chaque pression de touche en le stockant dans un fichier (via write) ou en l'envoyant via le réseau à via sendto, vous avez peut-être trouvé un renifleur de clavier.

Vous pouvez également vérifier quels processus ont des points de terminaison réseau (tcp + udp) ouverts:

# See 'man netstat' for details on all options used below
$ sudo netstat -tunapee

Conclusion:

La cause la plus probable de l'erreur n'est pas un malware, mais plusieurs processus essayant d'obtenir le contrôle du clavier en même temps. L'un des deux est gnome-ssh-askpass(celui qui imprime l'erreur). L'autre peut être un navigateur ouvert sur un site avec une boîte de dialogue agressive d'acquisition de focus.

Même si vous avez en fait peu de logiciels malveillants installés à distance, la bonne nouvelle est que, puisque vous êtes sous Linux, tous les processus sont transparents pour vous de rechercher et d'inspecter. Il serait très difficile pour un malware de vraiment vous cacher ou de vous empêcher de le localiser facilement à l'aide des techniques ci-dessus, de tuer ses processus et de supprimer tous ses fichiers.

Mon problème était dû à deux gnome-ssh-askpassfenêtres simultanées . J'ai eu deux tâches rsync sur le même serveur via SSH, et les deux ont essayé de demander le mot de passe du certificat SSH. Les regrouper (et les enchaîner) les a résolus pour moi!