Schlagwort-Archive: RDP

Qt5: LoadLibrary-Fehler mit RDP unter Windows (ATI, OpenGL, Nextcloud)

Das Qt-Framework wird von vielen Projekten genutzt um grafische Oberflächen auf allen Betriebssystemen einheitlich entwickeln zu können. Bekannte Softwarepakete, welche Qt nutzen, sind unter Anderem: Nextcloud-Client, Owncloud-Client, FileZilla, Quassel, Mumble, MiniTube, Bitcoin-Qt, Scribus, LuminanceHDR, Audacious, Clementine, LMMS, VLC, AviDemux-qt, Shotcut, OpenShot, LibreCAD, FreeCAD, OpenSCAD, QOwnNotes, Calibre, KeePassX, KeePassXC, Wireshark und BlueStacks.

Eigentlich eine praktische Sache, jedoch mit einem Haken: Mit Qt5 versuchte man viele grafische Operationen per Hardwarebeschleunigung zu erledigen. Dies sorgt für schnellere Programme und weniger Systemlast. Für die Ansteuerung der Grafikkarte nutzt man hierbei OpenGL, welches auf allen gängigen Betriebssystemen verfügbar ist. Leider tritt man sich hierbei auch einige Probleme ein, so ist z.B. Windows dafür bekannt qualitativ zweifelhafte Treiber zu verteilen, welche stark auf Gaming optimiert sind, aber bei anderen Operationen gerne ins Straucheln kommen.

Ein recht verbreitetes Problem tritt dann auf, wenn eine AMD-Grafikkarte wie z.B. Radeon oder im System steckt, man jedoch auf den Windows-Rechner per Remote Desktop (RDP) zugreift. Windows lädt – auch wenn RDP genutzt wird – die Grafikkartentreiber. Ein Fehler in den ATI-Treibern, welcher bereits seit Ende der 2010er-Jahre bekannt ist, führt jedoch dazu, dass in RDP-Sitzungen Grafikoperationen nicht in Software ausgeführt oder von der Grafikkarte berechnet und zurückgegeben werden, sondern sie versuchen diese Trotzdem komplett in der GPU zu verarbeiten und brechen die Anfrage letztendlich ab. In vielen Anwendungen äußert sich das in fehlenden Grafikelementen oder Fehlermeldungen. So lässt sich z.B. der Nextcloud-Client gar nicht starten und Quittiert den Versuch die GUI per RDP zu öffnen mit einem fatalen Fehler. Es ist somit nicht möglich die Software per RDP zu starten.

Fehlermeldung NextCloud-Client: „LoadLibrary failed with error 87: The parameter is incorrect.“

Glücklicherweise kann man sich hierbei einer Eigenheit von „Shared Libraries“ zu nutze machen, welche peeter123 auf GitHub vorschlägt: Jede App bevorzugt seine eigene Version, nur wenn sie selbst nichts mitliefert wird auf jene des Systems zurückgegriffen. Im Falle des OpenGL-Bugs kann man also einfach statt der Microsoft/ATI-Version eine weniger kaputte nutzen. Hierzu eignet sich z.B. die Variante des Mesa-Projektes, welche die OpenGL-Operationen nicht direkt an die Grafikkarte sendet. Um diese nun einzubinden lädt man auf der Releases-Seite die letzte Release-Version für mingw herunter (mesa3d-xx.yy.zz-release-mingw.7z), öffnet diese (z.B. mit 7Zip) und kopiert aus dem Ordner x64 (für 64-Bit-Systeme) die Datei „opengl32.dll“ in den Ordner des betroffenen Programms, also z.B. C:\Program Files\Nextcloud. Hierdurch greift die Änderung nur für diese eine App und beeinflusst nicht alle installieren Programme. Fortan sollten die Operationen der Software ohne GPU-Treiber laufen und die Applikation somit auch per RDP lauffähig sein.

Durch diese Änderung verliert man zur potentiell etwas Geschwindigkeit in der betroffenen App, dies sollte bei aktuellen Systemen aber nicht groß auffallen – insbesondere, wenn man diese ohnehin nicht häufig aktiv nutzt. Immerhin ist die Software so auch remote nutzbar. Mit fortschreitender Migration auf Qt6 sollte sich das Problem mit der Zeit auch ganz von selbst erledigen: Dies nutzt statt OpenGL die jeweiligen Funktionen des Betriebssystems, welche auch auf Windows nicht ganz so kaputt sind.

