Windows 10 und die OneDrive-Sicherheitslücken – Teil 2

[English]In Teil 1 des Beitrags zum Thema Sicherheit des OneDrive-Clients ging es um die Lage der Programmdateien im ungeschützten Profilordner. Aber die Microsoft-Entwickler haben sich weitere Schnitzer wie die Verwendung veralteter OpenSource-Bibliotheken mit Sicherheitslücken geleistet.

Unsichere OpenSSL-Bibliotheken verwendet

Stefan Kanthak machte mich in seiner Mail dann noch auf einen Sachverhalt aufmerksam, den ich zuerst kaum glauben konnte. Stefan schrieb mir:

Die Frickler dieses SONDERMUELLs sind anscheinend Gruenschnaebel aus
der OpenSource-Szene, die offensichtlich KEINERLEI Ahnung von Windows und von Software-Entwicklung haben!

Das aktuelle OneDriveSetup.exe, veroeffentlicht am 18.7.2018 um
16:56:01 GMT, verfuegbar via
<https://onedrive.live.com/about/en-us/download/> von
<https://go.microsoft.com/fwlink/p/?LinkId=248256> alias
<https://g.live.com/1rewlive5skydrive/skydrivesetup> alias
<https://oneclient.sfx.ms/Win/Prod/18.111.0603.0006/OneDriveSetup.exe>
installiert die veraltete (vom 28.8.2017) und UNSICHERE Version
1.0.2k des als OpenSSL beruechtigten OpenSource-Schrotts!

Nein, so etwas macht Microsoft nicht, das sind Profis, die mit Windows 10 am sichersten Windows aller Zeiten schnitzen. Das muss ich mir mal selbst anschauen. Also habe ich bei Stefan Kanthak nachgefragt, wie ich feststellen könne, ob OpenSSL installiert wird. Gut, jeder Entwickler, der das einsetzt, kennt die Bibliotheken. Stefan Kanthak schrieb dann, ich möge nach folgenden Dateien schauen.

DIR /A/S "%USERPROFILE%\???eay32.dll"
DIR /A/S "%ProgramFiles%\???eay32.dll"
DIR /A/S "%ProgramFiles(x86)%\???eay32.dll"
DIR /A/S "%ProgramData%\???eay32.dll"
DIR /A/S "%SystemRoot%\???eay32.dll"

Die beiden DLLs heißen ssleay32.dll und libeay32.dll – ich habe Dateien mit diesem Namen auch sofort im Profilordner einer aktuellen Windows 10 V1803 mit installierten August 2018-Updates gefunden.

(Zum Vergrößern klicken)

Stefan Kanthak schrieb dann noch: Weitere solchen Kandidaten sind libcurl.dll, libz*.dll alias zlib*.dll, *7z*.dll und viele mehr. Bei Dateinamen wie *7z*.dll klingelt selbst mir was (siehe mein Blog-Beitrag Warnung: Auf 7-Zip verzichten). Aber es gibt ja noch das OpenSSL-Thema.

Die Entwickler haben offenbar OpenSSL-Bibliotheken beim OneDrive-Client verwendet, ackern dabei aber auch noch am 18. August 2018 (als ich den Blog-Beitrag verfasst habe) mit der Version 1.0.2k, wie obiger Screenshot zeigt – ich habe die Datei ssleay32.dll per Rechtsklick angewählt und auf Eigenschaften geklickt. Stefan Kanthak hatte mir den Link auf folgende Webseite mitgeschickt:

https://www.openssl.org/news/vulnerabilities-1.0.2.html

