Signature enforcement in windows 10

Hi all,

I’ve installed a driver, signed with a new certificate (issued a month ago), on a fresh windows 10 machine (version 1803). Since this is a non-pnp driver, by installing I mean copying files to machine and registering under Services key in registry.
I’ve enabled secureboot in the machine (and checked with powershell that it is indeed enabled).
It was my expectation that the driver will not load, due to new restrictions on windows 10 regarding signature. But it load just fine. What am I missing ?
(I’ve also looked through the eventlog to see if there was a registered event about the driver not being properly signed or something like that, but didn’t see that either).
Am I missing something ? Are there any more specific cases I need to answer to, in order for the driver not to load ?
I’m basing my data on this :
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-

Thanks

Did you embed sign the driver?

Bent from my phone


From: xxxxx@gmail.com
Sent: Tuesday, May 22, 2018 5:46 AM
Subject: [ntdev] Signature enforcement in windows 10
To: Windows System Software Devs Interest List

Hi all,

I’ve installed a driver, signed with a new certificate (issued a month ago), on a fresh windows 10 machine (version 1803). Since this is a non-pnp driver, by installing I mean copying files to machine and registering under Services key in registry.
I’ve enabled secureboot in the machine (and checked with powershell that it is indeed enabled).
It was my expectation that the driver will not load, due to new restrictions on windows 10 regarding signature. But it load just fine. What am I missing ?
(I’ve also looked through the eventlog to see if there was a registered event about the driver not being properly signed or something like that, but didn’t see that either).
Am I missing something ? Are there any more specific cases I need to answer to, in order for the driver not to load ?
I’m basing my data on this :
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-hardware%2Fdrivers%2Finstall%2Fkernel-mode-code-signing-policy--windows-vista-and-later-&data=02|01|Doron.Holan%40microsoft.com|d8e645248646471f605208d5bfe1f8b1|72f988bf86f141af91ab2d7cd011db47|1|0|636625899620881313&sdata=5adYfU%2Fpu0ILBKOsz8Z1kyLlGm3he%2Bj1X9UdPn8cdZg%3D&reserved=0

Thanks


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

xxxxx@gmail.com wrote:

I’ve installed a driver, signed with a new certificate (issued a month ago), on a fresh windows 10 machine (version 1803). Since this is a non-pnp driver, by installing I mean copying files to machine and registering under Services key in registry.
I’ve enabled secureboot in the machine (and checked with powershell that it is indeed enabled).
It was my expectation that the driver will not load, due to new restrictions on windows 10 regarding signature. But it load just fine. What am I missing ?

That would also be my expectation.

(I’ve also looked through the eventlog to see if there was a registered event about the driver not being properly signed or something like that, but didn’t see that either).

I’m not sure what log to ask for.   A service driver doesn’t post to
\windows\inf\setupapi.dev.log.  Can anyone else confirm this?  Anyone
with a driver service or a PnP filter ought to be able to test this.  My
test systems do not yet have Secure Boot.

I’m basing my data on this :
https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-

Yes, I just helped them rework that page to fix up the known issues.  I
thought it was all correct now.  Your scenario here is disturbing.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Is it a boot start driver? Currently, enforcement doesn’t occur for a boot start driver. Check Event Viewer->Applications and Services Logs->Microsoft->Windows->CodeIntegrity->Operational.

Good idea. To be clear: “enforcement” here means, “the requirement that the executable be signed by Microsoft and not just embedded signed” – If it’s not embedded signed a driver will not load at boot start (without boot debugging enabled).

Peter
OSR
@OSRDrivers

Hi guys
In order to install my Unsigned driver on my host machine i had issues with
the Windows 10 enfrorcement mechanism;
I found a workaround to disable it on boot time through BCDEDIT

bcdedit /set {GUID} nointegritychecks on
bcdedit /set {GUID} testsigning on

afterwhat i was able to load my driver at boot time without any issues
I hope this helps.

Regards

Valar Morghulis !

On Wed, May 23, 2018 at 5:17 PM, xxxxx@osr.com
wrote:

>


>
> Good idea. To be clear: “enforcement” here means, “the requirement that
> the executable be signed by Microsoft and not just embedded signed” – If
> it’s not embedded signed a driver will not load at boot start (without boot
> debugging enabled).
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>

Hi all,

