Un peu bizarre, mais: c'est un risque de déni de service ou de divulgation potentielle d'informations.

Comme le préprocesseur de C inclura joyeusement tout fichier spécifié dans une directive #include , quelqu'un peut #include "../../../../. ./../../../../../dev/zero " et le préprocesseur essaiera de lire jusqu'à la fin de / dev / zero (bonne chance ).

De même, surtout si vous laissez les gens voir la sortie de leurs tentatives de compilation, quelqu'un pourrait essayer d'inclure divers fichiers qui peuvent ou non être présents sur votre système, et pourrait apprendre des choses sur votre machine. Combiné à une utilisation intelligente de #pragma poison , ils pourraient même apprendre des choses sur le contenu du fichier même si vous ne fournissez pas de messages d'erreur complets.

De même, les pragmas peuvent modifier beaucoup de comportement du préprocesseur, du compilateur ou de l'éditeur de liens, et sont spécifiés dans les fichiers source. Il n'y en a probablement pas un qui permet à quelqu'un de faire quelque chose comme spécifier le nom du fichier de sortie ou quelque chose comme ça, mais s'il y en a un, il pourrait être abusé pour remplacer des fichiers sensibles, ou se faire exécuter (en écrivant dans cron ou similaire). Il pourrait y avoir quelque chose de tout aussi dangereux. Vous devez vraiment faire attention à ne pas compiler du code non fiable.

Compilateurs bombes

C est un langage très puissant, et certaines des choses terribles que vous pouvez en faire vous choqueraient. Par exemple, vous pouvez créer un programme de 16 octets C qui prend 27 minutes à compiler , et quand il se termine finalement, il se compile en un 16 gigaoctets fichier exécutable. Et cela n'utilise que 16 octets. Lorsque vous prenez en compte le préprocesseur et les fichiers de code source plus volumineux, je suis sûr que vous pourriez créer des bombes de compilateur beaucoup plus volumineuses.

Cela signifie que toute personne ayant accès à votre serveur pourrait effectivement faire une DoS attaque sur votre serveur. Maintenant, pour être honnête, c'est beaucoup moins dangereux que d'avoir quelqu'un abuser d'une vulnérabilité dans le compilateur, ou d'inclure des fichiers sensibles pour obtenir des informations sur votre serveur (comme les autres répondants ont parlé).

Mais c'est encore une autre ennui possible que vous rencontrerez lors de la compilation de code arbitraire. Je suis sûr que vous pouvez définir une limite de temps pour toutes les versions et vous assurer de ne jamais stocker les fichiers binaires. Bien sûr, vous devez toujours le conserver sur le disque pendant sa création , donc si quelqu'un a hypothétiquement fabriqué une bombe de compilateur plus grande que votre disque dur, vous auriez des problèmes (si vous laissez la compilation terminer).

@ AndréBorie a raison. Les compilateurs et la configuration correspondante ne seront pas bien contrôlés pour les problèmes de sécurité, donc de manière générale, vous ne devriez pas compiler de code non fiable.

Le risque est qu'un débordement de tampon ou un certain type de vulnérabilité d'exécution de bibliothèque soit exploité, et le l'attaquant accède au compte utilisateur (espérons-le non root !) qui a exécuté le compilateur. Même un piratage non root est sérieux dans la plupart des cas. Cela pourrait être développé dans une question distincte.

Créer une VM est une bonne solution, pour contenir tous les exploits potentiels afin qu'ils ne puissent pas nuire au reste de votre application.

C'est mieux pour avoir un modèle de VM Linux, vous pouvez le lancer selon vos besoins avec un environnement de compilateur clean slate.

Idéalement, vous le jetteriez après chaque utilisation, mais cela peut ne pas être strictement nécessaire. Si vous isolez suffisamment bien la machine virtuelle et nettoyez correctement les données de réponse de la machine virtuelle, ce que vous devriez faire de toute façon; alors le pire qu'un hack puisse faire est DoS ou créer de faux temps de compilation. Ce ne sont pas des problèmes graves en soi; au moins pas aussi grave que d'accéder au reste de votre application.

