Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 9-13 Sept 2024 | Live, Online |
Developing Minifilters | 15-19 July 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 20-24 May 2024 | Live, Online |
Comments
Bent from my phone
_____________________________
From: [email protected]
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://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-&data=02|01|[email protected]|d8e645248646471f605208d5bfe1f8b1|72f988bf86f141af91ab2d7cd011db47|1|0|636625899620881313&sdata=5adYfU/pu0ILBKOsz8Z1kyLlGm3he+j1X9UdPn8cdZg=&reserved=0
Thanks
---
NTDEV is sponsored by OSR
Visit the list online at:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at
To unsubscribe, visit the List Server section of OSR Online at
> 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, [email protected]
Providenza & Boekelheide, Inc.
Tim Roberts, [email protected]
Software Wizard Emeritus
Is it a boot start driver? Currently, enforcement doesn't occur for a boot
start driver.
</quote>
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
Peter Viscarola
OSR
@OSRDrivers
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, [email protected]
wrote:
>
> Is it a boot start driver? Currently, enforcement doesn't occur for a
> boot
> start driver.
>
>
> 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: showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
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 :
4. @Thanos Titan, I am having the opposite problem. I *want* the driver not to load :-)
5. 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 :
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-CodeIntegrity" Guid="{4EE76BD8-3CF4-44A0-A0AC-3937643E37A3}" />
<EventID>3076</EventID>
<Version>2</Version>
<Level>4</Level>
<Task>18</Task>
<Opcode>118</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2018-05-24T07:08:35.805164700Z" />
<EventRecordID>39463</EventRecordID>
<Correlation ActivityID="{D4C6ECA0-F0F6-0001-DC9A-C7D4F6F0D301}" />
<Execution ProcessID="9804" ThreadID="1616" />
<Channel>Microsoft-Windows-CodeIntegrity/Operational</Channel>
<Computer>DESKTOP-SKRBIFU</Computer>
<Security UserID="S-1-5-18" />
</System>
- <EventData>
<Data Name="FileNameLength">51</Data>
<Data Name="File Name">\Device\HarddiskVolume4\Windows\SysWOW64\rpcnet.dll</Data>
<Data Name="ProcessNameLength">52</Data>
<Data Name="Process Name">\Device\HarddiskVolume4\Windows\SysWOW64\svchost.exe</Data>
<Data Name="Requested Signing Level">2</Data>
<Data Name="Validated Signing Level">4</Data>
<Data Name="Status">3236495362</Data>
<Data Name="SHA1 Hash Size">20</Data>
<Data Name="SHA1 Hash">D032BA8EB8F0E62AD53F7412ACD5DC9BB41E21D2</Data>
<Data Name="SHA256 Hash Size">32</Data>
<Data Name="SHA256 Hash">EA0BD8041C904A54514CD9483EB0E7AFFF53883F74550D27A8BA06AB99F6DD22</Data>
<Data Name="USN">744392416</Data>
<Data Name="SI Signing Scenario">1</Data>
<Data Name="PolicyNameLength">7</Data>
<Data Name="PolicyName">Default</Data>
<Data Name="PolicyIDLength">7</Data>
<Data Name="PolicyID">Default</Data>
<Data Name="PolicyHashSize">64</Data>
<Data Name="PolicyHash">5CAF2E26ABD726B293937F0092883B3B04C0DB80EF854454297C3DC686FC8CD10000000000000000000000000000000000000000000000000000000000000000</Data>
</EventData>
</Event>
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.
6. Thanks for everyone who tried helping. Does anyone have any other suggestions ?
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 <path> 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
[email protected]
> 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
[email protected]