Est-il prudent de compiler un morceau de code source à partir d'un inconnu au hasard? [fermé]

Supposons que je vérifie le code envoyé par les candidats pour prouver leurs compétences. Clairement, je ne veux pas exécuter les exécutables qu’ils envoient. Pas si clairement que je préfère ne pas exécuter le résultat de la compilation de leur code (par exemple, Java permet de masquer le code exécutable dans les commentaires ).

Qu'en est-il de la compilation de leur code? Je veux des avertissements pour le compilateur, mais que se passe-t-il si leur code contient des séquences de caractères intelligentes qui exploitent mon compilateur et que celui-ci compromet ma machine?

Lorsque je recherche Google sur les "vulnérabilités du compilateur", les résultats que je reçois concernent essentiellement l'optimisation du compilateur et l'émission de code, ainsi que la question de savoir si le code émis est aussi sécurisé que le code source d'origine était censé l'être.

Les compilateurs sont-ils généralement validés pour s’assurer qu’ils ne compromettent pas la machine de l’utilisateur lors de la compilation d’un morceau de code intelligent? Est-il prudent de compiler un morceau de code d'un inconnu?

Ça dépend.

Ce fichier makefile pourrait supprimer votre répertoire personnel:

all:
    rm -rf ~

Donc, si vous devez utiliser un outil (comme cmake ou un système makefile), alors ce n’est pas sûr. Cela dépend de la malveillance du codeur.

De l’autre côté, les compilateurs sont programmés par des utilisateurs, ils ont donc des bogues. Donc, il est peut-être possible que quelqu'un trouve un moyen d'exécuter du code malveillant pendant la compilation.

Comme suggéré dans les commentaires, utilisez une machine virtuelle si vous voulez vous assurer qu'aucune chose amusante n'est apportée à votre machine.

Je suis presque sûr que quelque part dans l'entreprise, il y a des types intelligents qui ont déjà créé un tel hack pour un langage spécifique et une version du compilateur. Mon endroit préféré pour chercher quelque chose comme ceci serait probablement le concours international C obscurci - (je ne sais pas s'il y a quelque chose de comparable pour Java). Cependant, en réalité, à quel degré considérez-vous le risque, en supposant que

• le postulant fait une impression plausible sur vous, il veut vraiment le poste dans votre entreprise (et non un procès)

• le mec ne sait pas combien de critiques sont faites chez vous

• il / elle ne sait pas quelle version exacte du compilateur vous utilisez

• il / elle ne sait pas si vous utilisez un environnement virtuel ou un compilateur en ligne, juste pour être sûr

• vous n'acceptez pas les programmes trop volumineux pour être examinés efficacement

• vous ne compilez rien qui vous semble suspect

• Il n'y a pas beaucoup de gens dans le monde qui sachent réellement accomplir techniquement une telle tâche (et googler seul ne vous donnera pas de "ref rapide" ou de tutoriel à ce sujet, comme vous l'avez déjà découvert par vous-même).

Donc, bien que la compilation ne soit pas "totalement sûre" en théorie, à mon humble avis, en réalité, le risque est extrêmement faible que votre "compilateur soit utilisé".

Nous devons distinguer plusieurs cas:

