[c#]How to specify /GS, options to c# application?

Question

As you know, /GS are Visual C++ Compiler or Linker Options.

1. Can i Specify /GS in c# compiler or linker?

2. Are these flags enabled by default in c# applications?

   [Edit]: change the question contents:

   2a. Are these features enabled (by these compiler options as in Visual C++) by default in c# applications?

3. Is there a way to find out wheather a .exe/.dll file is build with these flags?

Thanks in advance.

Answer 1

I'm guessing your trying to do a code audit/run static analysis tools to ensure that security/SDL best practices are being followed. If you are keep reading...

There is a tool called Binscope that can be used to check that your native/C++ binaries are compiled with the /GS, /SafeSEH, /NXCOMPAT, and /DYNAMICBASE. These are C++ specific options that make it harder for attackers to exploit buffer overruns. (Binscope also checks for a few other things)

The only thing Binscope checks for in C#/managed binaries is if they are using strong names. The closest thing to binscope for C# is FxCop which will detail a bunch of potential issues in your managed .Net code. For security, fix any security warnings that FxCop produces and you are on your way.

The /analyze flag causes Visual Studio to do some static analysis of your native code and lets you know if it finds anything suspicious. The C#/.Net equivalent is the security part of FxCop.

Answer 2

None of those options exist in C# because C# generates managed code and C++ generates native code (machine language code). Managed code is called 'verifiable' because it has much stricter checking than C/C++ and enforces type safety in ways that C++ and native code cannot. (These checks are irrelevant for managed code written in C++/CLI).

Much of this is due to the fact that that native code runs directly on the hardware and managed code runs inside the .NET run time (CLR).

Allow me to go over the options one by one

1. /analyze - I'm not all the familiar with this option, but looking at the list of what it checks, none of those errors are possible or a problem in managed code. For example the first warning C6031 is not a problem because managed codes will throw an exception that can't be ignored when it doesn't succeed.
2. /GS - Managed code (ignoring unsafe) doesn't directly access memory and is immune to buffer overflows. You'll get an exception rather than overflowing into other memory.
3. /DynamicBase - Managed code produces byte called Intermediate Language (IL) and is dynamically compiled to native code (JIT) at run time, so it has no fixed address space to randomize.
4. /SafeSEH - Managed code has it's own exception mechanism and doesn't use SEH.