[English]Im Beitrag geht es um den OneDrive-Client, den Microsoft mit Windows 10 liefert. Wie schaut es 'unter der Haube' mit der Implementierung, insbesondere in Bezug auf Sicherheit aus? Wenn es von Microsoft kommt, muss dass ja gut sein, oder? Ich habe mal wieder die 'Nadel im Heuhaufen' gesucht …
Anzeige
Am Anfang war das Wort …
In Windows 10 liefert Microsoft ja einen OneDrive-Client mit. Dieser soll möglichst überall mit dem gleichnamigen Cloud-Dienst genutzt werden, wenn es nach Microsoft geht – alles andere ist irgendwie 'old school'. Wer sich kritisch ob 'der Daten in der Cloud' äußert, wird oft schräg angesehen oder als Aluhut-Träger abgestempelt.
Spätestens nachdem ich diesen Artikel gelesen habe (plane noch eine separaten Beitrag dazu), kam auch die Idee für einen Beitrag mit 'Blick unter die Haube'. Denn ich hatte vom Stefan Kanthak, der sich viel mit Sicherheitsfragen beschäftigt, einige Fragmente mit Informationen zu OneDrive und Sicherheitsproblemen vorliegen. Es war eine dieser (mir über cc zugegangenen) Mails von Stefan Kanthak, die ganz harmlos begann und den Stein ans Rollen brachte:
> Eine Freundin hat unter Windows 10 OneDrive deaktiviert, weil sie den
> Dienst nicht mehr nutzen wollte.Wieso hat sie diesen UEBLEN UNSICHEREN Schrott ueberhaupt aktiviert?
Und dann folgte auf die Frage im letzten Satz eine Salve an Aussagen zum OneDrive-Client und dessen Schwachstellen von Stefan Kanthak, die ich nachfolgend schrittweise aufbereiten werde.
Anmerkung: Es gibt noch OneDrive for Business aus dem Office-Umfeld, was faktisch ein anderer Client ist. Ich habe diesen Client nicht untersucht. Aber der Verdacht liegt zumindest nahe, dass es dort nicht anders ausschaut. Das Ganze wird im Verlauf der folgenden Ausführungen klarer.
Unbekannt: "Designed for Windows"-Richtlinien
Ich hatte es schon mal in dem einen oder anderen Blog-Beitrag angerissen: Wenn ich mir die Windows-Entwicklung ab Windows 8 so ansehe, hänge ich den Design-Grundlagen nach, die Microsoft mal in den Frühzeiten von Windows 95 veröffentlicht hatte (siehe meinen Blog-Beitrag Nostalgie: Blick auf das Design von Windows 95).
Anzeige
Es gibt noch viele weitere Dokumente, die Microsoft seinerzeit für Software-Entwickler zusammen getragen hat. Auch wenn ich längst aus der Entwicklung raus bin, fand ich diese Richtlinien sehr sinnvoll. Ziehen diese doch Leitplanken ein, an denen sich ein Entwickler orientieren kann, um halbwegs passable Software zu stricken. Dieses Wissen scheint aber in Redmond entweder verloren gegangen, oder ins Firmenmuseum ausgelagert worden zu sein, oder nicht mehr in die heutigen Entwicklungsprozesse zu passen. Stefan Kanthak umschreibt es etwas direkter:
Die VOLL***, die diesen Schrott [gemeint ist der OneDrive-Client unter Windows] gefrickelt haben, ignorieren die MINIMAL-Vorgaben der inzwischen 23 Jahre alten "Designed for Windows"-Richtlinien.
Sie installieren diesen SCHROTT nicht unter %ProgramFiles%, wo er vor Schreibzugriffen durch Benutzer sicher ist, sondern in das Benutzerprofil JEDES Benutzers.
Das war etwas, was mir auch schon aufgefallen war, wo ich mir aber keinen Reim drauf machen konnte. Es ist in der Tat so, dass der OneDrive-Client in jedem Benutzerprofil unter
C:\Users\%USERNAME%\AppData\Local\Microsoft\OneDrive
mit allen Dateien zu finden ist. Neben den .exe-Dateien samt Updates sind dort auch Konfigurationsdateien zu finden.
(Zum Vergrößern klicken)
Es ist in der Tat so, dass ein Benutzer (aber auch Malware) auf diesem Ordner Schreibrechte besitzt, also die OneDrive-Dateien nach Belieben manipulieren kann. Ein Ansatz, der gemäß den "Designed for Windows"-Richtlinien seit 23 Jahren verpönt ist. Aber so alte Sachen liest man in Redmond bei den Entwicklern wohl nicht mehr – und die alten Hasen sind längst gegangen oder gegangen worden. Eine weitere mögliche Erklärung findet sich in Teil 3 der Artikelreihe – dann würde Microsoft schlechte Kompromisse eingehen und als Windows-Nutzer sollte man seine Schlüsse ziehen.
Leider geht die Geschichte noch weiter, und das keineswegs positiver. Die Microsoft-Entwickler haben sich weitere Schnitzer wie die Verwendung veralteter OpenSource-Bibliotheken mit Sicherheitslücken geleistet. Das ist aber Bestandteil von Teil 2 dieser Artikelreihe
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
Anzeige
Lieber Günter,
vielen Dank für die wie immer gut aufgearbeiteten Infos. Mach bitte weiter so und lass Dich nicht durch Kommentare mancher "Micro$oft Fanboys" nerven (ich nehme an, die kleine Spitze mit der "Suche nach der Nadekl im Heuhaufen" zielt auf das Kommentar-Geschreibsel auf den Artikel "Windows 10 V1803: Probleme, welche Probleme? Oh, doch!" ab).
Ich oute mich hiermit als "Aluhut-Träger" :-) Oder liegt es daran, dass ich Ü50 bin und nicht mehr jeden heißen Sch… mitmachen will?
Wenn das Zeugs wenigstens ausgegoren wäre … Das Testen überlasse ich den jungen, die sollen selber ihre Erfahrungen machen und dafür im Firmenumfeld gerade stehen.
Grüße
Thomas
Achtung zynisch:
Naja… verhält sich doch eh wie viele andere Apps die jedem Benutzer reingewürgt werden. Ist doch praktisch, wenn man da direkt reinschreiben darf!
Ich zitier aus der Windows 10 update History Webseite von Microsoft:
"Windows 10 is a service, which means it gets better through periodic software updates."
Also wozu sorgen machen?
Ich habe den Müll de-installiert. Das geht tatsächlich auch ohne Ccleaner und es installiert sich nicht wieder plötzlich von selbst neu, wie die schrägen Spiele oder das "Deutsch local experience pack".
Gibt es die "Designed for Windows"-Richtlinien eigentlich wirklich? Also findet man diese irgendwo? Wie "man es machen sollte", also welche Daten in welches Verzeichnis gehören, weiß ich, aber gibt es dazu Vorgaben von Microsoft in Textform, die für externe Programmierer zugänglich sind?
Ich denke, es ist vieles verstreut auf den Microsoft-Seiten zu finden – bin da aber nicht so der Spezialist. Hier mal Einstiegspunkte (aus meinem Artikel hier).
CWE-426: Untrusted Search Path
CWE-427: Uncontrolled Search Path Element
CAPEC-471: DLL Search Order Hijacking
What are Known DLLs anyway?
Dynamic-Link Library Security
Microsoft Security Advisory 2269637
Secure loading of libraries to prevent DLL preloading attacks
Load Library Safely
https://docs.microsoft.com/en-us/windows/desktop/win_cert/certification-requirements-for-windows-desktop-apps
Speziell hier ist mir ja die Sicherheitslücke noch nicht ganz klar… Software mit Rechten des Benutzers kann… hmm… lokale Programmdateien des Benutzers manipulieren? Also um das Profil zu hacken und/oder an die OneDrive-Inhalte zu kommen gibt es da sicher leichtere Varianten, oder wie Raymond Chen es immer nennt: "You are already on the other side of the airtight hatch".
Fatal wäre es doch nur, wenn die Programmdateien von mehreren Benutzern verwendet würden – globale Schreibrechte auf %ProgramFiles% sind das no go und von den Designrichtlinien ja auch verboten?
Ich bin nicht sicher, ob deine und meine Phantasie ausreicht, um mögliche Angriffsszenarien zu durchdenken. Im Sinne einer Tarnung ist es fatal, wenn eine Malware eine DLL für eine Anwendung mit lokalen Schreibrechten ersetzen kann. Jedes Mal, wenn diese Anwendung vom Benutzer oder Windows ausgeführt wird, liefe die Schadfunktion mit. Und wer sagt denn, dass nicht irgend ein Nutzer auf die Idee 'probiere mal Als Administrator ausführen' kommt?
Ist aber nicht relevant, denn am Ende des Tages gilt: Vermeide alles, was als unsicher bekannt ist, auch wenn Du jetzt noch nicht erkennen kannst, dass dies ausgenutzt werden könnte. Oder frei nach dem Sprichwort unserer Altvorderen: 'Der Krug geht so lange zum Brunnen, bis er bricht.'
AUTSCH!
Die Sicherheitslücke ist, dass dieser Schrott NICHT jenseits der Sicherheitsbarriere "%ProgramFiles%" installiert wird; damit existiert kein "airtight hatch".
Fatal ist, dass die Programmdateien SCHREIBBAR sind und somit von jedem unprivilegierten Prozess durch einen Schädling ersetzt werden können.
JFTR (also zum Nach DENKEN): write XOR execute!