Diafero, danke für die Details zum "Patch" der Lücke.
Leider muss ich dir in deinen Ausführungen bezüglich Sicherheit in einigen Punkten widersprechen.
Erst einmal sollte man dazu klarstellen, was man unter "Sicherheit" verstehen will.
Unter Sicherheit versteht man folgende Aspekte
- Integrität (keiner kann Daten unerlaubterweise verändern)
- Authentizität (Herkunftsnachweis von Ressourcen - für Uru wohl weniger nötig)
- Verfügbarkeit (niemand kann das System lahmlegen, ernsthaft verlangsamen etc.)
- Nichtabstreitbarkeit (man kann gegenüber Dritten beweisen, dass etwas stattgefunden hat - für Uru wohl weniger nötig)
- Vertraulichkeit (Geheimhaltung von Ressourcen gegenüber Dritten - hier müsste man nachdenken, inwieweit das für Uru erforderlich ist: keine leichte Frage)
- Privatsphäre/Datenschutz als Cross Concern aller 5 Sicherheitsaspekte
zur
- Prävention (Vermeidung von Angriffen auf die Aspekte)
- Detektion (Erkennung von Angriffen auf die Aspekte)
- Wiederherstellung eines sicheren Zustands nach Angriffen
in dem Umfang, wie sie für die Erfüllung der Aufgabe des Systems erforderlich ist.
(vergleiche z. B.
http://omen.cs.uni-magdeburg.de/itiamsl ... 010_01.pdf Folien 54-56. Andere Bücher wie
Claudia Eckert: IT-Sicherheit (eines der deutschen Standardwerke zur IT-Sicherheit)
definieren das ähnlich, verwenden allerdings leicht andere Fachbegriffe).
Da zumindest Integrität und Verfügbarkeit der Höhlen (also in dem Fall: Player-Avatare sind keine Bahros ein Aspekt ist, den Uru offenbar zu gewährleisten hat, handelt es sich demnach definitiv um einen Angriff auf die Integrität - auch wenn dieser wegen ungenügender Maßnahmen seitens Cyan zur Gewährleistung eines angemessenen Integritäts-Niveaus recht einfach war. Und nicht wie du schriebst:
denn eine Lücke kann nur existieren, wo etwas drumherum ist - in Uru gibt es kein Sicherheitskonzept. Es wurde keine Lücke ausgenutzt. Es wurden einfach nur Dinge gemacht, die der "normale" Client nicht tut, sie aber durchaus tun könnte, das Protokoll und der Server erlauben es.
Damit kommen wir zum nächsten Punkt: was muss der Client und was der Server für die Integritäts- und Verfügbarkeitssicherung tun? Da Clientdaten im Internet eigentlich immer (auf Ausnahmen will ich an dieser Stelle nicht eingehen) bei Client-Server-Systemen als nicht vertrauenswürdig zu betrachten sind, reicht es aus, wenn der Client lediglich nicht fehlerhafterweise Dinge tut, die er nicht tun soll (um zu vermeiden, dass dies fehlerhafterweise als Angriff gesehen wird). Mehr braucht (und soll) er gar nicht zur Integritäts- und Verfügbarkeitssicherung beitragen. Warum? Ganz einfach: man kann sowieso davon ausgehen, dass sämtliche Sicherheitsmaßnahmen zur Integritäts- und und Verfügbarkeitssicherung im Client umgangen werden können (wie gesagt: auf Ausnahmen gehe ich nicht ein). Es bringt daher meist gar nichts (bzw. Security by Obscurity), Im schlimmsten Fall liefert es noch Hinweise auf mögliche Angriffe.
Also muss ein entsprechendes Sicherheitskonzept zur Sicherung dieser beiden Aspekte rein serverseitig implementiert werden. Du wirst also clientseitig nichts finden, was zur Sicherung dieser beiden Aspekte beiträgt. Und da ich nicht davon ausgehe, dass du Zugriff auf den Servercode hast, kannst du nicht beurteilen, ob (serverseitig) ein Sicherheitskonzept zur Integritätssicherung gibt oder nicht. Auch wenn ich eher auf "nein" tippen würde - da stimme ich dir zu.
Kommen wir zu deinem nächsten Punkt
Die Sache ist die, dass Uru von gesamten Design her extrem unsicher ist. Das lässt sich nicht korrigieren, ohne es von Grund an neu zu schreiben. Da hätten einige Tage Downtime mehr auch nichts gebracht... eher ein oder zwei Jahre.
Zweifellos ist es sicherheitsmäßig keine gute Idee (um es dezent auszudrücken) SQL-Befehle als Kommandos zu senden, was zumindest dafür spricht, dass in einer Phase des Protokolldesigns für Uru Sicherheitsaspekte ziemlich vernachlässigt wurden.
Im zweiten Punkt (neu schreiben erforderlich, was 1-2 Jahre dauert) stimme ich dir absolut nicht zu. Warum? Überlegen wir uns am besten dazu, was es denn überhaupt ermöglicht, durch Übergeben von nicht vorgesehen SQL-Befehlen auch einen nicht vorhergesehenen Befehl in der Datenbank auszuführen.
Antwort: weil die SQL-Strings des Protokolls direkt in der Datenbank ausgeführt werden, statt sie vorher auf Zulässigkeit zu validieren und sie nur, wenn sie zulässig sind, auszuführen.
Wie könnte man dies implementieren? Da die Korrektheit einer Anfrage auch vom aktuellen Zustand (den man erst aus der Datenbank auslesen muss) abhängen kann (Beispiel: bewege dich zu Punkt (1,2,3) kann korrekt sein, wenn sich der Avatar nahe dem Punkt befindet, aber cheaten, wenn er davon entfernt ist), ist der Weg, den ich implementieren würde, eine 2-Phasen-Validierung:
Phase 1: statische Vorvalidierung
Diese schließt aus, dass z. B. DELETE-Befehle abgesetzt werden oder auf Tabellen zugegriffen wird, auf die Spieler nicht zugreifen dürfen oder dass Dinge abgefragt werden, die das Spiel nicht abfragt (manche Datenbank-Anfragen können sehr aufwändig sein, weswegen die Schwachstelle über diesen Angriffspunkt eventuell auch Angriffe auf die Verfügbarkeit erlaubt) etc.
Phase 2: dynamische Validierung
Vorbedingung: die Anfrage ist grundsätzlich gültig (wird durch die Validierung in Phase 1 gesichert) könnte jedoch Informationen beinhalten, die der Spieler nicht tun/aktuell für ihn nicht erlaubt sind.
Die Lösung ist hier auf den betroffenen Tabellen einen Trigger zu setzen, welcher dynamisch die Anfragen auf Zulässigkeit überprüft.
In 4-5 Wochen wäre so etwas in meinen Augen realistisch zu implementieren. Anschließend sollte man natürlich sicherstellen, dass das
Wenn "sicher" jedoch, wie normalerweise, meinen soll, dass jeder nur das tun kann, was er vernünftigerweise tun können sollte - dann ist MOUL nur so lange sicher, wie es keiner probiert. Es gibt diverse Leute in der Community, die das Wissen und die Tools haben, die einzige Sicherheitsmaßnahme (wenn man sie denn so nennen kann) zu umgehen: Statt des vom Server beim Start geladenen Python-Codes wird eigener geladen.
Was sicher heißt, habe ich oben geschrieben. Uru ist es offenbar nicht. Sämtliche Sicherheitsmaßnahmen zur Sicherung der Integrität müssen - wie oben geschrieben - serverseitig implementiert werden. Beim Downloaden des Python-Codes beim Start handelt es sich nicht um eine Sicherheitsmaßnahme im Sinne der IT-Security, sondern um Security by Obscurity.