This article contains information about security tools and practices. Using them does not make applications immune from attack, but it makes successful attacks less likely.
Enable Control Flow Guard
Syntax
|
1 2 3 |
/guard:cf[-] |
The /guard:cf option causes the compiler to analyze control flow for indirect call targets at compile time, and then to insert code to verify the targets at runtime. By default, /guard:cf is off and must be explicitly enabled. To explicitly disable this option, use /guard:cf-.
Buffer Security Check
Detects some buffer overruns that overwrite a function’s return address, exception handler address, or certain types of parameters. Causing a buffer overrun is a technique used by hackers to exploit code that does not enforce buffer size restrictions.
A buffer overrun security check is performed on a GS buffer. A GS buffer can be one of these:
- An array that is larger than 4 bytes, has more than two elements, and has an element type that is not a pointer type.
- A data structure whose size is more than 8 bytes and contains no pointers.
- A buffer allocated by using the _alloca function.
- Any class or structure that contains a GS buffer.
|
1 2 3 4 5 6 |
char buffer[20]; int buffer[20]; struct { int a; int b; int c; int d; } myStruct; struct { int a; char buf[20]; }; |
However, the following statements do not declare GS buffers. The first two declarations contain elements of pointer type. The third and fourth statements declare arrays whose size is too small. The fifth statement declares a structure whose size on an x86 platform is not more than 8 bytes.
|
1 2 3 4 5 6 7 |
char *pBuf[20]; void *pv[20]; char buf[4]; int buf[2]; struct { int a; int b; }; |
Image has Safe Exception Handlers
When /SAFESEH is specified, the linker will only produce an image if it can also produce a table of the image’s safe exception handlers. This table specifies for the operating system which exception handlers are valid for the image.
/SAFESEH is only valid when linking for x86 targets. /SAFESEH is not supported for platforms that already have the exception handlers noted. For example, on x64 and ARM, all exception handlers are noted in the PDATA. ML64.exe has support for adding annotations that emit SEH information (XDATA and PDATA) into the image, allowing you to unwind through ml64 functions. See MASM for x64 (ml64.exe) for more information.
|
1 2 3 |
/SAFESEH[:NO] |
Code Analysis
|
1 2 3 |
/analyze[-][:WX-][:log filename][:quiet][:stacksize number][:max_paths number][:only] |
/analyze
Turns on analysis in the default mode. Analysis output goes to the Output window like other error messages. Use /analyze- to explicitly turn off analysis.
/analyze:WX-
Specifying /analyze:WX- means that code analysis warnings are not treated as errors when you compile by using /WX. For more information, see /w, /Wn, /WX, /Wall, /wln, /wdn, /wen, /won (Warning Level).
/analyze:log filename
Detailed analyzer results are written as XML to the file that is specified by filename.
/analyze:quiet
Turns off analyzer output to the Output window.
/analyze:stacksize number
The number parameter that is used with this option specifies the size, in bytes, of the stack frame for which warning C6262 is generated. If this parameter is not specified, the stack frame size is 16KB by default.
/analyze:max_paths number
The number parameter that is used with this option specifies the maximum number of code paths to be analyzed. If this parameter is not specified, the number is 256 by default. Larger values perform more thorough checking, but the analysis might take longer.
/analyze:only
Typically, the compiler generates code and does more syntax checking after it runs the analyzer. The /analyze:only option turns off this code generation pass; this makes analysis faster but compile errors and warnings that might have been discovered by the code generation pass of the compiler are not emitted. If the program is not free of code-generation errors, analysis results might be unreliable; therefore, we recommend that you use this option only if the code already passes code-generation syntax checking without errors.
Use address space layout randomization
This option modifies the header of an executable to indicate whether the application should be randomly rebased at load time.
|
1 2 3 |
/DYNAMICBASE[:NO] |
Help us improve our articles by commenting on them.