Diese Webseite dokumentiert Schwachstellen in der OpenSSL-Bibliothek. Geht man die Seite durch, finden sich zwar einige Fundstellen zur Version 1.0.2k. Mir ist dort aber keine Textstelle bei der Suche aufgefallen, wo eine Schwachstelle für diese Version dokumentiert wurde. Aber ich habe zur Kenntnis genommen, dass Version 1.0.2k so irgendwann Januar 2017 aktuell war. Für Juni 2018 wird Version 1.0.2p in den letzten Fixes erwähnt. Sucht man aber gezielt nach den Begriffen 'OpenSSL 1.0.2k vulnerabilities', sollte man auf der Seite CVE-Details eine Menge Treffer finden. Es ist zwar keine kritische Schwachstelle dabei (der Level geht nur bis 5, Maximum wäre 10). Aber unter dem Strich setzen Microsofts Entwickler eine veraltete Open Source OpenSSL-Bibliothek ein.

Windows hat ein CryptoAPI …

Stefan Kanthak merkt in einer Mail süffisant an: Windows bringt seit 22+ Jahren ein CryptoAPI samt SChannel mit und braucht solchen Schrott NICHT! und ergänzt:

Microsofts Mantra "Keep your PC up-to-date!", das sie allen ihren Kunden regelmaessigst predigen, wird innerhalb dieser Klitsche mal wieder ignoriert!

Wo er Recht hat, hat er Recht – köpft jetzt bloß nicht den Boten der schlechten Nachricht. Es wäre Microsoft, was sich erklären müsste. Aber es liegen noch mehr Leichen im Keller, wie Stefan Kanthak ausführt.

zusaetzlich zu diesem ersten Griff ins Kl** sind diese Frickler entweder UNFAEHIG oder UNWILLENS (ich argwoehne: beides), eine Windows-Anwendung (genauer: eine "shell extension" fuer den Explorer) mit den Schnittstellen des Win32-API der Windows-GUI zu schreiben.

Hintergrund für diesen Wutausbruch: Die Entwickler des OneDrive-Clients verwenden statt der wohl dokumentierten und per Update gepflegten Windows API die Qt5-Bibliothek. Stefan Kanthak schreibt:

   Stattdessen verwursten diese ANFAENGER (eine selbstverstaendlich
auch VERALTETE Version) des OpenSource-Ungetuems Qt5; dessen
Laufzeitumgebung Qt5*.dll belegt auf der Festplatte "nur" 20MB.
Im RAM sind es ETWAS mehr.

Das Ganze hat zwei Ebenen. Einmal kritisiert Kanthak die Verwendung einer veralteten (und 'fetten') Version von Qt5. Dort gelten im Grunde die gleichen Ausführungen wie oben zur veralteten OpenSSL-Bibliothek.

Ich postuliere mal, dass Microsoft in gewissen Sachzwängen steckt und die veralteten Open Source-Bibliotheken nicht als 'extrem gravierende Sicherheitsrisiken' eingestuft werden. Kann man teilen oder aus Anwendersicht kritisch sehen. Ich neige zu letzterem, gilt doch Microsofts Credo 'die Angriffe nehmen zu, aber wir entwickeln mit Windows 10 das sicherste aller Windows-Betriebssysteme'. Mit dem Material, was ich oben skizziert habe, fällt mir nur der Status zur Ausrüstung der Bundeswehr mit 'bedingt einsatzfähig' ein

Der zweite Punkt, den Kanthak kritisiert, ist die Verwendung von Qt5. Die Verwendung von Qt5 ist auf den ersten Blick unverständlich. Mir ist beim Schreiben dieses Blog-Beitrags aber einiges klar geworden. Diese Gedanken, sowie eine Stellungnahme Microsoft zum OneDrive-Client folgt in Teil 3.

Artikelreihe:
Windows 10 und die OneDrive-Sicherheitslücken – Teil 1
Windows 10 und die OneDrive-Sicherheitslücken – Teil 2
Windows 10 und die OneDrive-Sicherheitslücken – Teil 3

Ähnliche Artikel:
Microsoft und die Office 20xx-Sicherheitslücke in ose.exe
Sicherheitslücken in InfoZips UnZip-Programm
Warnung: Auf 7-Zip verzichten
F-Secure Sicherheitsupdates für 7-Zip-Schwachstellen