Use BinSkim to examine binary files to identify vulnerabilities
Use BinSkim to examine binary files to identify coding and building practices that can potentially render the binary vulnerable. It can be used to check binaries that are getting ready to ship, to help to validate that nothing went wrong in the build chain.
BinSkim checks for:
- Use of outdated compiler tool sets - Binaries should be compiled against the most recent compiler tool sets wherever possible to maximize the use of current compiler-level and OS-provided security mitigations.
- Insecure compilation settings - Binaries should be compiled with the most secure settings possible to enable OS-provided security mitigations, maximize compiler errors and actionable warnings reporting, among other things.
- Signing issues - Signed binaries should be signed with cryptographically-strong algorithms.
BinSkim is an open source tool and generates output files that use the Static Analysis Results Interchange Format (SARIF) format. BinSkim replaces the former BinScope tool.
For more information about BinSkim, see the BinSkim User Guide.
Install and run BinSkim
Follow these steps to validate that the security compile options are properly configured in the code that you are shipping.
Download and install the cross platform .NET Core SDK.
Confirm Visual Studio is installed. For information on downloading and installing Visual Studio see Install Visual Studio.
There are a number of options to download BinSkim, such as a NuGet package. In this example we will use the git clone option to download from here: https://github.com/microsoft/binskim and install it on a 64 bit Windows PC.
Open a Visual Studio Developer Command Prompt window and create a directory, for example
C:\binskim-master
.C:\> Md \binskim-master
Move to that directory that you just created.
C:\> Cd \binskim-master
Use the git clone command to download all of the needed files.
C:\binskim-master> git clone --recurse-submodules https://github.com/microsoft/binskim.git
Move to the new
binskim
dirctory that the clone command created.C:\> Cd \binskim-master\binskim
Run BuildAndTest.cmd to ensure that release build succeeds, and that all tests pass.
C:\binskim-master\binskim> BuildAndTest.cmd Welcome to .NET Core 3.1! --------------------- SDK Version: 3.1.101 ... C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64\BinSkim.Sdk.dll 1 File(s) copied C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\linux-x64\BinSkim.Sdk.dll 1 File(s) copied ...
The build process creates a set of directories with the BinSkim executables. Move to the win-x64 build output directory.
C:\binskim-master\binskim> Cd \binskim-master\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64>
Display help for the analyze option.
C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64> BinSkim help analyze
BinSkim PE/MSIL Analysis Driver 1.6.0.0
--sympath Symbols path value, e.g., SRV*http://msdl.microsoft.com/download/symbols or Cache*d:\symbols;Srv*http://symweb. See
https://learn.microsoft.com/windows-hardware/drivers/debugger/advanced-symsrv-use for syntax information. Note that BinSkim will clear the
_NT_SYMBOL_PATH environment variable at runtime. Use this argument for symbol information instead.
--local-symbol-directories A set of semicolon-delimited local directory paths that will be examined when attempting to locate PDBs.
-o, --output File path to which analysis output will be written.
--verbose Emit verbose output. The resulting comprehensive report is designed to provide appropriate evidence for compliance scenarios.
...
Setting the symbol path for BinSkim
If you are building all the code you are analyzing on the same machine you are running BinSkim on, you typically don't need to set the symbol path. This is because your symbol files are available on the local box where you compiled. If you are using a more complex build system, or redirecting your symbols to different location (not alongside the compiled binary), use --local-symbol-directories
to add these locations to the symbol file search.
If your code references a compiled binary that is not part of your code, the Window debugger sympath can be used to retrieve symbols in order to verify the security of these code dependencies. If you find an issue in these dependencies, you may not be able to fix them. But it can be useful to be aware of any possible security risk you are accepting by taking on those dependencies.
Tip
When adding a symbol path (that references a networked symbol server), add a local cache location to specify a local path to cache the symbols. Not doing this can greatly compromise the performance of BinSkim. The following example, specifies a local cache at d:\symbols.
--sympath Cache*d:\symbols;Srv*http://symweb
For more information about sympath, see Symbol path for Windows debuggers.
Execute the following command to analyze a compiled driver binary. Update the target path to point to your complied driver .sys file.
C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64> BinSkim analyze "C:\Samples\KMDF_Echo_Driver\echo.sys"
For additional information, add the verbose option like this.
C:\binskim-master\binskim\bld\bin\AnyCPU_Release\Publish\netcoreapp2.0\win-x64> BinSkim analyze "C:\Samples\KMDF_Echo_Driver\osrusbfx2.sys" --verbose
Note
The --verbose option will produce explicit pass/fail results for every check. If you do not provide verbose, you will only see the defects that BinSkim detects. The --verbose option is typically not recommended for actual automation systems due to the increased size of log files and because it makes it more difficult to pick up individual failures when they occur, as they will be embedded in the midst of a large number of 'pass' results.
Review the command output to look for possible issues. This example output shows three tests that passed. Additional information on the rules, such as BA2002 is available in the BinSkim User Guide.
Analyzing... Analyzing 'osrusbfx2.sys'... ... C:\Samples\KMDF_Echo_Driver\osrusbfx2.sys\Debug\osrusbfx2.sys: pass BA2002: 'osrusbfx2.sys' does not incorporate any known vulnerable dependencies, as configured by current policy. C:\Samples\KMDF_Echo_Driver\Debug\osrusbfx2.sys: pass BA2005: 'osrusbfx2.sys' is not known to be an obsolete binary that is vulnerable to one or more security problems. C:\Samples\KMDF_Echo_Driver\osrusbfx2.sys: pass BA2006: All linked modules of 'osrusbfx2.sys' generated by the Microsoft front-end satisfy configured policy (compiler minimum version 17.0.65501.17013).
This output shows that test BA3001 is not run as the tool indicates that the driver is not an ELF binary.
... C:\Samples\KMDF_Echo_Driver\Debug\osrusbfx2.sys: notapplicable BA3001: 'osrusbfx2.sys' was not evaluated for check 'EnablePositionIndependentExecutable' as the analysis is not relevant based on observed metadata: image is not an ELF binary.
This output shows an error for test BA2007.
... C:\Samples\KMDF_Echo_Driver\Debug\osrusbfx2.sys: error BA2007: 'osrusbfx2.sys' disables compiler warning(s) which are required by policy. A compiler warning is typically required if it has a high likelihood of flagging memory corruption, information disclosure, or double-free vulnerabilities. To resolve this issue, enable the indicated warning(s) by removing /Wxxxx switches (where xxxx is a warning id indicated here) from your command line, and resolve any warnings subsequently raised during compilation.
To enable these warnings in Visual Studio, under C/C++ in the property pages for the project, remove the values that you don't wish to exclude in Disable Specific Warnings.
The default compile options in Visual Studio for driver projects can disable warnings such as the following. These warnings will be reported by BinSkim.
C4603 - 'name': macro is not defined or definition is different after precompiled header use
C4627 - 'description': skipped when looking for precompiled header use
C4986 - 'declaration': exception specification does not match previous declaration
For more information about the compiler warnings, see Compiler Warnings by compiler version.