1. Un bug dans le compilateur. Comme tout programme complexe, un compilateur peut avoir des bogues, et l'un de ces bogues peut être exploitable.
2. Un cheval de Troie. L’attaquant peut vous amener à exécuter du code arbitraire dans le cadre du processus de compilation. A Makefile, a build.xml, un configurescript shell, etc. Techniquement, cela n'est pas dû à la compilation du code de l'attaquant mais à la configuration de l'environnement de compilation.
3. Langages permettant au code arbitraire de s’exécuter au moment de la compilation. Le langage macro de Scala est Scala, le langage macro de Common Lisp est Common Lisp, le langage macro de Template Haskell est Haskell. Scala a également des plugins de compilateur, qui sont encore une fois du code Scala arbitraire qui s'exécute au moment de la compilation. F # a des fournisseurs de types.
4. Langages permettant le calcul de Turing au moment de la compilation. Les systèmes de types Scala et Haskell sont Turing-complete, de même que les modèles C ++. Vous pouvez demander au compilateur d'effectuer des calculs de Turing arbitraires au moment de la compilation, y compris, sans toutefois s'y limiter, des boucles infinies. Notez que Turing-complete signifie uniquement que vous pouvez calculer chaque fonction calculable par Turing, cela ne signifie pas que vous pouvez accéder au système de fichiers ou à quelque chose comme ça. Mais, vous pouvez créer un programme dont la compilation prendra beaucoup de temps.
5. Très longs temps de compilation. Par exemple, les règles de résolution de surcharge de C # sont si complexes que vous pouvez coder tout problème 3-SAT en résolution de surcharge de C #. 3-SAT est bien sûr célèbre NP-complet. En d'autres termes, selon nos connaissances actuelles, il est impossible de trouver un algorithme efficace pour la résolution de surcharge en C #. Vous ne pouvez pas faire une compilation infiniment longue, mais il ne faut pas beaucoup de programme pour que la compilation dure plus longtemps que la vie de l'univers, ce qui est pratiquement la même chose.

# 4. et # 5. entraînera au maximum un déni de service. Pratiquement, C ++ et compilateurs Scala limitent la quantité de récursivité vous pouvez le faire, de sorte qu'il ne soit pas réellement possible d'écrire une boucle infinie. En Scala, ce n'est qu'une contrainte d'implémentation, mais en C ++, c'est explicitement autorisé par la spécification, je crois.

# 2. est techniquement hors de propos parce que la question portait sur la compilation de code ne fonctionnant pas (OTOH, il y a une question philosophique profonde: si la vérification de type d'un programme Haskell peut effectuer un calcul de Turing arbitraire, s'agit-il d'une compilation ou d'un programme?)

#1. est peu probable. D'une part, les compilateurs de production étant très complexes, le risque de bogues est élevé. D'autre part, ils sont rigoureusement testés. Après tout, la gestion des entrées mal formées fait partie de la description de travail d'un compilateur. Même s'ils ne sont pas testés, ils seront tout de même bombardés de code mal formé. Consultez quelques questions de StackOverflow pour obtenir des exemples de ce que les gens indésirables jettent sur leurs compilateurs!

Cela nous laisse avec 3. Certains compilateurs peuvent limiter le type d'accès du système au code temporel de compilation, mais pour certains cas d'utilisation, un accès complet est inévitable. Les fournisseurs de types de F #, par exemple, ont pour objectif de "simuler" des types synthétiques pour les données dont le système de types ne correspond pas à celui de F #, afin que vous puissiez interagir avec, par exemple, un service Web doté d'un schéma WSDL dans un fichier fortement typé. mode. Toutefois, pour ce faire, le fournisseur de types doit avoir accès à la ressource de schéma WSDL sur le système de fichiers ou sur le Web. Il doit donc disposer d'un accès au système de fichiers et au réseau.

Alors, est-ce sécuritaire? Techniquement non. Est-ce risqué? Pas vraiment.

Il ne devrait y avoir aucun risque que de compiler le code. En théorie, il pourrait y avoir un bug dans le compilateur dont un pirate informatique habile pourrait tirer parti mais qui semble extrêmement improbable.

Sachez que la construction peut être dangereuse. Par exemple, en C #, 'build event' vous permet de spécifier des lignes de commande arbitraires à exécuter avant et après la construction, ce qui est évidemment dangereux et beaucoup plus facile à exploiter que le dépassement de la mémoire tampon dans le code du compilateur.

Au lieu de spéculer, je me suis donné la peine de faire quelques recherches sur ce sujet avant de répondre, en allant à la ressource la plus fiable que je puisse penser ( CVE Details ). Cette liste complète des failles de sécurité divulguées publiquement est probablement la meilleure solution pour évaluer le niveau de menace de divers types de logiciels.

