https://github.com/marketplace/actions/devskim

According to https://docs.microsoft.com/en-us/cpp/build/reference/safeseh-image-has-safe-exception-handlers?view=vs-2019:

/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.

The SAFESEH only applies for x86 (32-bit)/PE binaries.

I am not sure if we report it for x64/PE+ binaries but if we do, we should not do that or mark it as it doesn't apply to x64 binaries.

Additionally, we should make sure the README points this out too, so we should change:

Structured Exception Handling and SafeSEH support

Into:

Structured Exception Handling and SafeSEH support (for x86 binaries, where it applies)

Right now we loop over all of the IMAGE_SECTION_HEADERs in the LOADED_IMAGE to find the one that contains the RVA for the load config. This works and is fine, but Windows provides a convenience method that would be even better: ImageDirectoryEntryToDataEx. Using this would allow us to get rid of the loop + manual offset calculation and would make #15 unnecessary.

Reference: https://docs.microsoft.com/en-us/windows/desktop/api/dbghelp/nf-dbghelp-imagedirectoryentrytodataex

Platform: Windows 10 16229.192
Visual Studio: Professional 2019 16.6.2
Command: winchecksec.exe example.dll

Winchecksec can also be built as a library. We should consider making Python bindings for it, like so:

from winchecksec import Checksec

checksec = Checksec("foo.exe")
checksec.gs
checksec.authenticode
# ...

We should public macOS, Linux, and Windows builds for each release.

System Details:

Virtualization: vmware
Operating System: Ubuntu 18.04.4 LTS
Kernel: Linux 4.15.0-88-generic
Architecture: x86-64
cmake version 3.19.0

How am I building?
$ git clone https://github.com/trailofbits/winchecksec.git
$ cd winchecksec
$ mkdir build
$ cd build
$ export CMAKE_PREFIX_PATH=/home/iot/tools/vcpkg/packages/pe-parse_x64-linux/share/pe-parse/
$ export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:/home/iot/tools/vcpkg/packages/uthenticode_x64-linux/share/uthenticode

root@xyz ~/t/w/build# cmake -DCMAKE_BUILD_TYPE=Release ..
-- The C compiler identification is GNU 7.4.0
-- The CXX compiler identification is GNU 7.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/iot/tools/winchecksec/build

root@xyz ~/t/w/build# cmake --build .
Scanning dependencies of target winchecksec
[ 20%] Building CXX object CMakeFiles/winchecksec.dir/checksec.cpp.o
[ 40%] Linking CXX static library libwinchecksec.a
[ 40%] Built target winchecksec
Scanning dependencies of target winchecksec-bin
[ 60%] Building CXX object CMakeFiles/winchecksec-bin.dir/checksec.cpp.o
[ 80%] Building CXX object CMakeFiles/winchecksec-bin.dir/main.cpp.o
make[2]: *** No rule to make target '/home/iot/tools/vcpkg/packages/uthenticode_x64-linux/lib/libcrypto.a', needed by 'winchecksec'. Stop.
CMakeFiles/Makefile2:123: recipe for target 'CMakeFiles/winchecksec-bin.dir/all' failed
make[1]: *** [CMakeFiles/winchecksec-bin.dir/all] Error 2
Makefile:102: recipe for target 'all' failed
make: *** [all] Error 2

From MSDN:

To be effective, /GUARD:CF also requires the /DYNAMICBASE (Use address space layout randomization) linker option, which is on by default.

Dependabot couldn't find a .gitmodules for this project.

Dependabot requires a .gitmodules to evaluate your project's current Git dependencies. It had expected to find one at the path: /.gitmodules.

If this isn't a Git project, or if it is a library, you may wish to disable updates for it from within Dependabot.

View the update logs.

We currently model the presence of mitigations as true or false, making a partially arbitrary choice when a mitigation doesn't apply (e.g. ASLR on .NET, SafeSEH on x86_64). Instead, we should model presence as true, false, or "N/A".

We should also be able to check whether the given PE is both signed (at all) and signed with a valid/trusted certificate.

Links:

• https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode
• https://docs.microsoft.com/en-us/windows/desktop/seccrypto/example-c-program--verifying-the-signature-of-a-pe-file

Windows is adding hardware-backed stack protection via Intel's CET:

• https://techcommunity.microsoft.com/t5/windows-kernel-internals/understanding-hardware-enforced-stack-protection/ba-p/1247815

It looks like the relevant linker flag is /CETCOMPAT:

• https://docs.microsoft.com/en-us/cpp/build/reference/cetcompat?view=vs-2017

We should figure out which bit that flag sets in the DLL characteristics/load config and support it.

There are lots of other interesting checks that we could do, although most require a live process handle:

• Dynamic code/handle check policies
• Disabled/restricted system calls
• Disabled non-system fonts

Split out from #1: We should attempt to detect functions that are marked __declspec(guard(nocf)) or __declspec(guard(ignore)).

