Les liens symboliques sur les modèles sont-ils un problème de sécurité, et si oui, pourquoi?

35

Magento recommande de ne pas utiliser les modèles via les liens symboliques:

Advanced > Developer > Template Settings > Allow Symlinks

Attention! L'activation de cette fonctionnalité n'est pas recommandée sur les environnements de production car elle représente un risque potentiel pour la sécurité.

Jusqu'à aujourd'hui, je ne vois aucun risque ici.

Quel est le risque?

— Fabian Blechschmidt
source

8

Je peux seulement imaginer que cela représente un risque pour les hôtes partagés, ce qui ne devrait pas être utilisé pour le commerce électronique en premier lieu.

— benmarks

3

@benmarks. Pourquoi ne mettez-vous pas cela comme une réponse?

— Marius

2

Très bonne question @Fabi!

— user487772

3

Je savais que d'autres proposeraient des réponses plus complètes. J'avais

— raison

3

@benmarks Le site Web a besoin d'un taux de réponse plus élevé par question de quelque manière que ce soit ;-)

— user487772 le

40

Les liens symboliques ne sont pas nécessairement mauvais.

Tout d'abord: si vous essayez d'ouvrir une cible de lien symbolique, les autorisations de fichier de la cible sont en vigueur. Si vous n'êtes pas autorisé à lire / écrire / exécuter la cible du lien symbolique, rien ne se passe.

Mais: vous pourrez peut-être exécuter des fichiers en dehors de la racine de votre document (c'est parfois ce que vous voulez en faire, n'est-ce pas?). Le problème peut se produire si un pas dans Vous êtes en train environnement suEXEC et ont un apacheou www-datautilisateur sur un hébergement mutualisé qui est chargé de servir des fichiers à partir de différents comptes. Votre utilisateur système n'est pas autorisé à accéder aux fichiers d'un autre client, mais l' apache/www-datautilisateur aura principalement des droits de lecture sur tous les comptes partagés. Cela peut être un scénario dans lequel un utilisateur peut accéder aux fichiers d'un autre utilisateur sur un hôte partagé. Pas avec votre propre utilisateur, mais en accédant au fichier via un navigateur avec l' apache/www-datautilisateur. En résumé: Dans ce scénario, vous pourrez accéder aux fichiers des autres utilisateurs => mauvais.

