Worum geht es?
Microsoft hat ja kürzlich bekanntgegeben, dass ab dem "April 2026 non-security" Update alle Treiber blockiert werden sollen, die noch nicht über eine WHQL-Signatur von Microsoft verfügen und noch mit einer Signatur aus dem veraltenen Cross-Signing-Programm unterwegs sind. Leider gibt es dazu praktisch keine weiteren Informationen. Vielmehr halluzinieren sich LLMs und Benutzer gleichermaßen den allergrößten Schwachsinn zum Thema zusammen.
Daher hier mal eine aktuelle Übersicht zum Thema von jemandem, der im Gegensatz zu 99% der Nutzer den Newsbeitrag auch gelesen hat. Außerdem hilft ein Blick in die Dukumentation und den Code auch ungemein bei solchen Dingen ...
Was ist die Ausgangssituation?
Damit ein
Kernel Mode Treiber unter modernen Windows Systemen geladen werden darf, muss er über eine gültige und vertrauenswürdige Signatur verfügen. Früher hatte Microsoft die Hoheit über diese Signaturen an einigen Unternehmen übergeben, die dann quasi jedem ungeprüft erlaubten, beliebigen Code im Windows Kernel auszuführen, solange man die horrenden Zertifikatsgebühren bezahlen konnte. ("
Cross-Signing"-Idee: Microsoft vertraut, dass das Unternehmen alles ordnungsgemäß überprüft und deshalb vom Unternehmen augestellte Zertifikate und die damit signierten Treiber ebenfalls vertrauenswürdig sind)
Ab Windows 10 hat Microsoft dieses Programm auslaufen lassen und bei jedem "Windows 10 kompatiblen" Treiber verlangt, dass dieser vorher an Microsoft zur Überprüfung übersendet wird. Falls er dann die grundlegenden Anforderungen erfüllt (z.B. keine offensichtlichen Fehler, Sicherheitslücken oder Malware, Herausgeber und Zweck erkennbar), wird er von Microsoft selbst signiert mit einer sogenannten WHQL-Signatur.
Ältere Treiber ohne WHQL-Signatur waren zwar dann nicht offiziell "Windows 10 kompatibel", ließen sich aber noch problemlos laden und weiter betreiben. Vor Erscheinen von Windows 11 wurden auch keine neuen Cross-Signing-Zertifikate mehr signiert, so dass eigentlich heute nur noch WHQL-signierte Treiber im Umlauf sein sollten.
Wie wird das technisch umgesetzt?
Microsoft nutzt
Application Control for Windows Richtlinien zur Umsetzung. Das ist eine Schnittstelle, die auf allen Windows 10/11 Editionen (auch Home) und ab Server 2016 unterstützt wird und aktiv ist. (irgendwelche Frankenstein-Versionen sind von dieser Aussage ausgenommen ...)
Richtlnien werden dort über eine GUID identifiziert. Die beiden in diesem Zusammenhang wichtigen Richtlinien sind:
- "Microsoft Windows Cross Certificates for Code Integrity Exceptions Audit Policy" {784C4414-79F4-4C32-A6A5-F0FB42A51D0D}
- "Microsoft Windows Cross Certificates for Code Integrity Exceptions Policy" {8F9CB695-5D48-48D6-A329-7202B44607E3}
Die beiden RIchtlinien unterscheiden sich nur darin, dass die "Audit" Richtlinie alles erlaubt und Verstöße protokolliert, während die andere Richtlinie nicht erlaubte Treiber blockiert.
Aktuell gibt es folgende Einträge in den Richtlinien, die Microsoft als vertrauenswürdig betrachtet:
- die standardmäßigen Microsoft-Zertifikate
- etwa 650 Cross-Signing-Zertifikate
- etwa 1150 individuelle Datei-Hashes
Damit wird also nicht nur WHQL-Signaturen vertraut, sondern auch einem ganzen Haufen alter Treiber, die Microsoft überprüft und als unproblematisch eingestuft hat. Es ist also ganz ausdrücklich eine
Erlaubnisliste! (Info für alle "Besserwisser", die schon anfangen wollen, Richtlinien zu löschen ...)
Wie ist der Ablauf?
Ab April 2026 (also Mitte oder Ende April) wird dieses Feature nach und nach aktiviert (Controlled Feature Rollout). Zuerst ist nur die Richtlinie {784C4414-79F4-4C32-A6A5-F0FB42A51D0D} aktiv, also die "Audit"-Richtlinie. Die Richtlinie {8F9CB695-5D48-48D6-A329-7202B44607E3} wird erst dann aktiviert, wenn mindestens 100 Stunden Laufzeit und 3 (bzw. 2) Reboots vergangen sind und kein Versuch unternommen wurde, einen nicht vertrauenswürdigen Treiber zu laden.
Wie ist der technische Ablauf?
Unter dem Schlüssel "HKLM\System\CurrentControlSet\Control\CI\WhqlOnlyEvaluation" werden die Statusinformationen gespeichert. Es gibt folgende Werte:
- SystemUptime: Kummulierte Anzahl der 100-Nanosekunden Einheiten der Laufzeit (QWORD)
- NumBootSessions: Anzahl der Neustarts (DWORD)
- NumAudits (DWORD)
- NumBlocks (DWORD)
Wenn ein Treiiber geladen wird, der nicht als vertrauenswürdig gilt, werden die ersten beiden Einträge auf 0 gesetzt, und die anderen beiden jeweils um eins erhöht. "
NumAudits" und "
NumBlocks" scheinen aber nur statistischen Zwecken zu dienen und haben sonst keine Bedeutung. Das ganze passiert im Windows-Kernel bei jedem Versuch, einen Treiber zu laden.
Die Erfassung der Laufzeit-Informationen erfolgt über die "Microsoft Dignostics" Schnittstelle. Dazu werden fünf Callbacks registriert:
- Driver.Allow
- Driver.Retry
- Driver.Block
- Wintrust.EncodedCertificate
- Wintrust.SignatureVerification
Wann immer eines der Events auftritt, wird "
SystemUptime" und "
NumBootSessions" aktualisiert. Dazu werden zusätzlich noch im gleichen Registrieungsschlüssel die Einträge "
SystemUptimeTimestamp" und "
LatestBootId" benutzt.
Falls bei einem Update der Wert "
SystemUptime" >= 3600000000000 ist (100 Stunden in 100ns-Einheiten) und gleichzeitig "
NumBootSessions" >= (3 - OsVersion) ist (mit OsVersion 0 = Workstation, 1 = Server), wird die Richtlinie {8F9CB695-5D48-48D6-A329-7202B44607E3} aktiviert.
Es handelt sich bei den Registry-Einträgen nicht um read-only Kopien von internen Kernel-Zuständen, sondern um regulär les-/schreibbare Werte. Auch die Aktivierung der Richtlinie lässt sich aus einem unsigniertem Prozess einfach mit der API "
ManageCI_BeginUpsertSystemCIPolicy" durchführen.
Welche sonstigen Vorausetzungen gibt es?
Das ist etwas schwierig zu sagen, da alles undokumentiert ist. Das ganze System betrifft auf jeden Fall nur Kernel Mode Treiber. Nicht betroffen sind:
- Normale Anwendungen und "Apps"
- Systemdienste
- "Pseudo-Treiber" (z.B. Farbprofile, Audio-Codecs, PDF-Drucker, ...)
Grundsätzlich kann man sagen: Wenn die Dateierweiterung nicht
*.sys lautet, dann ist es auch kein Kernel Mode Treiber.
Inaktiv ist die erzwungene WHQL Richtlinie auf jeden Fall, wenn mindestens eine der Bedingungen zutrifft:
- "Test Signing" ist aktiv
- Ein Windows Upgrade wird durchgeführt
- WindowsPE wird ausgeführt
- "Flight Signing" ist aktiv
- Es handelt sich um eine Insider-Version
- Mindestens eines von drei weiteren Feature-Bits ist gesetzt. Da diese aber undokumentiert sind, kenne ich deren Bedeutung nicht. Von der Wertigkeit der Bits her würde ich aber vermuten, dass die Bits ebenfalls mit Beta/Dev/Canary Versionen in Bezug stehen
- Das aktuelle Datum liegt vor dem 29. Juli 2015 (Zeitpunkt, ab dem WHQL-Signaturen für alle Treiber verpflichtend wurden, um sich "Windows 10 kompatibel" nennen zu dürfen)
Was ist sonst noch wichtig?
Ein paar unsortierte Hinweise:
- Bei den beiden Richtlinien wird kernel-seitig eine Microsoft-Signatur erzwungen. Wenn also jemand auf die Idee kommt, die SIgnatur der Richtlinie zu ändern oder gar zu löschen, dann bootet Windows nicht mehr. Das hat nichts mit SecureBoot zu tun und betrifft sogar das Booten von einem USB-Stick mit einer aktuellen Windows-ISO. Man müsste in einem solchen Fall also auf eine ältere Windows-ISO oder auf Linux zurückgreifen, um das System wieder zu repaprieren.
- Das Aktivieren bzw. Deaktivieren der Speicherintegrität (VBS) scheint keinen Einfluss auf die Funktion der Application Control for Windows Richtlinien zu haben. Allerdings gibt es den Registry-Eintrag VerifiedAndReputablePolicyState. Dieser zeigt nur bei aktivem VBS die Werte 1 (Enforced) oder 2 (Audit) an, während bei deaktiviertem VBS dort immer 0 steht. Möglicherweise steht das in Verbindung mit Smart App Control (SAC), die auch einige Richtlinien mit dem Präfix "VerifiedAndReputableDesktop" und "VerifiedAndReputableDesktopEvaluation" benutzt.
- Die Log-Einträge in der Ereignisanzeige sind nur für den Benutzer bestimmt. Die Entscheidung, wann die "Enforced" Richtlinie aktiv wird erfolgt nur aufgrund der Registry-Werte.
- Die "Audit" Richtlinie bleibt aktiv, auch nachdem die "Enforced" Richtlinie aktiviert wurde.
- Wenn ihr wissen wollt, ob die Richtlinien für euch Probleme bereiten werden, dann schaut einfach auf eurem eigenen System in der Ereignisanzeige nach und führt nicht stumpfsinnig irgendwelche Programme oder Anleitungen aus, die euch von LLMs oder anderen Benutzer vorgesetzt werden.