Windows RDP: „Die angeforderte Funktion wird nicht unterstützt“ (CredSSP)

Zugegeben, ich bin etwas spät dran, aber heute bin ich bei einer Stelle mit CredSSP und RDP dann auch mal auf die Schnauze gefallen. Da mir das – dank sonst gepflegter Infrastruktur – bisher nicht begegnet ist hier nochmal zum Nachlesen. Und mich als Gedächtnisstütze.

Vorgeschichte

Verursacher der ganzen Misere ist CredSSP, der Credential Security Support Provider. Dieses Windows-Modul ist unter Anderem für die Authentifizierung von Nutzern bei Verbindungen über RDP (Remote Desktop Protocol) und WinRM (Windows Remote Management) zuständig. Durch einen Fehler im Umgang mit den Sitzungen (CVE-2018-0886) können Angreifer einen Man-in-the-Middle-Angriff ausführen und so die bestehende Sitzung übernehmen. Da RDP und WinRM häufig für administrative Zwecke genutzt wird, können sich so Unbefugte ggf. weitrechende Zugriffe auf die verwalteten Systeme beschaffen. Betroffen ist so ziemlich alles – vom einfachen Windows 7 über die Server-Produkte bis hin zum aktuellen 10 sowie Server 2016.

Fixing

Microsoft hat den Fix in mehreren Stufen ausgerollt. Erstmals erschienen passende Updates im März, welche das Problem prinzipiell beheben. Sofern sie überall installiert werden. Zwei Monate später, im Mai, zog der Hersteller dann die Sicherheitsschrauben an: Ab diesem Patch ist die Nutzung der Mitigation zwingend erforderlich.

Wer nicht plant guckt in die Röhre

Wer seine Systeme im Griff hat wird nicht viel merken – ist alles auf einem aktuellen Patchstand wird man von den Umstellungen nichts merken. Anders sieht es aus, wenn man bei den Updates nachlässig handelt. Hat der eigene Rechner bereits aktuelle Patches installiert, das Zielsystem jedoch seit März keine Wartung erfahren, hat man Pech: Der RDP-Client bzw. WinRM verweigern die Verbindung mit dem Zielsystem. „Die angeforderte Funktion wird nicht unterstützt“. Selbes dürfte auch für die andere Richtung gelten.

Und nu?

Was folgt sind zwei Dinge: Erst mal sollte man dem Verantwortlichen Admin des Zielsystems eine Schulung zu IT-Sicherheit verpassen, denn inzwischen mehr als ein halbes Jahr lang keine Updates installieren ist – zumindest meiner Meinung nach – grob fahrlässig. Danach sollte das Zielsystem natürlich auf einen aktuellen Stand gebracht werden – für den Zugriff mindestens notwendig ist der entsprechende CredSSP-Patch, welcher sich auch einzel im dazugehörigen Artikel finden lässt. Da für den nur ein Dopelklick notwendig ist kann das ggf. auch ein Poweruser mit passenden Zugriffen vor Ort erledigen. Hat man keine Möglichkeit das System selbst zu verändern muss man am Client ran: Hier kann man über die Registry oder per GPO auch unsichere Verbindungen zulassen und somit eine Verbindung zu den betroffenen Zielen wieder ermöglich. Dies sollte immer nur temporär geschehen – umstellen, verbinden, Fix installieren und wieder zurück. Keinesfalls sollte man während die Lockerung aktiv ist Verbindungen zu anderen Systemen aufbauen.

Registry

Hierzu liegt man unter HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters ein neues REG_DWORD mit dem Namen „AllowEncryptionOracle“ an und gibt diesem den Wert „2„.

GPO

Das Pendant in GPO-Form findet sich unter Computerkonfiguration\Administrative Vorlagen\System\Delegierung von Anmeldeinformationen\Encryption Oracle Remediation. Diese muss aktiviert und die Schutzebene auf „Vulnerable“ eingestellt werden.

EOF

Patchmanagement etablieren. Systeme zeitnah Patchen. Spart Arbeit. Und Axteinsätze bein den zuständigen Systembetreuern.