Bien sûr, je n’ai pas pris le temps de lire tout le matériel disponible, mais j’ai choisi quelques compilateurs «primaires», des IDE et des éditeurs de texte pour élaborer un exemple d’évaluation de la menace. Si vous êtes sérieux au sujet de l’exécution d’un logiciel, vous devriez au moins savoir quelles menaces existent. Notez également que les logiciels plus anciens sont généralement plus dérangeants que les logiciels plus récents, il est donc idéal d'exécuter la dernière version de ce que vous utilisez.

Premièrement, nous pouvons jeter un coup d’œil sur divers éditeurs de texte. Il semble que les meilleurs éditeurs sont les plus simples. Vi si vous utilisez un shell Linux ou Notepad si vous utilisez Windows. Quelque chose sans capacités de formatage, sans analyse, juste une visualisation directe des données et une fin automatique de l'analyse si un seul caractère est en dehors du schéma de codage actuel. Même Notepad ++ a eu une poignée de vulnérabilités. Évitez tout ce qui est complexe lorsque vous affichez des fichiers non fiables.

Deuxièmement, nous pouvons regarder les IDE. Si vous choisissez d'ouvrir le fichier dans un IDE, sachez que certains IDE ont eu des bogues signalés. Apparemment, Visual Studio a eu des exploits disponibles via le mécanisme d'extensions, donc l'ouverture d'une solution peut être problématique. Éviter les IDE évite toute une classe de problèmes entre vous et le code non approuvé. Rester avec VI semble beaucoup plus sûr.

Troisièmement, nous pouvons regarder les compilateurs réels. J'en ai parcouru quelques-uns, notamment Adobe, Microsoft, Java et le C / C ++ de GNU, et j'ai constaté qu'en général, compiler du code (et même construire , en supposant l'absence de fichier de création personnalisé) est relativement sûr, mais chacun de ces compilateurs le fait ou l'a fait. avoir des exploits de sécurité qui pourraient résulter de l'exécution des fichiers binaires compilés. En d'autres termes, ils ne pourraient pas gérer votre système simplement en compilant, mais ils pourraient le faire en exécutant du code.

Donc, en conclusion, en supposant que la méthode de livraison n'ait pas déjà détourné votre système (par exemple, votre client de messagerie a été piraté, ou la clé USB sur laquelle il est entré a été infectée ...), la lecture du code source et la compilation du code source sont probablement sûres . En recherchant votre logiciel spécifique, vous pouvez le rendre encore plus sûr en validant, par exemple, que le fichier se trouve dans la page de code appropriée, etc. Le code ne doit être exécuté que sur du matériel dont vous ne vous souciez tout simplement pas. Pas une machine virtuelle, mais un ordinateur complètement différent physiquement, sans accès réseau, sans fichiers sensibles ni périphériques externes. Même si vous pensez comprendre le code, de simples recherches montrent que même les compilateurs ont des bogues qui pourraient permettre à un exploit de dépassement de tampon caché de se faufiler derrière et d’exécuter du code arbitraire, mais uniquement si vous choisissez de le faire.exécuter ou déboguer le programme. La compilation réelle devrait être en sécurité.

Eh bien, je commencerais par "réviser leur code". Pourquoi est-il nécessaire d'exécuter le code?

En dehors de cela, il y a beaucoup de compilateurs en ligne où vous pouvez simplement insérer du code et le compiler et / ou l'exécuter. Vous pouvez en faire une exigence: il compile ceci et ce compilateur en ligne.

Voici un exemple de page avec des compilateurs en ligne: Compilateurs en ligne

Le code de révision pour un entretien d'embauche ne devrait de toute façon pas être aussi grand que pour que vous ne compreniez pas ce qui se passe.

Les compilateurs sont-ils généralement validés pour s’assurer qu’ils ne fonctionneront pas sur la machine utilisateur lors de la compilation d’un morceau de code astucieux?

En général, ils sont trop complexes et souvent écrits en utilisant des langages dans lesquels il n'est pas pratique de prouver cette propriété.

Peut-être pas avec cette intention spécifique, mais la notion de compilateurs de test fuzz est au moins connue ( LLVM peut maintenant effectuer un test fuzz lui-même ). Les tests destinés à intercepter une entrée qui bloque le compilateur à cause de bogues du compilateur auront également tendance à révéler des failles exploitables.

