Ssortingngs su et ssh affiche le mot de passe. Est-ce une faille de security ou est-ce que je manque quelque chose?

Je suis actuellement fasciné par strace donc, étant nouveau, j'ai décidé de jouer un peu. Comme suggéré par le titre de la question, j'ai essayé à la fois strace su et strace ssh . Les deux commands affichent le mot de passe que j'ai tapé dans la sortie strace. su s'est plaint d'un mot de passe incorrect alors que ssh réussi à se connecter normalement.
Mes questions:

  • Est-ce une faille de security ou est-ce que je manque quelque chose?
  • Est-ce que su rapporte un mot de passe incorrect en tant que mesure de security car il a détecté qu'il était exécuté via strace ? Si oui, comment peut-il dire qu'il est invoqué par strace ? Vérifie-t-il /proc/self/cmdline ?
  • Combien de dégâts peuvent être causés par quelque chose comme
    alias su="strace -o /tmp/output.log su"

Ce n'est pas un défaut de security; vous êtes en mesure d'accélérer le process parce que c'est votre process. Vous ne pouvez pas simplement attacher strace à un process en cours d'exécution. Par exemple:

 $ sudo sleep 30 & [1] 3660 $ strace -p 3660 attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted 

su signale un mot de passe incorrect car il ne dispose plus de l'autorisation suffisante pour lire /etc/shadow . /etc/shadow est l'endroit où votre mot de passe est stocké, et il est défini de manière à ce que seul root puisse le lire pour des raisons de security. su a le bit setuid défini pour qu'il soit effectivement exécuté en tant que root, peu importe qui l'exécute, mais quand vous l'exécutez à travers strace qui ne fonctionne pas, il finit par s'exécuter sous votre count

Je ne suis pas sûr de ce que vous entendez par "combien de dégâts pourraient être causés". Comme vous l'avez vu, su ne fonctionne pas à partir de strace , donc vous allez le rendre non fonctionnel. Si vous voulez dire «quelqu'un pourrait-il utiliser ce code pour voler mon mot de passe?», Ils auraient besoin de définir des alias dans votre shell, ce qu'ils ne devraient pas avoir l'autorisation de faire, sauf si vous avez rendu vos files de connection inscriptibles ou similaires. S'ils avaient la permission de définir des alias, ils pourraient simplement alias su à une version patché qui enregistre votre mot de passe directement; il n'y a rien de spécial à propos de strace

Je crois que la raison pour laquelle vous voyez cela est parce que vous devez entrer les passwords su et ssh en text brut avant d'être hachés et traités. Lorsque vous exécutez strace , vous récupérez tous les appels système et intercepte le mot de passe en clair avant qu'il soit haché et traité. Ce n'est pas parce que le terminal n'affiche pas de text que vous n'entrez pas de text en clair.

http://blog.vpetkov.net/2013/01/29/sniffing-ssh-password-from-the-server-side/ suggère qu'il existe un problème de security potentiel en ce que si les attaquants ont des privilèges root sur un server exécutant openssh, ils pourraient recueillir les passwords des personnes qui ssh au server en exécutant strace sur le process «net»:

 ps aux | grep ssh | grep net | awk {' print $2′} | xargs -L1 strace -e write -p 

 Process 17681 attached – interrupt to quit write(4, “\0\0\0 \v”, 5) = 5 write(4, “\0\0\0\33thisismysupersecretpassword“, 31) = 31 write(3, “\345+\275\373q:J\254\343\300\30I\216$\260y\276\302\353″…, 64) = 64 Process 17681 detached 

Même si cela ne peut se faire qu'avec des privilèges root, mais c'est encore très dangereux: vous utilisez ssh depuis cette machine pour accéder à d'autres machines critiques, alors une personne malveillante rootera votre mot de passe ou votre phrase de passe sans que vous le sachiez.