[English]Zum Patchday am 14. September 2021 hat Microsoft für die unterstützten Windows-Systeme Sicherheitsupdates freigegeben, die auch weitere PrintNightmare-Schwachstellen beseitigen sollen. Diese Updates verursachen aber Probleme, so dass Netzwerkdrucker nicht mehr angesteuert werden können. In einigen Fällen könnte ein einfacher Workaround helfen, ohne dass das Sicherheitsupdate deinstalliert werden muss.
Anzeige
Die PrintNightmare-Druckprobleme
Seit Anfang Juli 2021 sind Schwachstellen im Windows Print-Spooler öffentlich, die eine Remote Code Execution (RCE) ermöglichen (siehe PoC für Windows Print-Spooler-Schwachstelle öffentlich, hohes RCE-Risiko). Ein Angreifer könnte beliebigen Code mit SYSTEM-Rechten ausführen. Dies umfasst Programme zu installieren, Daten anzuzeigen, zu ändern oder löschen oder neue Konten mit vollen Benutzerrechten zu erstellen.
Zum Patchday am 14. September 2021 gab es einen weiteren PrintNightmare-Fix, der aber wieder Probleme aufwirft. So können Drucker an Terminalservern oder Print-Servern nicht mehr drucken. Ich hatte im Blog-Beitrag Patchday-Nachlese Sept. 2021: Neues PrintNightmare-Fix-Desaster bereits über das Thema berichtet.
Microsoft hat Ende letzter Woche die Probleme eingestanden und gibt den Ratschlag zur Druckertreiberaktualisierung, um wieder drucken zu können. Ich bin im Blog-Beitrag Windows PrintNightmare: Microsoft bestätigt Probleme nach Sept. 2021-Update auf dieses Thema eingegangen. Falls die Aktualisierung der Druckertreiber nicht hilft, sollen Nutzer an die OEMs gehen und neue Treiber anfordern – leichter gesagt als getan.
Ein Workaround ohne Update-Deinstallation
Als Konsequenz aus den Microsoft-Empfehlungen deinstallieren Administratoren die Sicherheitsupdates vom 14. September 2021, um die Drucker wenigstens zum Laufen zu bringen. Es gibt aber einen Ansatz, der ohne Deinstallation des Updates möglichweise ebenfalls (temporärer) eine Lösung bringt.
Anzeige
Erklärungen zum Hintergrund
Sicherheitsforscher Benjamin Delpy, der sich seit Monaten intensiv um das Thema PrintNightmare kümmert, hat auf Twitter einige Tweets abgesetzt, die möglicherweise etwas mehr licht in das Thema bringen.
Seit längere Zeit ist die Spoofing-Schwachstelle CVE-2021-1678 bekannt (im Januar 2021 hat Microsoft da was dazu veröffentlich, siehe auch meinen Blog-Beitrag Details zur Windows NTLM-Schwachstelle CVE-2021-1678 veröffentlicht). Wie ich jetzt bei Benjamin Delpy herauslese, betrifft dies auch die Drucker-RPC-Bindung und die Authentifizierung für die Remote-Winspool-Schnittstelle.
Microsoft hat über Sicherheitsupdates im Januar 2021 und im September 2021 begonnen, diese Schwachstelle zu schließen. Dazu wurde ein neuer Registrierungseintrag festgelegt, über den Administratoren die RPC-Authentifizierungsebene erhöhen oder erniedrigen konnte.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print
Wird der DWORD-Wert RpcAuthnLevelPrivacyEnabled=1 gesetzt, verschlüsselt Windows die RPC-Kommunikation mit den Netzwerkdrucker bzw. Druck-Servern. Diese Sicherheitsmaßnahme wurde aber per Sicherheitsupdate in zwei Stufen ausgerollt:
- Seit dem 12. Januar 2021 gab es dazu eine sogenannte Bereitstellungsphase, in der Administratoren diesen Registrierungswert setzen
- Mit dem Sicherheitsupdate vom 14. September 2021 wurde die Erzwingungsphase eingeleitet, d.h. die RPC-Verschlüsselung ist standardmäßig aktiv.
Die Details lassen sich im Microsoft-Supportbeitrag Managing deployment of Printer RPC binding changes for CVE-2021-1678 (KB4599464) (hier auf Deutsch). Genau dies könnte die Verbindungsprobleme von Clients mit dem Windows Drucker-Spooler in diverse Szenarien erklären. Denn es wird berichtet, dass nach Installation des September 2021-Update kein Drucken mehr möglich sei.
Dieser Workaround könnte helfen
Statt nun das Sicherheitsupdate vom 14. September 2021 zu deinstallieren, sind Nutzer auf die Idee gekommen, den Erzwingungsmodus (Enforcement mode) auf dem Server zu deaktivieren.
Wenn ich den obigen Tweet richtig interpretiere, reicht das Deaktivieren der betreffenden Einstellungen unter:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print\
auf dem Server, damit wieder gedruckt werden kann. Dort ist der DWORD-Wert:
RpcAuthnLevelPrivacyEnabled=0
einzustellen und dann der Print-Spooler neu zu starten (siehe diesen reddit.com-Thread und im Forum von Bleeping Computer). Vielleicht hilft es jemandem weiter. Beachtet zudem meine Hinweise im Blog-Beitrag Patchday-Nachlese Sept. 2021: Neues PrintNightmare-Fix-Desaster, wo ich Hinweise zum Fehler 0x0000011b gegeben habe.
Ähnliche Artikel
PoC für Windows Print-Spooler-Schwachstelle öffentlich, hohes RCE-Risiko
Windows Print-Spooler Schwachstelle (CVE-2021-1675, PrintNightmare) von MS bestätigt; CISA warnt
Nachlese: Das Chaos-PrintNightmare-Notfall-Update (6./7.Juli 2021)
Notfall-Update schließt PrintNightmare-Schwachstelle in Windows (6. Juli 2021)
PrintNightmare-Notfall-Update auch für Windows Server 2012 und 2016 (7. Juli 2021)
Microsoft zur PrintNightmare-Schwachstelle CVE-2021-34527: Windows ist nach Patch sicher
Windows-Schwachstelle PrintNightmare: Es ist noch nicht vorbei (15. Juli 2021)
PrintNightmare: Point-and-Print erlaubt die Installation beliebiger Dateien
Microsoft Defender for Identity kann PrintNightmare-Angriffe erkennen
0Patch Micropatches für PrintNightmare-Schwachstelle (CVE-2021-34527)
0patch-Fix für neue Windows PrintNightmare 0-day-Schwachstelle (5. Aug. 2021)
Windows PrintNightmare, neue Runde mit CVE-2021-36958
Ransomware-Gang nutzt PrintNightmare für Angriffe auf Windows Server
Vice Society: 2. Ransomware-Gang nutzt Windows PrintNightmare-Schwachstelle für Angriffe
Microsofts macht bei PrintNightmare auf „schlanker Fuß"
Windows: PrintNightmare-Nachlese und Stand (27. August 2021)
Patchday-Nachlese Sept. 2021: Neues PrintNightmare-Fix-Desaster
Windows PrintNightmare: Microsoft bestätigt Probleme nach Sept. 2021-Update
Patchday: Windows 10-Updates (14. September 2021)
Patchday: Windows 8.1/Server 2012-Updates (14. September 2021)
Patchday: Updates für Windows 7/Server 2008 R2 (14. September 2021)
Anzeige
Der Schlüssel existiert hier nicht…
ich habe
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint]
"RestrictDriverInstallationToAdministrators"=dword:00000000
gesetzt und das funktioniert
Cool, beim nächsten freien Zeitfenster dann mal testen ob es auch in unserer Umgebung funktioniert.
Wo stand das bitte das die RPC-Verschlüsselung nun scharf geschalten wird? Hätte man das wissen müssen?
Auf unserem 2012R2 existierten beide Einträge nicht :-(
Ich hab den Eintrag angelegt und die Drucken funzen nun wieder.
Sind die Server mit deaktivierten Enforcement mode nicht anfällig für den ZeroLogon exploit? Oder betrifft das nur Domain Controller?
Wenn man diesen Schlüssel setzt, macht man dann nicht absichtlich das Scheunentor (bzw. einen Teil davon) wieder auf, das eigentlich durch den ganzen Patchwahnsinn geschlossen werden sollte?
Danke! Ein Lebensretter! Seit RpcAuthnLevelPrivacyEnabled=0 können unsere Macs auch wieder auf dem Printserver drucken :-)
Ja scheint bei uns auch der Fall zu sein. Aber was muss denn nun gemacht werden, dass es "enabled" auch auf den mac´s funktioniert? Hat da jemand Infos zu?
Vielen Dank, der Workaround mit dem
„RestrictDriverInstallationToAdministrators"=dword:00000000
auf unserem Printserver hat uns super geholfen! :-)
Nach gestrigen Updates auf dem Printserver (2012R2), Patch KB 50055613 (2021-09 – Monatliches Sicherheitsqualitätsrollup) konnte einige Mitarbeiter:innen nicht mehr über freigegebene Netzwerkdrucker drucken. Beim Großteil funktionierte es zwar noch, also kein generelles Problem, trotzdem für die Betroffenen ärgerlich.
Auch ein mit Admin-Rechten angemeldeter User konnte nicht mehr drucken, lag also nicht (nur) an mangelnden Berechtigungen.
Beim Aufruf der "Anschlüsse" in den Druckereigenschaften keine Liste der (möglichen) Anschlüsse mehr, auch nicht LPT1 oder USB zur Auswahl. Hinzufügen von Anschlüssen oder Netzwerkdruckern ebenfalls nicht möglich.
Nach dem Setzen des Reg-Schlüssels war Drucken bei allen wieder *sofort* möglich, kein Server- oder PC-Neustart notwendig. Auch Hinzufügen von freigegebenen Druckern wieder möglich. Genau wie bei Tom existierte der Schlüssel vorher noch gar nicht.
Was für ein "Nightmare" mit dieser Sicherheitslücke ! :-(
Sorry, ich vergaß, dass wir nach dem Hinzufügen des Reg-Keys noch den Druckspooler-Dienst neu gestartet haben, also nicht ganz so "sofort", wie vorher beschrieben ;-)
Hier steht die Information drin:
https://support.microsoft.com/de-de/topic/verwalten-der-bereitstellung-von-%C3%A4nderungen-der-drucker-rpc-bindung-f%C3%BCr-cve-2021-1678-kb4599464-12a69652-30b9-3d61-d9f7-7201623a8b25
Phase 1 Januar
Phase 2 September enforce
Ausserdem wurde es am webcast von Microsoft vom letzten Mittwoch auch erwähnt.
Bei mir hat das Hinzufügen des DWORD RpcAuthnLevelPrivacyEnabled mit dem Wert 0 und neustarten der Druckerwarteschlange auf den Servern funktioniert. Die Kollegen konnten danach sofort wieder drucken.
Vielen Dank für die Beschreibung des Workarounds.
Interessanterweise sind ja die Treiber jeweils auf den betreffenden Stationen vorhanden, das System möchte diese nur einmalig (mit Administrator-Anforderung) aktualisieren, und dies auch vereinzelt nur bei manchen Stationen, nicht allen.
Hier hat meiner Meinung nach MS 'irgendetwas' in der Vergangenheit verkehrt gemacht, sodass die Treiber zwar installiert, aber anscheinend niemals (lokal) aktualisiert wurden.
Interessanterweise ist bei Neu-Anmeldungen (noch kein Profil des Users auf der Workstation) auch etwas in der Drucker-Zuweisung schief gelaufen, denn diese User haben dann in der Regel keinen Drucker in ihrem Profil zugewiesen.
Was uns betrifft, lösen wir das zukünftig durch eine eigene Zuweisung über eine selbst entwickelte Komponente, welche wir in unser eigenes Software-Verwaltungs- und Management-System integriert haben. Auf MS verlassen wir uns in diesem Punkt bestimmt nicht mehr :(
Wer
RestrictDriverInstallationToAdministrators"=dword:00000000
Setzt sollte dringend auch eine Liste der Printserver für Point aber Print und Point aber Print packs setzen. Der Key stellt den Zustand vor dem August Patch wieder her und die Lücke ist wieder nutzbar.
Microsoft macht zwar viele Fehler aber ist nicht immer Schuld @drucktreiber.
Das mit dem Fenster zum "aktualisieren" kommt vornehmlich bei älteren hp treiben und einigen Xerox. Wenn man bei hp auf den neuesten Universal Treiber verwendet, besteht das Problem dann nicht mehr da dort die neueste Druck api verwand wird.
Aktuell ist v4 aus 2016, gibt aber noch mehr als genug v3 Treiber
Nun könnte man sagen der Fehler liegt bei ms das v3 überhaupt noch funktioniert hat aber wenn aufgrund der Abschaffung einer Schnittstelle ein Gerät nicht mehr geht ist ja auch ms Schuld und nicht der Hersteller des Gerätes ;)
klar doch: MS könnte ja auch eine Aussagekräftige Meldung ausgeben!
Achtung Druck API V3 nicht mehr unterstützt bitte updaten oder so …
Es ist ja schließlich nicht der Druckerhersteller der einfach so API stilllegt!
Die Hersteller werden über die neuen Versionen schon informiert. Und in diesem Fall hatten die Hersteller wohl mind. 5 Jahre Zeit.
Stillgelegt ist v3 auch nicht vollständig. Mit v4 scheint es aber so wie es aktuell aussieht keine Probleme zu geben. Und ich finde eben in der Zeit hätte sich jeder der großen Druckhersteller einmal schon damit beschäftigen können.
Haben von unterschiedlichen hard / Software Herstellern schon öfter in anderen Fällen Infos vor einem patchday bekommen das Version x,y z eines Produktes aktualisiert werden muss vor Patch x damit es keinen ärgert gibt.
So manche Firma interessiert das aber eben einfach nicht / oder erst wenn eben 10000de Geräte nicht mehr funktionieren.
Die Druckerhersteller werden aber leider keine Treiber für 10 Jahre alte Drucker mehr neu schreiben, nur weil MS das Treibermodell von V3 auf V4 umgestellt haben. Die Leute sollen neue Drucker kaufen.
angeblich gehen mit v4 manche Filter und Druckseitenzähler von Drittanbietern nicht. Sagt beispielsweise Papercut: https://www.papercut.com/kb/Main/WindowsType4PrintDrivers
Jain. Zum einen wenn wir bei hp bleiben geht der upd auch für Recht alte Modelle und wird weiter entwickelt. Nur halt meist eher nur um neue Features wie Drucker Patronen als Service mit Telemetrie zu verbauen.
Zum anderen dürfe es fast ist nicht funktionieren das 10 Jahre alte Schnittstellen fehlerfrei und ohne Lücken funktionieren.
Unter Linux habe ich mit alten drucken am Desktop leider nicht zu tun. Funktioniert ein 10 Jahre alter Treiber ohne Anpassungen heute noch?
Es scheint sich auch gerade herauszukristallisieren, dass sich das Problem quasi von selber löst, wenn sowohl der Printserver als auch der Client den gleichen Patchstand (also momentan September-Patchday) haben. Den Ansatz hatte ich vorgestern irgendwo gelesen, und bei uns ist das gerade auch so, der Kyocera geht wieder, obwohl der Druckserver das September-Update wieder installiert hat. Inzwischen sind halt auch alle Clients auf dem aktuellen Stand.
Kurzer Kommentar eines Linux-Users:
Debian = treiberloses Drucken
Windows = druckerloses Treiben
Kurzer Kommentar eines Windows-Admin zum kurzen Kommentar eines Linux-Users:
Sinnloser Kommentar.
Es drängt sich die Frage auf:
Warum müssne Linux-User immer überall ihren Dünnpfiff abladen? Haben die ein Aufmerksamkeitssyndrom?
Einem sinnlosen Kommentar mit einem noch sinnloserem Kommentar zu begegnen ist… irgendwie sinnlos!?
Betriebssystemunabhängiger User:
Gleiches machst du auch immer, vielleicht mal in den Spiegel schauen.
Kann mich leider nur anschließen:
August-Update benötigte für den Betrieb "nur" RestrictDriverInstallationToAdministrators=0.
Seit dem September-Update musste dann auch noch schnell RpcAuthnLevelPrivacyEnabled auf dem Print-Server eingerichtet werden. Vorher waren keine Drucker mehr verbunden/"verbindbar".
Ob tatsächlich beide Keys benötigt werden, kann ich noch nicht genau sagen.
Gibt es denn schon Empfehlungen das ganze "sauber" zu konfigurieren?
Na ja, sauber konfiguriert ist es, wenn man das alles gar nicht macht. Ihr macht jetzt hier Workarounds, die die erhöhten Sicherheitseinstellungen wieder rückgängig machen. Das muss natürlich jeder für sich selbst entscheiden, aber "sauber" ist das eben gerade nicht.
Hallo riedenthied,
was wäre Ihrer Meinung nach der beste Weg, um zum einen den Patch installiert zu lassen und dennoch den Clients im Unternehmen die Funktion Drucken zu ermöglichen?
Wir haben überwiegend Kyocera Geräte, hilft es v4 Treiber einzusetzen?
Aufgefallen ist, dass die v4 Treiber deutlich "schlichter" in der GUI sind und deutlich langsamer was den Ausdruck und Spool-Zeit betrifft.
Kunde hat TA, die ja umlackierte Kyocera sind. TA sagt wörtlich "wenden Sie sich mit diesem Problem an Windows" :-( Wir sind am Verzweifeln…
klappte prima mit dem RegSchlüssel. konnte wieder Netzwerkdrucker verbinden und drucken.
Bei meinem Kunden hat zwar das Runterstufen der RPC Sicherheit geholfen daß wieder prinzipiell gedruckt werden kann,
ABER
beim Aufrufen der Druckereinstellungen (z.B. um von Farbe auf s/w zu wechseln) stürzt der Client PC ab.
Gibt es da schon eine Lösung?