Naturellement, il vous faudrait déterminer si le compilateur qui vous intéresse est testé ou non-fuzz pour détecter les pannes potentielles, et si les bogues ainsi trouvés sont réellement corrigés. La règle de base est que s'il existe des collisions plus graves que des exceptions non mémorisées en mémoire, alors, sans enquêter davantage sur les détails, vous devez envisager la possibilité sérieuse de les utiliser pour exploiter des exploits.

Est-il prudent de compiler un morceau de code d'un inconnu?

Malheureusement, combien de temps dure un bout de ficelle. En principe, l'e-mail peut exploiter votre client de messagerie ou le code source, votre éditeur de texte ou cppcheck, avant même d'atteindre votre compilateur. La suggestion de Sebastian dans les commentaires d'utiliser un compilateur en ligne est une très bonne idée, mais bien sûr, le code doit être sous une forme que le compilateur acceptera.

N'importe quel langage ou compilateur disposant de fonctionnalités permettant l'exécution d'un code général au moment de la compilation est évidemment très suspect. Les modèles C ++ sont fonctionnellement complets, mais n'ont pas accès (prévu) au système, ils présentent donc un risque relativement faible. BЈовић mentionne makele risque extrêmement élevé (puisqu'il exécute le code de l'inconnu, c'est simplement que le code est écrit dans le makelangage, pas en C ++). Si le compilateur s'exécute, systemvous êtes dans le même bateau. J'avais l'habitude de travailler avec un assembleur qui, si je me souviens bien, pouvait exécuter du code à la compilation de manière arbitraire. Il était destiné aux tables de consultation, mais je ne pense pas que rien vous ait empêché de passer des appels système.

En pratique , si le code me semble correct et si je pense le comprendre, alors je considère qu'il est extrêmement risqué de le compiler, un risque bien moindre que celui de "naviguer sur Internet avec un navigateur verrouillé". Je fais régulièrement des choses plus risquées sur ma machine polyvalente, mais je ne ferais pas beaucoup de choses, par exemple dans un laboratoire de virus ou sur un serveur critique. Si le code est drôle ou évidemment obscurci, je ne risquerais peut-être pas de le compiler car, outre le risque, il pourrait contenir un exploit caché dans une liste illisible, il s'agit d'un code de déchets. Le code sournois est difficile mais possible. Le code sous-jacent utilisé par la machine via un exploit du compilateur doit contenir une charge utile exécutable non triviale, il est donc extrêmement difficile.

Si vous souhaitez approfondir cette question, essayez de demander aux personnes qui hébergent des compilateurs en ligne. Si cela ne leur a pas été fait alors (à moins que vous ne veniez à l'attention de la NSA ou de son équivalent), vous pouvez raisonnablement supposer que cela ne vous sera pas fait. Ils s’efforcent d’exécuter leur compilateur dans un bac à sable approprié, ce qui peut être plus difficile que vous ne le souhaitez, mais ils pourraient au moins être en mesure de vous dire à quelle fréquence ce bac leur évite des problèmes.

Bien que ce soit généralement une préoccupation, je pense que le problème est inexistant en raison de la configuration.

Le demandeur vous a envoyé du code source. Comment ou pourquoi est-ce arrivé?

Bien évidemment il n'y a que trois possibilités:

1. Vous avez confié au demandeur une tâche pour résoudre un problème particulier (bien défini) afin d'évaluer ses compétences.
2. Le demandeur veut montrer quelque chose de cool qu'il a écrit.
3. Le demandeur est un imbécile, un espion ou une personne malicieuse et ne souhaite pas réellement être embauché. Tout ce qu'il espère, c'est que vous soyez assez stupide pour exécuter son code.

Environ 2) et 3)

