Pourquoi «AcceptEnv *» est-il considéré comme non sécurisé?

Dans /etc/ssh/sshd_config, il existe une option appelée AcceptEnvqui permet au client ssh d'envoyer des variables d'environnement. Je dois pouvoir envoyer un grand nombre de variables d'environnement. Celles-ci changent à chaque connexion du client, donc les mettre dans un script de connexion sur le serveur serait plus difficile.

J'ai lu que ce "AcceptEnv *"n'était pas sûr. Je voudrais comprendre pourquoi avant d'essayer d'obtenir une liste de toutes les variables d'environnement qui sont tentées d'être définies pour y être placées.

Pourquoi est-il considéré comme peu sûr? Puis-je obtenir un exemple?

— TheDauthi
source

Réponses:

L'activation du traitement de l'environnement peut permettre aux utilisateurs de contourner les restrictions d'accès dans certaines configurations à l'aide de mécanismes tels que LD_PRELOAD.

Toutes les versions des pages de manuel de sshd_config ne le mentionnent pas. Si vos variables d'environnement sont modifiées au préalable et que certains processus privilégiés sont exécutés avec de nouvelles bibliothèques spécifiées par cela, des problèmes peuvent survenir.

Jetez un œil à http://www.dankalia.com/tutor/01005/0100501004.htm et recherchez "LD_PRELOAD Exploit". Désolé, la page n'a pas de liens d'ancrage.

Voir aussi cette question StackOverflow, " Quelle est l'astuce LD_PRELOAD? "

La définition de variables d'environnement après la connexion est correcte, mais lorsque ces variables sont interprétées par le démon ssh comme défini par AcceptEnv, de mauvaises choses peuvent se produire.

— Jeff Ferland
source

En quoi est-ce différent de celui où ils ont défini les variables manuellement après la connexion?

— Joseph Garvin

@JosephGarvin, certains systèmes ont des shells restreints ou n'autorisent qu'une seule commande spécifique, de sorte que "ils" ne peuvent pas . Le souci est donc de fournir un moyen de contourner ces mesures de sécurité.

— Charles Duffy

N'acceptez pas les variables d'environnement:

Voir l'exploit Shellshock qui est sorti récemment .. si vous acceptez les variables d'environnement, vous ouvrez un exploit vraiment désagréable.

— John Hunt
source

Vous répandez la peur OMI. Si vous êtes inquiet, pourquoi ont-ils accès à SSH? Et btw vous ne pouvez pas les empêcher de définir des variables d'environnement une fois qu'elles sont dans le shell ou même dans des fonctions. Cet exploit concerne l'accès non autorisé au shell via des choses comme nginx, et non l'accès au shell autorisé.

— Jordon Bedwell

Quoi qu'il en soit, vous acceptez au moins un env. variable nommée TERM. Il peut y avoir des besoins valides pour accepter d'autres variables comme IMPRIMANTE, EDITEUR, PAGER, ...

— ibre5041

@JordonBedwell, toutes les connexions SSH ne sont pas autorisées pour l'accès au shell. J'ai plusieurs systèmes où il existe des comptes pour lesquels la seule authentification est avec une clé SSH qui ne permet d'exécuter qu'une seule commande spécifique (avec l'identité du propriétaire de cette clé et d'autres détails, intégrés).

— Charles Duffy

... cela dit, je conviens qu'à partir de 2017, ShellShock est très exagéré ici. Avec les implémentations actuelles, la génération d'une fonction exportée nécessite un contrôle non seulement sur la valeur d' une variable d'environnement , mais aussi sur son nom (et le processus d'évaluation des fonctions exportées au démarrage du shell n'est plus lui-même sujet aux attaques par injection).

— Charles Duffy