Le point négatif suivant est qu’un attaquant pourrait créer des liens symboliques, également vers des fichiers tels que / etc / passwd, ..., télécharger ces données et poursuivre avec ces informations. Cela ne concerne pas seulement le lien symbolique, mais également une configuration de serveur incorrecte (où l'accès à ces fichiers est strictement limité). Donc, ne pas utiliser de liens symboliques empêche certaines attaques plus possibles.

Le lien symbolique en soi ne constitue pas un risque pour la sécurité, mais un problème de configuration du serveur.

— Anna Völkl
source

5

Excellente explication -

— voici

2

Il convient probablement de le mentionner (bien qu'il y ait toujours une balance avec des bogues liés à la sécurité dans un environnement "répugnant à mettre à niveau") - Magento décourageant fortement les liens symboliques était lié à un exploit où des fichiers de modèle et de présentation en dehors du app/designdossier, lorsqu'ils étaient combinés avec d'autres exploits mineurs, pourrait être utilisé par un utilisateur administrateur pour l'élévation de privilèges et d'autres exploits de serveur.

— Alan Storm

1

Sur Apache httpd si vous voulez supporter les liens symboliques, considérez que cette SymLinksIfOwnerMatchoption est utilisée à la place de FollowSymlinks.

— hakre

15

oui, c’est la raison pour laquelle les serveurs Web ont aussi généralement une configuration "ne pas suivre les liens symboliques" ou au moins un "ne suivent que les liens symboliques de la cible avec le même utilisateur" C'est parce que webserver / php fonctionne généralement avec plus de droits que vous ne devriez y avoir accès.

Et comme les serveurs Web essaient généralement d’éviter des choses telles que visible / etc / shadow, c’est encore plus dangereux pour les modèles magento, car les modèles sont analysés via include (), ce qui vous permet d’éventuelles très fortes fuites de sécurité si vous n’avez pas le contrôle total sur vos fichiers.

Vous pouvez faire valoir qu'il existe d'autres problèmes alors, mais qui connaît vraiment tous les scénarios d'attaque potentiels, et la plupart du temps, c'est la combinaison de différentes failles de sécurité moins problématiques, qui conduisent à de grandes ruptures.

En outre, il y a quelque temps, un correctif de sécurité concernant le répertoire des supports et les liens symboliques a été créé. Vous devriez donc y rechercher des scénarios d'attaque possibles.

— Flyingmana
source

1

Si quelqu'un d'autre peut créer des liens symboliques sur votre serveur, vous avez déjà de gros problèmes. Je veux dire - voir le commentaire de Ben ci-dessous. Qui hébergerait un Magento dans un hébergement partagé? De nos jours, qui voudrait héberger quoi que ce soit dans un hébergement mutualisé et pourquoi? :)

— Sven

3

tout simplement parce qu'il y a des gens qui le font. Vous ne pouvez pas vous attendre à ce que les autres agissent de manière raisonnable. Il y aura toujours des gens qui font cela, et il y aura toujours des gens qui font des erreurs en ce qui concerne la configuration générale du serveur.

— Flyingmana

14

Je ne peux qu'imaginer que cela représente un risque pour les hôtes partagés, ce qui ne devrait pas être utilisé pour le commerce électronique en premier lieu.

— benmarks
source

1

Malheureusement, il est beaucoup utilisé.

— Piotr Kaminski

2

Selon les normes du Conseil de sécurité PCI, techniquement, le cloud public étant multi-locataire, même cela est considéré comme un "risque".

— philwinkle

4

Le correctif Magento SUPEE-9767 inclut APPSEC-1281: L'exécution de code à distance via des liens symboliques ; ainsi, les liens symboliques sur les modèles posent un problème de sécurité.

Type:
exécution de code à distance (RCE)

Gravité CVSSv3:
8.8 (Elevé)

Attaques connues:
oui. Les pirates désactivent la protection de la configuration après avoir obtenu un accès administrateur et téléchargent du code malveillant.

Description: l’
utilisation de l’option AllowSymlinks dans les paramètres de configuration peut permettre le téléchargement d’une image contenant du code malveillant. Bien que cette option soit désactivée par défaut, un attaquant disposant d'un accès pour stocker les paramètres de configuration peut l'activer et exécuter du code à distance.

Produit (s) concerné (s):
Magento CE avant 1.9.3.3 et Magento EE avant 1.14.3.3

Correction dans:
CE 1.9.3.3, EE 1.14.3.3, SUPEE-9767

Journaliste:
Wilko Nienhaus

— ehannes
source

0

Ne recommande pas d'autoriser. Je faisais face à des erreurs de chargement alors que les liens symboliques étaient activés.
Beaucoup de;

TypeError: $ .widget n'est pas une fonction

Je dois faire essayer 4-5 actualiser pour les pages chargées avec succès.
Après la fermeture, les ressources non déployées peuvent être chargées lentement pour la première fois mais les erreurs js disparues.

PS: Après avoir désactivé symlink, vous devez supprimer la copie déployée des fichiers après chaque modification de static.php, recopiez-la pour vous.

— rbostan
source

1

Désolé, je ne comprends pas - vous devez effectuer 4 à 5 actualisations avant que cela fonctionne? Qu'est-ce que cela a à voir avec les liens symboliques?

— Fabian Blechschmidt

Avant de désactiver les liens symboliques :) Désolé pour mon anglais.

— rbostan

Parlons-nous de magento2? Alors je comprends, que je ne comprends pas - aucune idée sur 2 pour le moment.

— Fabian Blechschmidt