Le risque principal est de distinguer entre 2) et 3). Il y a de fortes chances que si ce qu'il a écrit vaut la peine d'être lu , vous pouvez obtenir le code source en ligne (d'une source "neutre") et vous en connaissez peut-être déjà une partie, ou c'est quelque chose que vous ne connaissez pas vraiment. ne voulez pas regarder parce que vous enfreindriez la propriété intellectuelle d'un concurrent (ancien employeur). Ce dernier signifierait que vous ne voudriez de toute façon pas engager cette personne.
Si vous pouvez obtenir la source en ligne, faites-le. Si vous pouvez vérifier la contribution du demandeur à un logiciel bien connu (y compris un logiciel propriétaire) par son nom quelque part dans les crédits, faites-le.
Dans tous les autres cas, ignorez simplement ce qu'il vous a envoyé. Ce n'est pas la peine de regarder, ou illégale, ou à haut risque.

Environ 1)

Le demandeur vous a envoyé quelque chose parce que vous lui avez confié une mission. Si vous avez une compétence (ce que je suppose que vous avez!), Alors pour une tâche de programmation typique (... que vous avez même choisie vous-même!), Vous serez en mesure de dire s'il s'agit d'une solution plausible qui semble fonctionner. en regardant le code source pendant moins de 30 secondes (plus probablement 10 secondes).

Si vous ne pouvez pas dire que le programme fonctionnera probablement (ou ce qu'il fait du tout) dans les 30 secondes, celui qui l'a écrit n'est pas le genre de personne que vous souhaitez embaucher, pas de limite. Vous voulez des gens qui écrivent du code que d'autres humains peuvent comprendre et conserver. Vous ne voulez pas de quelqu'un qui essaie de faire preuve d'intelligence, ni de quelqu'un qui gagne régulièrement le concours C obscurci. Peu importe que le programme fonctionne ou non. Dès qu'une autre personne ne peut pas comprendre le code, cela ne fonctionne jamais.
Si le programme semble fonctionner normalement, mais que vous trouvez quelque chose qui a l'air "étrange" (par exemple, des séquences d'échappement Java Unicode, des chaînes de caractères brutes C ++, des éléments qui ressemblent à des trigrammes, peu importe), traitez l'affectation comme "échec", déplacez au demandeur suivant. Il n'est pas nécessaire d'inclure quoi que ce soit du genre dans 99% de tous les programmes (et, bien sûr, pas dans votre mission - j'espère bien). Donc, si vous trouvez quelque chose de "bizarre" comme ça, vous ne voudrez pas embaucher le candidat.

Si le code réussit le premier triage, vous voudrez peut-être consacrer encore 2 à 3 minutes à un examen plus approfondi. Si vous êtes toujours satisfait de ce que vous voyez après cela, vous pouvez l'exécuter via un analyseur statique et le compiler sur une machine virtuelle avec un niveau d'avertissement élevé.

Cela devrait soulever des problèmes que vous avez peut-être manqués lors de la lecture du code source (par exemple, invoquer un comportement non défini ou limiter la conversion).
La compilation vous dira avant tout si le postulant a la diligence nécessaire et le souci du détail, et non pas si il possède des compétences en programmation. Tout comme écrire le nom de l'employeur correctement sur votre candidature et vérifier votre CV avant de le remettre, il est recommandé de s'assurer que le code source que vous transmettez est compilé sans erreur (et de préférence sans avertissement). Si quelqu'un ne le fait pas, vous ne voulez pas l'embaucher.

Le risque que des choses diaboliques se produisent à ce stade (exploiter le compilateur et sortir de la machine virtuelle) est négligeable, vu que vous avez déjà effectué un contrôle de vraisemblance sur le code. Ça n'arrivera pas.

Si la possibilité vous inquiète, prenez une machine plus ancienne (la plupart d’entre nous n’en avons pas quelques-uns assis?), Installez la version actuelle de Linux et le compilateur & c, copiez le code source, débranchez le câble réseau (ou désactivez le WiFi ), et faire les compilations. Si quelque chose de méchant se produit, cela n'affectera rien d'autre.

Et pour les logiciels malveillants dans le Makefile, exécutez-le avec l’option -n (IIRC, RTMF) pour voir ce qu’il va faire sans le faire réellement.

* À moins bien sûr que votre programmeur ait codé le logiciel malveillant de manière à attendre une reconnexion, mais dans ce cas, vous: a) nettoyez la machine; et b) envoyer le CV de ce type à la NSA, car il est gaspillé dans le monde commercial :-)