There hasn't been a stable winchecksec release in over a year, meaning that we haven't stabilized the pe-parse integration and other improvements made in that period.

Here's the release needlist:

• Enable tests in the CI (#47)
• Enforce code style with clang-format in the CI (#50)
• Move VERSION to Checksec.cpp, to emphasize that we're versioning the entire project and not just the CLI interface
• Actually bump VERSION in main.cpp
• Use smolverify to verify Authenticode signatures on Linux (#39)
• Publish build products for releases (via a GitHub action, see pegoat)

Wantlist:

• Builds for Linux and macOS (#38, #51)

cc @ekilmer

We should also probably check whether the program was built with /GS, which inserts stack cookies.

Like /DYNAMICBASE, /GS has an interesting edge case: if the user defines a custom entry point via /ENTRY and forgets to call __security_init_cookie() within it, then the cookie value is set to a default value that makes circumvention much easier.

Windows 10 also introduced return-flow guard (RFG) protection, which acts like a beefed up /GS by storing the return address on the (user-inaccessible) thread control stack (which is really just the fs segment) rather than just placing it behind a randomized stack cookie.

The relevant flags are in the load config (like #5 and #9), and are:

#define IMAGE_GUARD_RF_INSTRUMENTED                    0x00020000 // Module contains return flow instrumentation and metadata
#define IMAGE_GUARD_RF_ENABLE                          0x00040000 // Module requests that the OS enable return flow protection
#define IMAGE_GUARD_RF_STRICT                          0x00080000 // Module requests that the OS enable return flow protection in strict mode

Links:

• https://xlab.tencent.com/en/2016/11/02/return-flow-guard/

.NET applications are de-facto ASLR'd, even if the PE that contains them has had its relocation entries stripped or wasn't built with /DYNAMICBASE to begin with. It'd be good to report this.

IMAGE_OPTIONAL_HEADER.DataDirectory[14] represents the CLR header, so checking for this is a good way to check whether a PE is a .NET application and therefore unconditionally ASLR'd.

As a wishlist item, I'd like to better understand the output of winchecksec.

Please provide a newbie page under
https://github.com/trailofbits/winchecksec/wiki
explaining what each of the fields means, a short description of each, and links to the reference documentation.

As an end-user, I'm just curious, but as a developer, I might want some expert guidance on which security features are worth the effort to enable.

Not all Windows security features/mitigations can be detected statically; it'd be nice to have a -p PID or similar flag that allows a running process to be audited via GetProcessMitigationPolicy and other calls.

Travis CI supports Windows now, so there's no reason to stick with Appveyor (which has been unreliable and slow).

The below code checks to see if the loadConfiData.size() is greater than loadConfig but does not check to see if it is as big as loadConfig. It then does a memcpy of loadConfiData.data() to loadConfig of size sizeof(loadConfig). In my tests, loadConfigData.size() is 64 and is sizeof(loadConfig) is 164. So 100 random bytes are being copied into loadConfig. The RFG test gives inconsistent results because it references these random bytes.

        peparse::image_load_config_64 loadConfig;
        if (loadConfigData.size() > sizeof(loadConfig)) {
            std::cerr << "Warn: large load config, probably contains undocumented "
                         "fields"
                      << "\n";
        }
        memcpy(&loadConfig, loadConfigData.data(), sizeof(loadConfig));

According to Windows 10 security: How the shadow stack will help to keep the hackers at bay published by TechRepublic in April of 2020, Return Flow Guard (RFG) was never released by Microsoft:

But when the same team looked at how they could attack their own design, they found a race condition that meant some apps weren't protected and decided not to ship it at all.

Displaying this protection may cause people like me(1) to spend a lot of unneeded time trying to figure out how to enable this technology. The above article is consistent with what I experienced.

Can the check be removed or at least have the documentation show a deprecated flag?

(1) I am Mark Eklund, an employee of Zoom Video Communications.

These APIs shouldn't be part of the Checksec class:

    json toJson() const;
    friend std::ostream& operator<<(std::ostream& os, Checksec&);

Instead, they should be private to the winchecksec CLI.

ImageHlp can't (correctly) parse 32-bit binaries when built into a 64-bit build of winchecksec and vice versa. It's also a PITA to use and needs to be wrapped to conform to C++ idioms.

We should really just use our own pe-parse instead. PRs appreciated.

The original goal was to have it compile on linux. Should be easier with pe-parse now.

It could be useful to report/display in CLI:

• a hash of the scanned binary/binaries
• information if the binary os x86 or x64 (PE vs PE+)

If we don't want it by default, this could be behind some flag.

Once pe-parse is available via microsoft/vcpkg#11012, we should be able to remove the submodule here.

It'd be nice to have a basic sanity test for the JSON output, at the very least.

Broken off from #18.

Recently there was this article about how mingw does not add relocs by default in the main executable so even though it has the dynamic base flag set, it does not get randomized. This would be a good edge case to handle.

https://insights.sei.cmu.edu/cert/2018/08/when-aslr-is-not-really-aslr---the-case-of-incorrect-assumptions-and-bad-defaults.html

We currently check whether the target is using SEH, but we should also check whether it was compiled with the (even safer) /SAFESEH. The flags for SafeSEH live in the same load structure as those for /GS, so the check for this should be pretty similar to that for #5.

https://github.com/trailofbits/winchecksec/blob/master/Checksec.cc#L88

    peparse::image_load_config_32 loadConfig;
    memcpy_s(&loadConfig, sizeof(loadConfig), loadConfigData.data(),
             loadConfigData.size());

To repro, run winchecksec on itself:

PS Z:\winchecksec\win> .\Debug\winchecksec.exe .\Debug\winchecksec.exe
PS Z:\winchecksec\win>

You'll get no output, because the memcpy_s fails. Is this peparses fault or the use of it?

Right now, we just spit out some warning messages if the IMAGE_LOAD_CONFIG_DIRECTORY doesn't exist or is too short to perform some checks, but it'd be nice to include that in the JSON output as well.

isCFG currently checks for IMAGE_DLLCHARACTERISTICS_GUARD_CF in the image's DllCharacteristics. It should also check for IMAGE_GUARD_CF_INSTRUMENTED and IMAGE_GUARD_CF_FUNCTION_TABLE_PRESENT in the load config's GuardFlags.

The only thing blocking winchecksec builds for non-Windows is a single API: WinVerifyTrust.

We should try to remove usage of it in favor of an open-source implementation, of which there should be a few (since Authenticode is basically PKCS#7).

Some potential starting points:

• WINE has a WinVerifyTrust implementation
• Technical documentation on Authenticode from MS: http://www.microsoft.com/whdc/winlogo/drvsign/Authenticode_PE.mspx

cc @haxmeadroom @ekilmer

Right now we seek to and read from the right offset within the file HANDLE given to us by LOADED_IMAGE.hFile, but there's no need to do this when we already have the full file mapped into memory at LOADED_IMAGE.MappedAddress already.

Would be cool to also support ELF like the original checksec.
http://www.trapkit.de/tools/checksec.html

The Winchecksec API (i.e., the classes and functions exposed in Checksec.h) should be documented. Documentation should be auto-build with Doxygen and auto-published to GitHub Pages.

Components that aren't intended for public use should be isolated in an impl namespace.

Fix should be adding

SortIncludes: false
SortUsingDeclarations: false

It appears that the fast out checks for loadConfigSize_ thresholds are hardcoded for x64 and thus result in incorrect reports for x86 binaries.

I think they’re based on Microsoft’s Load Configuration Layout table which lists sizes for both 32 bit and 64 bit binaries, and that perhaps only the right hand side of the Offset column was used by mistake.

For example isSafeSEH’s loadConfigSize_ check specifies 112, but this is correct only for x64 binaries, which of course don’t use SafeSEH at all. The correct value to check against would appear to be 72, and thus the current checks may result in false negatives.

Provided I haven’t completely misunderstood this then there’d be two options:

1. Set all the checks to the x86 offsets as they’re the lower of the two, or
2. Support both sets of offsets so that the fast out can still be used in 100% of cases.

Hey in Checksec.cpp Line 115:

const bool Checksec::isDynamicBase() const  {   
    return !!(dllCharacteristics_ & IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE);  
}

The double NOT is equivalent to the absence of both of them. Are you relying on a side-effect behavior or was this an oversight? This is probably more of a refactoring issue rather than a bug if there is no change in behavior.

SafeSEH doesn't apply to x86_64, so we should report this as "N/A" rather than false.

See #66.

Checking whether an image is CFG-instrumented should be as simple as testing the header flags for IMAGE_DLLCHARACTERISTICS_GUARD_CF.

Add some basic pre-commit testing that runs winchecksec on a few exe's and checks the results.

We should have a basic suite of unit tests, plus a CI/CD setup for automatically attaching build products to new releases.

We currently use WinVerifyTrust to validate in-binary Authenticode signatures, but this doesn't work for externally signed binaries (i.e., those that come with a separate .cat file). Many core WIndows binaries are signed externally, so we should support this case.

Some initial research:

• https://stackoverflow.com/questions/7241453/read-and-validate-certificate-from-executable

Split out from #5: If the user defines a custom entrypoint via /ENTRY, we should verify that they call call __security_init_cookie(). If they fail to, we should mark GS as not enabled, as the stack cookie will be whatever the compile time value was.

For #81: GitHub actions uses SARIF to render its security alerts, so we should add a SARIF output mode to Winchecksec.

I'm confused about how to build this on linux. Don't know how best to fulfil the pe-parse requirement. Running "cmake --build . --target install" for that dependency does not seem to install anything.

Can anyone please help?