A few answers :

  1. Yes, the driver is embeddedly signed with the SHA2 signature
  2. The driver is of start type = SERVICE_SYSTEM_START (and not BOOT_START).
    Also, I stopped and restarted theh service (through sc stop/sc start), and it still works.
    I even tried to change the type to SERVICE_DEMAND_START , and restarted the machine and started the driver. It still loaded properly.
  3. I am attaching here the output from powershell : (as if, to show that secure boot is on)

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\Windows\system32> Confirm-SecureBootUEFI
True
PS C:\Windows\system32> Get-CimInstance ?ClassName Win32_DeviceGuard ?Namespace root\Microsoft\Windows\DeviceGuard

AvailableSecurityProperties : {1, 2, 3}
CodeIntegrityPolicyEnforcementStatus : 1
InstanceIdentifier : 4ff40742-2649-41b8-bdd1-e80fad1cce80
RequiredSecurityProperties : {1, 2}
SecurityServicesConfigured : {1, 2}
SecurityServicesRunning : {1, 2}
UsermodeCodeIntegrityPolicyEnforcementStatus : 1
Version : 1.0
VirtualizationBasedSecurityStatus : 2
PSComputerName :

  1. @Thanos Titan, I am having the opposite problem. I *want* the driver not to load :slight_smile:

  2. I’ve looked through the suggested logs, but there’s no mention of a problem loading the driver.
    I do see a bunch of problems mentioned about loading dlls. I’m posting an example :


  • -

    3076
    2
    4
    18
    118
    0x8000000000000000

    39463


    Microsoft-Windows-CodeIntegrity/Operational
    DESKTOP-SKRBIFU


    -
    51
    \Device\HarddiskVolume4\Windows\SysWOW64\rpcnet.dll
    52
    \Device\HarddiskVolume4\Windows\SysWOW64\svchost.exe
    2
    4
    3236495362
    20
    D032BA8EB8F0E62AD53F7412ACD5DC9BB41E21D2
    32
    EA0BD8041C904A54514CD9483EB0E7AFFF53883F74550D27A8BA06AB99F6DD22
    744392416
    1
    7
    Default
    7
    Default
    64
    5CAF2E26ABD726B293937F0092883B3B04C0DB80EF854454297C3DC686FC8CD10000000000000000000000000000000000000000000000000000000000000000

Code Integrity determined that a process (\Device\HarddiskVolume4\Windows\SysWOW64\svchost.exe) attempted to load \Device\HarddiskVolume4\Windows\SysWOW64\rpcnet.dll that did not meet the Enterprise signing level requirements or violated code integrity policy. However, due to code integrity auditing policy, the image was allowed to load.

  1. Thanks for everyone who tried helping. Does anyone have any other suggestions ?

Also, forgot to mention, that my driver doesn’t specify a load order group, if that matters.

If I embed-sign a SERVICE_SYSTEM_START non-PnP SERVICE_KERNEL_DRIVER
using just my post-July 2015-issued SHA256 certificate (no Microsoft
embedded signature), indeed that driver will not load on a Windows 10
Pro 1803 x64 clean (non-upgrade) installation where Secure Boot is
enabled. As expected, and seemingly opposite of what you’re seeing.

There are no details in the regular System event log when this
happens; just a generic non-Error “Information” from Service Control
Manager saying that “The following boot-start or system-start
driver(s) did not load”.

I do also happen to have additional non-PnP drivers with
DependOnService configurations against this driver, and Service
Control Manager reports Event 7001 errors for being unable to resolve
those dependencies, but the details are simply “A device on the system
is not functioning.”

The CodeIntegrity event log that Gabe Jones pointed to was more
helpful, and has an Event 3004 error citing “Windows is unable to
verify the image integrity of the file because file hash could
not be found on the system. A recent hardware or software change
might have installed a file that is signed incorrectly or damaged, or
that might be malicious software from an unknown source.”

Your original assertion was “on a fresh windows 10 machine (version
1803).” Is it clear that the Microsoft documentation you linked to is
saying that “upgrade” installations are exempt from this enforcement,
and that by “fresh” you mean a bare-metal installation of 1803?

Meaning it might subjectively be a “clean” installation of Windows,
but if you upgraded to 1803 from any pre-1607 version of Windows 10,
or upgraded to 1803 on a post-1607 version of Windows which itself
originally had been upgraded from a pre-1607 version of Windows,
Microsoft is intentionally allowing the Secure Boot requirement to
remain un-enforced on that machine.

Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com

> Microsoft is intentionally allowing the Secure Boot requirement to

remain un-enforced on that machine.

I do mean “the driver signature requirement related to having Secure
Boot enabled”, of course.

I should have also mentioned that on this Windows 10 Pro 1803 x64
non-upgrade installation, the CodeIntegrity log starts with an
informational Event 3084, “Code Integrity will enable WHQL driver
enforcement for this boot session. Settings 0x0. Exemption 1.”

Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com