L'essentiel est qu'il y a un risque. Le risque est assez faible, comme le soulignent d’autres réponses, mais il existe un risque. Cela signifie que vous devez poser deux questions:

1. Que puis-je faire pour atténuer les risques?
2. Le risque est-il suffisamment élevé pour que je devrais m'en préoccuper?

La seconde est ce que vous avez posé ici dans cette question, mais c'est le mauvais objectif pour ce cas particulier. La solution pour atténuer les risques est claire et facilement disponible: ne compilez pas le code sur votre ordinateur . Vous avez deux façons évidentes de le compiler sans utiliser votre machine:

1. Utilisez une machine virtuelle (comme l'a immédiatement souligné @ FlorianMargaine dans les commentaires). Vous devez simplement le prendre avant la compilation, puis le restaurer lorsque vous avez terminé.
2. Utilisez un service hébergé (tel qu'un compilateur en ligne).

Ces moyens d'atténuer vos risques sont tellement évidents, peu coûteux et facilement accessibles qu'il ne vaut pas la peine de passer beaucoup de temps à essayer d'analyser l'ampleur du risque. Il suffit d’en faire l’un d’eux et d’en finir.

En fait, Visual Studio vous avertit si vous ouvrez un projet à partir d'un emplacement non approuvé (par exemple, téléchargé ou partagé sur le réseau).

Voici un exemple d'utilisation de ce projet avec WPF: vous pouvez référencer des classes .NET à partir de XAML et fournir à IntelliSense, VS charge et exécute les classes référencées au moment de la conception.

Cela signifie qu'un attaquant peut déposer un fichier .dll malveillant dans le répertoire bin, remplacer le code source par un code non malveillant et qu'au moment de la conception, la DLL est exécutée. Après votre première construction, toute trace du fichier binaire malveillant a disparu.

Ainsi, même si tout le code fourni est "propre", le compilateur est exempt de bogues et, bien sûr, vous n'exécutez jamais manuellement les fichiers .EXE fournis, un code malveillant pourrait toujours être exécuté en arrière-plan. (Pour vous protéger de cette attaque spécifique, assurez-vous simplement qu'il n'y a AUCUN fichier binaire dans l'arborescence avant d'ouvrir la solution. VS vous invitera ensuite à créer la solution avant de fournir IntelliSense au moment de la conception.)

Des vecteurs similaires existent probablement avec d'autres langages / systèmes d'exploitation.

Lecture du code source: totalement sécurisé. Compiler le code source: totalement sécurisé. Exécution des fichiers binaires compilés: eh bien ... ça dépend.

La compilation est simplement l'ordinateur qui lit le code source et écrit son équivalent sous forme binaire. Après la compilation, vous n'avez plus que 2 documents: un lisible par l'homme et un autre lisible par ordinateur. À moins que vous ne demandiez à l'ordinateur de lire (c'est-à-dire d'exécuter) le deuxième document, rien ne se passera.

Je pense que vous êtes inquiet pour l'une des deux saveurs:

• Malwares sophistiqués et axés sur l'exploit : peu probable, notamment parce qu'ils ciblent un matériel et / ou un logiciel très spécifique et que [selon votre question] votre attaquant n'a probablement pas ce niveau de connaissance du système.
• choses qui nuisent à votre environnement : directives de blague malveillante (par exemple, suppression de votre répertoire personnel) ou directives inconsidérées / incompétentes qui modifient le comportement de votre système (par exemple, réécriture des variables d'environnement PATH ou LIBRARY)

Certaines personnes ont suggéré des machines virtuelles ou d'anciens systèmes, mais je propose une solution beaucoup plus simple: Compiler en tant qu'utilisateur différent avec des autorisations réduites / différentes . Beaucoup plus facile que de configurer une machine virtuelle ou un ordinateur dédié.

Si, dans l’improbable, même si votre système est victime d’explosions au moment de la compilation, restaurez-les à partir de sauvegardes (vous en avez, n’est-ce pas?).