Cependant, la réinitialisation de la VM après chaque utilisation (c'est-à-dire au lieu de quotidiennement) fournit un environnement globalement plus stable et peut améliorer la sécurité dans certains bords cas.

Certains systèmes d'exploitation proposent des conteneurs comme alternative aux VM. C'est peut-être une approche plus légère, mais les mêmes principes s'appliquent.

Oui, c'est dangereux: mais comme les gens l'ont dit, c'est possible. Je suis l'auteur et le mainteneur des compilateurs en ligne sur https://gcc.godbolt.org/, et je l'ai trouvé assez pratique pour le rendre sûr en utilisant une combinaison de:

• L'ensemble du site fonctionne sur une instance de VM avec peu d'autorisations pour faire quoi que ce soit. Le réseau est sévèrement limité avec seul le port 80 visible et ssh activé uniquement à partir des adresses IP de la liste blanche (la mienne).
• Chaque instance de compilation s'exécute dans un conteneur Docker jetable avec encore moins d'autorisation
• Le compilateur est exécuté à partir d'un script qui définit toutes les limites de processus (mémoire, temps CPU, etc.) à des limites basses pour éviter les bombes de code.
• Le compilateur est exécuté avec un LD_PRELOAD wrapper ( source ici) qui empêche le compilateur d'ouvrir des fichiers ne figurant pas sur une liste blanche explicite. Cela l'empêche de lire / etc / passwd ou d'autres trucs de ce genre (pas que cela aiderait tant que ça).
• En fin de compte, j'analyse les options de ligne de commande et n'exécute pas le compilateur si il y a quelque chose de particulièrement suspect. Ce n'est pas une vraie protection; juste un moyen de donner un message d'erreur "sérieusement, n'essayez pas ça" au lieu de LD_PRELOAD attraper un mauvais comportement.

Toute la source est sur GitHub, tout comme la source des images de conteneur de docker et des compilateurs et autres.

J'ai écrit un article de blog expliquant comment le toute la configuration est également exécutée.

Vous ne voudriez pas exécuter le compilateur en tant que root, même si j'ai vu cela se produire pour des raisons de "facilité et de commodité". Il serait trop facile pour un attaquant d'inclure quelque chose comme:

  #include "../../../../etc/passwd"#include" ../. ./../../etc/shadow"

et récupérer le contenu de ces fichiers dans le cadre du message d'erreur du compilateur.

Les compilateurs sont également des programmes comme tout le reste, et aura leurs bogues qui pourraient être vulnérables, il serait trop facile pour quelqu'un de simplement brouiller les programmes C et causer des problèmes.

La plupart des applications de sécurité se concentreront d'abord et avant tout sur la validation des entrées, malheureusement, définir une entrée «sûre et valide» pour un compilateur C est probablement là-haut avec le problème d'arrêt en termes de difficulté :)

Si vous autorisez un utilisateur à fournir une archive contenant le code, vous pouvez avoir des problèmes, pas exactement avec le compilateur mais avec l'éditeur de liens qu'il utilise;)

ld suit des liens symboliques s'ils pointent vers un fichier qui n'existe pas. Cela signifie que si vous compilez test.c vers la sortie a.out mais que vous avez déjà un lien symbolique nommé a.out dans votre répertoire pointant vers un fichier inexistant, l'exécutable compilé sera écrit à l'emplacement pointant vers le fichier (avec la limitation des droits d'utilisateur).

En pratique, un attaquant pourrait, par exemple, inclure une chaîne contenant une clé publique ssh dans son code et fournir un lien symbolique nommé a.out à ~ / .ssh / allowed_keys . Si ce fichier n'existe pas déjà, cela permet à l'attaquant de planter sa clé ssh dans la machine cible lui permettant un accès externe sans avoir à craquer un mot de passe.