[C#] Comment spécifier/GS, options pour C# application?

Question

Comme vous le savez, /GS sont Visual C++ Compiler ou Linker Options.

1. Puis-je spécifier/GS dans le compilateur C# ou l'éditeur de liens?

2. Ces indicateurs sont-ils activés par défaut dans les applications C#?

   [Modifier]: modifier le contenu question:

   2a. Ces fonctionnalités sont-elles activées (par ces options du compilateur comme dans Visual C++) par défaut dans les applications C#?

3. Existe-t-il un moyen de trouver un fichier .exe/.dll construit avec ces drapeaux?

Merci d'avance.

Answer 1

Je suppose que vous essayez de faire un audit de code/exécuter des outils d'analyse statique pour vous assurer que security/SDL best practices sont suivies. Si vous continuez à lire ...

Il existe un outil appelé Binscope qui peut être utilisé pour vérifier que vos binaires natifs/C++ sont compilés avec/GS,/SafeSEH,/NXCOMPAT et/DYNAMICBASE. Ce sont des options spécifiques à C++ qui empêchent les attaquants d'exploiter les dépassements de mémoire tampon. (Binscope vérifie également quelques autres choses)

La seule chose que Binscope vérifie dans les binaires C#/gérés est s'ils utilisent des noms forts. La chose la plus proche de binscope pour C# est FxCop qui détaillera un tas de problèmes potentiels dans votre code .Net géré. Pour des raisons de sécurité, corrigez les avertissements de sécurité que FxCop produit et vous êtes sur votre chemin. L'indicateur/analyze permet à Visual Studio de faire une analyse statique de votre code natif et vous indique s'il détecte quelque chose de suspect. L'équivalent C# /. Net est la partie sécurité de FxCop.

Answer 2

Aucune de ces options n'existe en C# car C# génère du code managé et C++ génère du code natif (code de langage machine). Le code managé est appelé 'vérifiable' car il est beaucoup plus strict que C/C++ et renforce la sécurité du type d'une manière que C++ et le code natif ne peuvent pas. (Ces vérifications ne sont pas pertinentes pour le code managé écrit en C++/CLI). Une grande partie de ceci est due au fait que ce code natif s'exécute directement sur le matériel et que le code managé s'exécute dans l'environnement d'exécution .NET (CLR).

Permettez-moi d'aller sur les options, un par un

1. /analyser - Je ne suis pas tout familier avec cette option, mais en regardant le list of what it checks, aucune de ces erreurs sont possibles ou un problème dans code managé. Par exemple, le premier avertissement C6031 n'est pas un problème car les codes gérés lèveront une exception qui ne peut pas être ignorée quand elle ne réussit pas.
2. /GS - Le code géré (en ignorant unsafe) n'accède pas directement à la mémoire et est immunisé contre les dépassements de tampon. Vous obtiendrez une exception plutôt que de déborder dans un autre souvenir./DynamicBase - Le code géré produit un octet appelé langage intermédiaire (IL) et est dynamiquement compilé en code natif (JIT) au moment de l'exécution, de sorte qu'il n'a pas d'espace d'adressage fixe à randomiser.
3. /SafeSEH - Le code géré possède son propre mécanisme d'exception et n'utilise pas SEH.