Est-ce que sudo et .profile/.bashrc permettent une élévation triviale des privilèges ?

Tout ce que vous pouvez faire sur un compte compromis, un attaquant peut également le faire.

Fondamentalement, c'est parce que les fournisseurs Linux isolent les utilisateurs, pas entre des processus individuels s'exécutant sous le même utilisateur. Tout processus s'exécutant sous un utilisateur donné est considéré comme ayant des capacités équivalentes à tout autre processus s'exécutant sous cet utilisateur.

Est-il vrai que l'exécutable système sudo peut être contourné de cette manière ?

Oui, et d'autres manières aussi. Si vous élevez les privilèges à root sur un compte non privilégié compromis, vous compromettez root. Si vous supprimez les privilèges de root en utilisant su à un compte non privilégié, vous compromettez aussi root ! Vous ne pouvez jamais élever les privilèges en toute sécurité sur un compte non approuvé. Bien qu'il soit possible d'exploiter le système en utilisant PATH , il est également possible de détourner le processus bash lui-même pour renifler l'entrée de la clé. Désactiver l'exécution avec noexec n'est en outre pas utile car les interpréteurs (bash, python, perl, etc.) fonctionneront toujours. Le noexec l'option n'est pas et n'a jamais été conçue comme une fonctionnalité de sécurité, bien qu'elle soit régulièrement colportée comme telle.

Une liste incomplète des façons dont un attaquant pourrait détourner l'utilisation de sudo ou su :

• Utilisation du LD_PRELOAD variable sur le processus parent (par exemple bash ).

• Accrocher le processus parent avec ptrace() ou process_vm_writev() .

• Renifler ou injecter des frappes dans l'émulateur de terminal en utilisant le protocole X11.

• Créer des alias ou des fonctions pour encapsuler le sudo réel exécutable.

Je les ai expliqués plus en détail dans ma réponse à une autre question.

Pourquoi les systèmes Linux de bureau sont-ils, par défaut, configurés de manière si facilement exploitable ?

L'élévation des privilèges sur un compte non approuvé n'est pas quelque chose que vous êtes supposé faire. Sans oublier que Linux de bureau est une réflexion après coup dans le grand schéma de l'architecture générale * nix. C'est un échec du théâtre de sécurité répétant sans cesse le même mauvais conseil, pas un échec de l'architecture de sécurité de Linux elle-même. Les gens disent à plusieurs reprises d'utiliser sudo pour root car de nombreux nouveaux utilisateurs exécuteront à la place tout en tant que root, même leurs navigateurs ! Dans ce cas, il est préférable d'utiliser sudo . C'est nuisible dans le cas où l'utilisateur est déjà assez intelligent pour ne pas utiliser root pour tout.

Notez que sudo est hautement configurable et peut être conçu pour n'autoriser que certaines commandes. C'est là que ça brille vraiment. Vous pouvez configurer sudo pour vous permettre uniquement d'exécuter apt-get update en tant que root (avec ou sans mot de passe), et refuse tout le reste. Cela empêcherait en outre un attaquant de faire autre chose que... eh bien... faire une mise à jour logicielle.

Il est important de se rappeler que, même si vous le configurez pour autoriser uniquement l'exécution de certaines commandes en tant que root, vous pouvez toujours vous tirer une balle dans le pied si vous mettez en liste blanche des programmes qui ne sont pas conçus pour s'exécuter en tant que root via un utilisateur non approuvé. J'ai vu un exemple concret de quelqu'un essayant d'exécuter VeraCrypt de cette manière et j'ai expliqué pourquoi il n'est pas sécurisé. L'idée était que VeraCrypt peut être exécuté en toute sécurité en tant que root, il devrait donc être sûr d'utiliser sudo pour l'élever à la racine en tant qu'utilisateur non approuvé et non privilégié. Il s'avère que l'idée est erronée et permet une escalade de privilèges triviale !

La façon par défaut d'invoquer sudo ne devrait-elle pas s'assurer qu'il s'agit bien de l'exécutable fourni par le système (personne ne tapera /usr/bin/sudo à chaque fois) ?

Taper le chemin complet ne vous protégera pas ! Vous pouvez facilement créer une fonction qui contient un / de tête , et il remplacera le véritable exécutable. Même si l'exécutable s'est assuré qu'il est authentique et a tenté de vaincre le reniflage, un processus malveillant pourrait détourner le bash traiter et renifler les frappes indépendamment de sudo , ce qui le rend impossible à détecter de son point de vue.

$ function /usr/bin/sudo { echo 'hijacked!'; }
$ /usr/bin/sudo id
hijacked!

Dans un tel environnement, il semble que l'utilisation de sudo soit fondamentalement non sécurisée et il serait préférable d'activer la connexion en tant que root et de se connecter sur un TTY séparé.

C'est toujours l'affaire. Notez que même la connexion à un autre TTY n'est pas parfaitement sûre. Vous devez utiliser SAK, la combinaison Secure Attention Key, pour vous assurer que vous interagissez avec une véritable session de connexion (agetty ou logind , par exemple). SAK est une combinaison de touches que le noyau écoute (et ne peut donc pas être réprimée par l'espace utilisateur). Lorsqu'il le détecte, il tue tous les processus du TTY actuel, ce qui déclenche l'apparition de l'invite de connexion. Si vous êtes passé à un ATS authentique et sans compromis, cela ne fera que faire disparaître et réapparaître l'invite. Si vous êtes sur un TTY piraté, cela tuera le processus malveillant et ramènera l'authentique invite de connexion.