La plupart des systèmes Linux permettent-ils aux utilisateurs non root d'exécuter du code directement rootable?

Question

longue histoire si vous pouvez exécuter du code sur une boîte, il est généralement simple d'obtenir la racine

L'implication immédiate de cette citation (si elle est exacte) est que si vous exécutez un système multi-utilisateurs et n'essayez pas votre darndest pour empêcher tous les utilisateurs de créer des fichiers avec le jeu d'autorisations x, le système est aussi bon que compromis. Le corollaire est que l'exploitation d'un système multi-utilisateurs, comme ceux que l'on trouve généralement dans les universités, qui, par conception, permet à tous les étudiants de faire des exercices en C, C++, Assemblage, etc., est inutile, car tout étudiant peut facilement rooter ce système.

Étant donné que faire fonctionner des systèmes informatiques destinés à être utilisés par plus de personnes que leurs propriétaires n'est pas considéré comme inutile, et que les installations limitant les privilèges (gestion des droits des utilisateurs, sandbox, etc.) ne sont pas considérées comme inutiles, je doute en quelque sorte de ce genre de commentaires. Mais qu'est ce que je sais?

Est-il vrai que la plupart des systèmes Linux sont directement rootables par quiconque peut y exécuter du code?

forest · Answer

Non, ce n'est pas correct. Alors que l'on peut discuter de la difficulté relative de trouver et d'exploiter les vulnérabilités 0day sur Linux lorsque vous avez un accès local, l'architecture de sécurité lui-même d'un système Linux moderne (avec un MMU ) est conçu pour isoler différents utilisateurs et empêcher l'escalade de privilèges. Un utilisateur non root ne peut pas se rooter sans l'autorisation appropriée sans exploiter une vulnérabilité existante, et ces vulnérabilités d'élévation de privilèges sont corrigées très rapidement dès qu'elles sont découvertes.^*

Il est cependant possible d'abuser du facteur humain et de prendre racine en exploitant les idées fausses omniprésentes dans la profession d'administrateur système. Bien sûr, cela repose sur la mauvaise compréhension par l'administrateur système de l'architecture de sécurité du système qu'il gère. Une liste d'exemples non exhaustive:

Élever les privilèges avec Sudo ou su d'un utilisateur non privilégié mais non fiable.¹
Inciter un administrateur système à exécuter ldd sur un exécutable statique malveillant en tant que root.²
Abuser d'un binaire mal installé.
Passer à un utilisateur inférieur depuis root, permettant une attaque pushback TTY.^{4 5}

_{* Bien que cela soit apparemment vrai, de nombreux déploiements ne se mettent pas à jour assez fréquemment, ce qui rend les systèmes de production en direct vulnérables aux bogues connus. Une mise à jour disponible ne garantit pas l'installation d'une mise à jour.}

James Snell · Answer

Pour reformuler la citation - Des vulnérabilités d'escalade de privilèges ont existé et continueront d'être trouvées ou créées.

Au cours de la dernière semaine, nous avons ce petit doozy dans SystemD ; qu'allons-nous avoir la semaine prochaine, sera-t-il corrigé à temps, et quelle est la qualité de votre régime de correction?

Vous devez supposer qu'il est possible qu'un attaquant qui peut s'exécuter sur une boîte puisse probablement obtenir un accès root à leur instance de système d'exploitation à un moment donné, quel que soit le système d'exploitation en jeu. Le caractère "simple" d'une telle tâche est peut-être discutable, mais si un utilisateur peut exécuter du code arbitraire, cela lui donne beaucoup de portée.

Dmitry Grigoryev · Answer

Exploiter une vulnérabilité d'élévation de privilèges est déjà assez difficile, le faire tout en étant certain de ne pas laisser de trace est beaucoup plus difficile. Un utilisateur de Android essayant de rooter son téléphone peut continuer à essayer un exploit après l'autre, sans se soucier ni avoir à couvrir ses traces. Un élève essayant à plusieurs reprises d'abuser de Sudo ou de répandre les fichiers exécutables fishy à travers le partage de fichiers seront probablement remarqués et réprimandés ou expulsés.

Soit dit en passant, la façon n ° 1 d'obtenir un accès root dans un paramètre multi-utilisateur consiste à attendre qu'un utilisateur privilégié quitte le poste de travail en oubliant de le verrouiller. J'ai vu cela dans deux universités sur trois auxquelles j'ai assisté. Cependant, la même remarque à propos de ne pas se faire prendre s'applique.

odo · Answer

Je pense que "simplement" signifie "sans artifices humains et autres techniques sociales". Donc, la réponse est - Oui, si les systèmes contiennent des 0 jours non corrigés, ce qui entraîne une escalade des privilèges.

Il peut s'agir d'un jour 0 au niveau de l'application. Par exemple, s'il existe des exécutables appartenant à root avec des autorisations setuid qui pourraient affecter des fichiers arbitraires. La dernière référence est Xorg . Vous pouvez rechercher des vecteurs potentiels comme celui-ci: find / -user root -perm -4000 -print 2>/dev/null. Un autre exemple - service système comme systemd mentionné ci-dessus.

Ou ce pourrait être un jour 0 au niveau du noyau. Ils sont assez rares mais plus bruyants car leur couverture est beaucoup plus large. Une bonne référence est Vache sale .

Ci-dessus est vrai s'il y a une absence de contrôles d'accès obligatoires activé qui peut empêcher l'exécution de certains exploits.

Ou cela pourrait même être une attaque au niveau du démarrage. Secure boot est votre ami alors.