Sicherheitslücken in MO:ULagain

Hier werden alle grundsätzlichen und technischen Anforderungen und Probleme zu Myst Online: Uru Live diskutiert.
Antworten
Benutzeravatar
Mucol
Forscher
Beiträge: 2365
Registriert: 05.02.2004, 22:19
KI-Nummer: 157118
Kontaktdaten:

#1 Sicherheitslücken in MO:ULagain

Beitrag von Mucol » 08.05.2010, 11:45

Moin.

MO:ULagain ist wieder online (Status seht ihr übrigens hier im Forum auch immer über dem Forenkopf ganz oben).

Nur eine kleine Anmerkung zu der Offline-Zeit:
Die Server waren nicht down, weil es irgendwie technische Schwierigkeiten oder Server-Schluckauf gab, sondern weil einige "lustige" Spieler Sicherheitslücken entdeckt und ausgenützt hatten.

Also wurden das Spiel offline gesetzt um diese Sicherheitslücken zu schließen.
Das hatte einerseits den Effekt, dass wir alle nicht mehr spielen konnten, andererseits wurden bei Cyan durch diesen Vorfall (unnötig) Kapazitäten gebunden.

Rawa schreibt auch ganz klar:
Falls verbliebene Sicherheitslücken dazu ausgenützt werden wieder Unfug zu treiben, muss das Spiel deutlich länger offline gehen als es jetzt der Fall war (um endgültig alle Lücken zu schließen).

Mein Standpunkt dazu:
Wer auch immer sich in dieser "Szene" bewegt, möge sich doch gründlich überlegen, ob die eigene Eitelkeit Dinge tun zu können, die andere nicht tun können wirklich so wichtig ist, dass man in Kauf nimmt, dass sowohl Cyan als auch allen anderen Spielern dadurch Schaden entsteht.

Klar sind Sicherheitslücken nicht gut, und es ist wichtig sie zu entdecken.
Der Weg ist aber nicht, diese Lücken für sich selbst auszunützen, sondern sie dann diskret z.B. per PN an Rawa im MOUL-Forum weiterzugeben.

Mucol
Bild
Benutzeravatar
Seppolo
Forscher
Beiträge: 384
Registriert: 05.02.2010, 16:23
Geschlecht: männlich
KI-Nummer: 132492
Wohnort: Mitte von Sachsen, 01665 Klipphausen
Alter: 32
Kontaktdaten:

#2 Re: Sicherheitslücken in MO:ULagain

Beitrag von Seppolo » 08.05.2010, 12:37

Mmmm, das is ärgerlich! Das es immer (ich sag es mal) solche "Idioten" geben muss die einfach alles kaputt machen wollen!!! :wütend:

Cyan ist so schon genug gefährtet, stehen kurz vor dem Aus! Aber immer gibt es welche die es darauf anlegen! So was regt mich dermaßen auf ich könnte :kotz:

Solche Leute müsste man aufspüren können und von den Spiele-Servern verbannen oder sie müssen mit den Konsequenzen rechen. Geldstrafe im 4 Stelligen Bereich müsste man gegen diese Verursacher verhängen!

Also, würde ich so einen erwischen, ich glaube den würde ich den Hals umdrehen!

Das ist meine Meinung dazu.

Grüße an alle Forscher
„Myst will never forgotten“

filmschmiede's Tube Channel
Benutzeravatar
Ekk
Forscher
Beiträge: 60
Registriert: 27.01.2007, 15:43
Geschlecht: männlich
KI-Nummer: 1001420
Wohnort: Hamburg

#3 Re: Sicherheitslücken in MO:ULagain

Beitrag von Ekk » 08.05.2010, 12:44

Vollständige Zustimmung.

Und Mucol schönen Dank für deinen klaren Hinweis.

Ekk
iMac/3,06GHz24"IntelCore2Duo/MacOS 10.9.2
Benutzeravatar
D'n Alor
Forscher
Beiträge: 872
Registriert: 21.07.2007, 17:44
KI-Nummer: 519683
Wohnort: Nord-Ost Mittelfranken
Alter: 56

#4 Re: Sicherheitslücken in MO:ULagain

Beitrag von D'n Alor » 08.05.2010, 16:33

:evil: Wegen geltungssüchtigen Ar...lö..... mussten wir die halbe Woche auf MOUL verzichten. Ich könnte :motz: :flop:
Aber ich verstehe das Cyan das nicht durchgehen lassen kann, also die Lücken versucht zu stopfen und uns erstmal draussen lässt.
THX an Mucol.

P.S. Hab heute schon von Wori gehört warum die Server unten waren (Es soll sogar ein Video auf YouTube davon geben).
Hoffentlich wird es nicht so schlimm, wie es schon ist ! ~ Karl Valentin
KI 00519683
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 33

#5 Re: Sicherheitslücken in MO:ULagain

Beitrag von TheSearcher » 09.05.2010, 00:16

Was für Sicherheitslücken traten denn auf (falls es vertraulich/nicht für die Öffentlichkeit ist, ggf. auch per PN)?

Warum ich daran Interesse habe, liegt natürlich nicht daran, dass ich irgendetwas ausnutzen will (Gott bewahre). Sondern weil ich im Rahmen vom Informatik-Studium mich etwas in den Bereich IT-Sicherheit vertieft habe und daher (wie ich finde) ein berechtigtes Interesse daran besitze, zu erfahren, worin die Schwachstelle bestand. Denn nur dadurch kann ich auch daraus lernen und bei zukünftige Arbeitgeber/Kunden vielleicht ähnliche Fehler verhindern.

Nur, dass ihr nicht denkt, ich wäre hier auf primitiven Amateur-Niveau: ich bin auch schon bei einer sehr großen internationalen Internet-Firma (deren Namen ich jedoch aus Diskretionsgründen selbstverständlich nicht offenlege) auf eine vorher unbemerkte Schwachstelle gestoßen, die ich deren Security-Team gemeldet habe und die nach deren Aussage in absehbarer Zeit beseitigt werden soll.

Falls also jemand Näheres über die Details der Sicherheitslücken wisst, wäre ich daher sehr interessiert darüber zu erfahren.
Der Zyklustyp einer Permutation ist konjugationsinvariant.
Benutzeravatar
Al Bino
Forscher
Beiträge: 20
Registriert: 16.03.2010, 20:26
KI-Nummer: 3907300

#6 Re: Sicherheitslücken in MO:ULagain

Beitrag von Al Bino » 09.05.2010, 11:26

Es geht wohl um diesen Thread hier: http://mystonline.com/forums/viewtopic.php?t=21017
Just call me Al. Al Bino.
Benutzeravatar
Thoro
Forscher
Beiträge: 1494
Registriert: 23.09.2004, 14:43
Geschlecht: männlich
KI-Nummer: 529779
Wohnort: Duisburg
Alter: 36
Kontaktdaten:

#7 Re: Sicherheitslücken in MO:ULagain

Beitrag von Thoro » 09.05.2010, 14:05

Soweit ich das verstanden habe, bestand die Sicherheitslücke darin, dass jeder MOUL-Client, der sich erfolgreich am MOUL-Server angemeldet hatte, Vollzugriff auf die dahinterliegende Datenbank erhalten hat. Die gesamte Steuerung, wo was in die Datenbank geschrieben werden durfte, lag beim Client. Ein Team hat sich dann wohl durch Ausspionieren der Schlüssel für die Netzwerk-Verschlüsselung aus dem Original-Client und Mithören des Netzwerk-Verkehrs einen eigenen MOUL-Client gebastelt, mit dem sie nun beliebige Anweisungen auf der Datenbank ausführen konnten.

Das ganze ist hochgekocht, weil jemand, angeblich mit der Motivation die Uru-Geschichte fortzuführen, einen Avatar anlegte und in der Datenbank für diesen das Bahro-Erscheinungsbild setzte. So lief er dann als Bahro kurze Zeit durch die Stadt, was natürlich nicht unbemerkt blieb. Im Laufe der Foren-Diskussion gab Tahgtahv an, dass der "Bahro-Spieler" einen weiteren Avatar namens OMGHaxxor angelegt hätte, woraufhin jener sich erklären musste, wie er an diese Information gekommen sei. Es folgt eine endlose Diskussion über die Motivation der einzelnen Entwickler resp. Nutzer dieses Nachbau-MOUL-Clients. Fakt war aber, dass zumindest Teile des Programmcodes öffentlich verfügbar sind, womit auch böswillige Angriffe möglich wären.
Sarkasmus ... wie originell.
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 33

#8 Re: Sicherheitslücken in MO:ULagain

Beitrag von TheSearcher » 09.05.2010, 17:45

Danke für die Informationen, Thoro (und auch Al Bino für den Link).
Fakt war aber, dass zumindest Teile des Programmcodes öffentlich verfügbar sind, womit auch böswillige Angriffe möglich wären.
Also das ist nicht allzu schwer. Alles Standard-Techniken, wie man sie auch zur Analyse von Schadsoftware einsetzt.
Ich könnte sogar erklären, wie man aus der UruExplorer.exe einen möglichen Quellcode rekonstruieren kann (mache ich aber nicht!). Es gibt sogar ein paar Tricks, die man nutzen kann, um speziell den Teil für das Netzwerk-Protokoll sehr schnell zu finden (was für den gewählten Angriff schon ausreicht).

Die Lösung, die ich persönlich an Cyans Stelle umsetzen würde, wäre eine serverseitige Umsetzung des Clark-Wilson Modells (keine Details dazu - interessiert sowieso niemanden ;) ). Problem: das bekommt man eher nicht in ein paar Tagen hin.

Aber auch abgesehen davon: Security ist ein sogenannter "Cross Concern" in der Software. Das heißt: wenn man eine sichere Software entwickeln will, muss man die Sicherheit auf allen Ebenen berücksichtigen. Insbesondere ist es nicht möglich, eine Software, bei deren Entwicklung Sicherheitsaspekte ignoriert wurden, durch Zukauf oder Hinbasteln irgendeiner Sicherheitskomponente sicher zu bekommen (auch wenn sich einige Firmen dumm und dämlich an dem Verkauf derartiger Lösungen verdienen - ich schreibe jedoch nichts weiteres dazu).

Daher: ich persönlich würde stark annehmen, dass Cyan das Problem nicht wirklich gefixt hat (das bekommt man nach meiner Ansicht nie und nimmer in so kurzer Zeit hin, wenn die von Thoro beschriebene Ursache stimmt - oder anders ausgedrückt: den Programmierer, der dies in so kurzer Zeit schafft, würde ich einstellen ;) ), sondern lediglich eben schnell etwas zusammengebastelt hat, was die konkrete Durchführung des gewählten Angriffs minimal erschwert. Glaubt aber ja nicht, dass Angreifer mit dem nötigen Willen nicht schnell ein neues Loch findet.

Es wäre also in meinen Augen daher wohl sinnvoller gewesen MOUL ein paar Tage länger offline zu lassen und das Problem ernsthaft zu lösen.
Der Zyklustyp einer Permutation ist konjugationsinvariant.
diafero
Forscher
Beiträge: 150
Registriert: 01.04.2007, 10:56

#9 Re: Sicherheitslücken in MO:ULagain

Beitrag von diafero » 17.05.2010, 20:04

Daher: ich persönlich würde stark annehmen, dass Cyan das Problem nicht wirklich gefixt hat (das bekommt man nach meiner Ansicht nie und nimmer in so kurzer Zeit hin, wenn die von Thoro beschriebene Ursache stimmt - oder anders ausgedrückt: den Programmierer, der dies in so kurzer Zeit schafft, würde ich einstellen ;) ), sondern lediglich eben schnell etwas zusammengebastelt hat, was die konkrete Durchführung des gewählten Angriffs minimal erschwert. Glaubt aber ja nicht, dass Angreifer mit dem nötigen Willen nicht schnell ein neues Loch findet.
Stimmt genau. Es wurden wohl lediglich ein paar Verschlüsselungs-Parameter geändert und die Keys getauscht. Die Details der "Lücke" zu erfahren wird dir schwerfallen, Searcher, 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.

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 ;-) . Mein Kriterium für ein "sicheres" Uru wäre, dass es niemandem gelingt, den Server oder andere Clients zum Crashen zu bringen und/oder fremden Code auszuführen... zumindest in UU war dies bei Weitem nicht gegeben. In Alcugs tue ich mein Bestes, um das zumindest für den Server sicherzustellen. MOUL kann ich in dieser Hinsicht nicht kommentieren.
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. Diese Leute haben zum Beispiel den Stadt-Imager-Hack korrigiert (also wieder den alten Text draufgesetzt). Vielleicht ist einer von euch über die Bilder von Fan-Welten gestoßen, die sie importiert haben.
Warum ich das erzähle? Ich will nur klar machen, dass viele der Uru-Hacker oder wie man sie nennen mag mit ihrem Wissen durchaus nützlichen anfangen. Leider hat die weitere Verbreitung von MOUL, jetzt, da es kostenlos ist, auch schwarze Schafe angelockt (sprich, das geschah unter GameTaps Regie vor allem aus dem Grund nicht, dass es niemand versucht hat). Es ist i.A. nicht möglich, diese Personen zu ermitteln. Zudem erinnern obige Forderungen leider stark an ChrisGer, der inzwischen für seine Äußerung bekannt ist, man möge doch alle Uru-Hacker "zum Wohle aller" rausschmeißen auf dass wir ein besseres und saubereres Uru haben...

Um Missverständnissen vorzubeugen: Ich unterstütze natürlich Aktionen wie die Sache mit den Bahro nicht. Ich unterstütze allerdings das Hacken (oder "Analysieren", wenn euch der Begriff besser gefällt) von Uru. Unter anderem wird dieses Wissen nötig sein, wenn und falls wir jemals den Quelltext in die Hände bekommen. Vielleicht hätten einige findige Programmierer ja die Mittel, eine Art Schutzschicht in den Server einzubauen, der solche Angriffe verhindert - wenn Cyan uns aber weiterhin nur hinhält, kann natürlich nichts dergleichen geschehen. Searcher wird einwenden, dass ein "Schutzschild" keine Lösung ist, und er hat recht - aber es ist besser als garnichts.
Ich werde PNs in diesem Forum vermutlich nicht bemerken. Du kannst mich via E-Mail erreichen: "diafero arcor de" (mit At und Punkt an der richtigen Stelle).
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 33

#10 Re: Sicherheitslücken in MO:ULagain

Beitrag von TheSearcher » 18.05.2010, 02:04

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.
Der Zyklustyp einer Permutation ist konjugationsinvariant.
Benutzeravatar
Stefan
Forscher
Beiträge: 2421
Registriert: 05.02.2004, 19:25
KI-Nummer: 192377

#11 Re: Sicherheitslücken in MO:ULagain

Beitrag von Stefan » 18.05.2010, 17:52

Kann man sowas nicht per PM diskutieren :P
Okay, im Gegensatz zu mir, war der beitrag wenigstens Ontopic... auch wenn mich Definitionen von definitionen nicht sonderlich beeindrucken...

:echtwahr:
Stefan
diafero
Forscher
Beiträge: 150
Registriert: 01.04.2007, 10:56

#12 Re: Sicherheitslücken in MO:ULagain

Beitrag von diafero » 18.05.2010, 19:30

Klar kann man sowas auch per PM regeln, allerdings ist es durchaus "On-topic", wie du ja selbst gesagt hast. Und solange es beim Austausch von Argumenten, Fakten und Meinungen bleibt, warum nicht?

Ich habe zwar keine formale Definition von Sicherheit parat, aber intuitiv ist wohl jedem, der mit Computer-Systemen und unbekannten User-Eingaben, insbesondere in Mehrbenutzer-Systemen, zu tun hat, klar, worum es grundsätzlich geht. Meine saloppe "Um-Definition" oben war ein Tribut an die Tatsache, was in Uru realistisch ist. Es rollt mir ja selbst die Zehnnägel hoch, solche niedrigen Kriterien zu formulieren.
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.
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.
Dem stimme ich voll zu.
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.
Ich habe keinen Zugriff auf den Server-Code von MOUL. Aber ich habe den Alcugs-Server für POTS neu geschrieben und kenne das alte Netzwerkprotokoll auswändig. UU nutzt dasselbe Protokoll, und MOUL ein relativ ähnliches (es wurde eine komplexe Protokollschicht entfernt und durch eine andere komplexe ersetzt, und manche Nachrichten gehen nun etwas andere Wege - aber das grundlegende Design hat sich kaum geändert). Du wirst mir hoffentlich zustimmen, dass die genaue Kenntnis des Protokolls mit ein wenig Erfahrung schnell Rückschlüsse auf mögliche Sicherheitsprobleme zulässt und/oder man schnell erkennt, wo man genau aufpassen und kontrollieren muss.
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.
Okay, bleiben wir bei der Sicherheit des Vaults (also des persistenten Datenspeichers von Uru): Es wird nicht direkt mit SQL-Strings gearbeitet, sondern eine Ebene höher auf einer Baumstruktur. Das Protokoll stellt quasi sicher, dass die Baumstruktur gültig bleibt - nicht mehr und nicht weniger (zumindest tut es das in Alcugs, ich hoffe, Cyan hat diese recht einfachen Kontrollen auch drin...). Insbesondere wird nicht geprüft, ob die Baumstruktur im Kontext von Uru Sinn macht, oder ob man gewisse Bereiche der Baumstruktur vielleicht doch besser nicht ändern können sollte. Aber deine Erklärungen lassen sich natürlich analog auf diese Ebene übertragen. Und du hast recht, das Vault könnte man m.E. relativ schnell deutlich sicherer machen. Es gab in UU sogar Ansätze eines Sicherheitssystems, bei dem die Knoten des Baumes Eigentümer, Gruppe und Berechtigungen analog zu den Unix-Berechtigungen bekamen. Implementiert wurde das nie und in MOUL sogar aus dem Protokoll entfernt. 4-5 Wochen bei ein oder zwei Vollzeitprogrammierern inklusive Testen halte ich für realistisch, um dies umzusetzen. In dieser Zeit könnte man es auch hinbekommen, zu programmieren, dass jeder der Knoten ein gültiger Knoten seines Typs ist, was schon einen großen Teil des "Sinnvoll für Uru" sicherstellen würde (auch wenn das leider viel von der Eleganz des Ansatzes nehmen würde). Ich würde für die Portierung des gigantischen vorhandenen Vaults aber noch mindestens eine Woche draufzählen. Und Cyan hat keinen Vollzeitprogrammierer, der sich nur um MOUL kümmern kann....
Und natürlich könnte man manuell einbauen, dass der String, der den Typ eines Avatars im Avatar-Knoten speichert, nicht ohne weiteres geändert werden kann. Alle derartigen Sonderfälle abzufangen halte ich jedoch nicht für realistisch. Der Vault-Server weiß nicht, was die Daten in seinen Knoten bedeuten, er speichert sie nur für den Client. Ihm das en Detail beizubringen und vor allem, ihn die Gültigkeit der Werte kontrollieren zu lassen, wäre enormer Aufwand. Dieses Beispiel ist ja noch "relativ" simpel, aber zum Beispiel der Knoten, der in einem String speichert, welche Weltentücher man in Kirel angeklickt hat - es handelt sich dabei um ein allgemeines Variablen-System, das die Engine zur Verfügung stellt und erst vom Python-Code mit Sinn gefüllt wird. Den Vault-Server ständig auf dem Laufenden zu halten, welche Variablen es geben darf und welche Wert sie annehmen dürfen, würde schlicht und einfach das gesamte Konzept zerstören, man könnte die Variablen gleich abschaffen und durch fest in der Engine einprogrammierte Werte ersetzen. Und selbst wenn das der Fall wäre, könnte das Vault unmöglich wissen, ob du wirklich auf das Weltentuch geklickt hast, von dem du gerade dem Vault gesagt hast, dass es eingesammelt wurde.

Diese Idee des dummen Servers, der dem Client Dienste anbietet, die erst von diesem mit Sinn gefüllt werden, ist zwar elegant und macht mir die Arbeit an Alcugs leichter - es ist aber natürlich extrem unsicher, eben weil der Server keinen Schimmer hat, was der Client tut. Und Uru ist komplett so aufgebaut. Daher bringt "Client-Sicherheit" leider garnichts, ist aber so ziemlich das einzige, was wir haben. Das sieht man deutlich an Maßnahmen wie dem Neu-Download aller Python- und SDL-Dateien, der mit MOUL eingeführt wurde. Und daher sagte ich auch, dass man Uru neu schreiben müsste, um es sicher zu machen. Und bisher habe ich ja nur vom Vault gesprochen...
Ich werde PNs in diesem Forum vermutlich nicht bemerken. Du kannst mich via E-Mail erreichen: "diafero arcor de" (mit At und Punkt an der richtigen Stelle).
Benutzeravatar
TheSearcher
Forscher
Beiträge: 753
Registriert: 10.10.2004, 13:21
Wohnort: Magdeburg
Alter: 33

#13 Re: Sicherheitslücken in MO:ULagain

Beitrag von TheSearcher » 18.05.2010, 22:38

diafero hat geschrieben:
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.
Okay, bleiben wir bei der Sicherheit des Vaults (also des persistenten Datenspeichers von Uru): Es wird nicht direkt mit SQL-Strings gearbeitet, sondern eine Ebene höher auf einer Baumstruktur. Das Protokoll stellt quasi sicher, dass die Baumstruktur gültig bleibt - nicht mehr und nicht weniger (zumindest tut es das in Alcugs, ich hoffe, Cyan hat diese recht einfachen Kontrollen auch drin...). Insbesondere wird nicht geprüft, ob die Baumstruktur im Kontext von Uru Sinn macht, oder ob man gewisse Bereiche der Baumstruktur vielleicht doch besser nicht ändern können sollte. Aber deine Erklärungen lassen sich natürlich analog auf diese Ebene übertragen. Und du hast recht, das Vault könnte man m.E. relativ schnell deutlich sicherer machen. Es gab in UU sogar Ansätze eines Sicherheitssystems, bei dem die Knoten des Baumes Eigentümer, Gruppe und Berechtigungen analog zu den Unix-Berechtigungen bekamen. Implementiert wurde das nie und in MOUL sogar aus dem Protokoll entfernt. 4-5 Wochen bei ein oder zwei Vollzeitprogrammierern inklusive Testen halte ich für realistisch, um dies umzusetzen. In dieser Zeit könnte man es auch hinbekommen, zu programmieren, dass jeder der Knoten ein gültiger Knoten seines Typs ist, was schon einen großen Teil des "Sinnvoll für Uru" sicherstellen würde (auch wenn das leider viel von der Eleganz des Ansatzes nehmen würde).
Danke für die Erklärung.
Ich würde für die Portierung des gigantischen vorhandenen Vaults aber noch mindestens eine Woche draufzählen. Und Cyan hat keinen Vollzeitprogrammierer, der sich nur um MOUL kümmern kann....
Mit dem richtigen SQL-Befehl geht das Portieren recht schnell.
Und natürlich könnte man manuell einbauen, dass der String, der den Typ eines Avatars im Avatar-Knoten speichert, nicht ohne weiteres geändert werden kann. Alle derartigen Sonderfälle abzufangen halte ich jedoch nicht für realistisch. Der Vault-Server weiß nicht, was die Daten in seinen Knoten bedeuten, er speichert sie nur für den Client. Ihm das en Detail beizubringen und vor allem, ihn die Gültigkeit der Werte kontrollieren zu lassen, wäre enormer Aufwand. Dieses Beispiel ist ja noch "relativ" simpel, aber zum Beispiel der Knoten, der in einem String speichert, welche Weltentücher man in Kirel angeklickt hat - es handelt sich dabei um ein allgemeines Variablen-System, das die Engine zur Verfügung stellt und erst vom Python-Code mit Sinn gefüllt wird. Den Vault-Server ständig auf dem Laufenden zu halten, welche Variablen es geben darf und welche Wert sie annehmen dürfen, würde schlicht und einfach das gesamte Konzept zerstören, man könnte die Variablen gleich abschaffen und durch fest in der Engine einprogrammierte Werte ersetzen. Und selbst wenn das der Fall wäre, könnte das Vault unmöglich wissen, ob du wirklich auf das Weltentuch geklickt hast, von dem du gerade dem Vault gesagt hast, dass es eingesammelt wurde.

Diese Idee des dummen Servers, der dem Client Dienste anbietet, die erst von diesem mit Sinn gefüllt werden, ist zwar elegant und macht mir die Arbeit an Alcugs leichter - es ist aber natürlich extrem unsicher, eben weil der Server keinen Schimmer hat, was der Client tut. Und Uru ist komplett so aufgebaut. Daher bringt "Client-Sicherheit" leider garnichts, ist aber so ziemlich das einzige, was wir haben. Das sieht man deutlich an Maßnahmen wie dem Neu-Download aller Python- und SDL-Dateien, der mit MOUL eingeführt wurde. Und daher sagte ich auch, dass man Uru neu schreiben müsste, um es sicher zu machen. Und bisher habe ich ja nur vom Vault gesprochen...
Da muss ich dir wohl zustimmen, dass ein derartiges System auf den ersten Blick recht ekelhaft in Sachen Implementierung von Integritätssicherung aussieht. Auf der anderen Seite: um die Programmierung der Engine flexibel zu halten und schnell neue Daten hinzuzufügen, sollte man die Struktur besser recht flexibel halten. Das ist ein Abwägen von Sicherheit vs Flexibilität.

Aber ich sehe da durchaus eine Möglichkeit, wie man das Problem mit nur kleinen Protokolländerungen lösen könnte (auch wenn ich eine Wette eingehen würde, dass Cyan das sicherlich nicht so implementiert hat).

WARNUNG: ab jetzt wird es etwas akademisch

Dazu müssen wir ein wenig in die theoretische Informatik begeben.

Ein Entscheidungsproblem ist ein Problem, auf welches die Antwort ja oder nein lautet (stark vereinfacht).

Beispiel: für ein gegebenes natürliches n ist "Ist n Primzahl?" ein Entscheidungsproblem.

Für Uru ist das Entscheidungsproblem natürlich: "Darf Nutzer die Aktion ausführen?".

Nun möchte ich (bzw. der Uru-Client) gerne den Server davon überzeugen, dass er tatsächlich legitimiert ist, die entsprechende Aktion auszuführen (also den Server davon überzeugen, dass die Antwort auf das Entscheidungsproblem "ja" ist). Wie macht er das? Die Antwort ist: er sendet ein (polynomielles) Zertifikat an den Server, mit Hilfe dessen der Server nachprüfen kann, dass die Antwort tatsächlich "ja" ist.

Man beachte, dass dies *nicht* identisch damit ist, dass der Server tatsächlich den Python-Code, den der Client ausführt, nochmals ausführt.

Beispiel:

Player X darf Aktion Bla ausführen, wenn A oder B oder C oder D erfüllt ist.

Wenn A, B, C falsch sind (und der Client das ausgerechnet hat), dann muss der Client auch D auswerten, um (als Beweiser, dass er legitimiert ist, die Aktion auszuführen) sicherzugehen, dass er die Erlaubnis, Bla auszuführen, gegenüber dem Server beweisen kann.

Umgekehrt reicht es jedoch, um dem Server zu belegen, dass Player X Bla ausführen darf, ihm ein Zertifikat zu senden, dass D wahr ist - das ist bedeutend weniger Rechenaufwand für den Server.

Somit sendet der Client statt

AktionY

nun im Protokoll

AktionY|Zertifikat(AktionY für ihn erlaubt)

Der Server kann anhand des Zertifikats verifizieren, dass der Client tatsächlich berechtigt ist, die Aktion auszuführen.

Man müsste in der Tat das Protokoll minimal überarbeiten - aber funktionieren würde es (das Problem bei der praktischen Implementierung liegt mehr darin, dass heutige Entwicklungstools nicht auf diese Art von Aufgaben ausgelegt sind).

P. S.: Ich bin bewusst - um den Beitrag verständlich zu halten - nicht darauf eingegangen, wie für allgemeine Computerprogramme derartige Zertifikate aussehen. Dieses Problem ist jedoch seit langem gelöst (Stichwort für alle Insider: der Lehrbuch-Beweis dass SAT ein NP-vollständiges Problem darstellt und es somit insbesondere NP-vollständige Probleme gibt).
Der Zyklustyp einer Permutation ist konjugationsinvariant.
diafero
Forscher
Beiträge: 150
Registriert: 01.04.2007, 10:56

#14 Re: Sicherheitslücken in MO:ULagain

Beitrag von diafero » 20.05.2010, 11:23

Mit dem richtigen SQL-Befehl geht das Portieren recht schnell.
Die Berechtigungen könnte man ganz gut abhängig vom Typ setzen, aber kein SQL-Befehl kann den korrekten Eigentümer eines Knotens ermitteln. Selbst mit einem Programm wäre das schwierig. So müssten zum Beispiel alle direkten und indirekten Kindknoten eines Spieler-Haupt-Knotens diesem Spieler gehören, es sei denn, es handelt sich um Info-Knoten anderer Spieler oder den System-Knoten und seiner Unter-Knoten oder um KI-Photos, die ein anderer erstellt hat, oder um die Knoten einer Welt. Bei letzteren sollten der Eigentümer wohl die ID desjenigen sein, dem die Instanz gehört, es sei denn, es handelt sich um eine global- oder Nachbarschafts-instantiierte Welt. Da nicht klar ist, über viel viele Zwischen-Knoten so eine Eltern-Kind-Beziehung geht, dürfte das selbst mit monströsen Tabellenübergreifenden Abfrage schwierig sein (es gibt eine Tabelle, die jeder Knoten-ID den Inhalt zuordnet, und eine weitere, die Verknüpfungen zwischen Knoten speichert, also im Prinzip Eltern-Kind-Paare).


Diese Zertifikat-Sache mag zwar minimale Änderungen am Protokoll bedeuten, aber es bedeutet dennoch, dass der Server wissen muss, wie gültige Spiel-Sitationen aussehen. Dazu muss er überhaupt erstmal wissen, wie die Spielsituation aussieht - das Vault hat keine Ahnung, in welcher Welt sich der Spieler momentan befindet, während die aktuelle Welt nicht weiß, was der Spieler mit dem Vault verhandelt (in MOUL sind das sogar zwei verschiedenen TCP-Verbindungen). Noch schlimmer, selbst der aktuelle Spiel-Server weiß bei Urus allgemeiner Struktur nicht, wo sich der Spieler in der Welt befindet, da diese Information in einer SDL-Struktur steht, was wiederum ein vollständig vom Client kontrolliertes System ist. Und zumindest in UU/TPOTS weiß der Server nicht im geringsten, wie die Welt aussieht - seine ganze Information besteht darin, dass die Welt sequence prefix XYZ hat, und dass sie aus diesen und jeden Seiten ("Pages", die prp-Dateien) mit den Page-Nummern A, B und C besteht. Der Server weiß nicht nur nicht, ob der Spieler das Objekt, das er gerade angeklickt hat, überhaupt hätte anklicken können oder ob er am anderern Ende der Welt steht - er weiß nichtmal, ob es dieses Objekt überhaupt gibt. Er weiß nicht, ob der Spieler gerade im Flymode durch Wände geht, weil er nicht weiß, wo überhaupt Wände sind. Und er weiß auch nicht, ob der Wert, den der Python-Code gerade in eine SDL-Variable oder einen Vault-Knoten gespeichert hat, Sinn macht oder nicht. Selbst wenn nur die minimale Information, die der Client übermitteln muss, um zu belegen, dass er tun darf was er tun will, vom Server überprüft werden soll - selbst dann müsste der Server erheblich mehr über das Spiel an sich wissen als im Moment, und zwar so erheblich viel mehr, dass es jeden einzelnen Teil des Servers betrifft. Sprich, das Protokoll muss nur um diese Zertifikate erweitert werden, der Server jedoch um alles, was nötig ist, diese zu verifizieren. Dann könnte man gleich die entscheidenden Berechnungen in den Server verlegen und so das System sicher machen.

Momentan ist das System so flexibel, dass man das komplette Spiel im Client austauschen könnte, alle Dateien weg und neue rein, andere Avatar-Typen, andere GUI, wasweißich - der Server bekommt die neuen age- und SDL-Dateien und muss nichtmal neu gestartet werden. Okay, in der Praxis müsste man noch das Vault leeren, Cyans Server braucht wohl doch einen Neustart und vermutlich gibt es an einzelnen Stellen kleine Sonderbehandlungen, aber das sind hässliche Work-Arounds. Der bzw. die Server wissen nichts, aber auch garnichts über die Inhalte dessen, was sie hosten. Im Prinzip tut er nur dies:
- Er speichert Knoten und Verknüpfungen in einer Baumstruktur und liefert sie auf Anfrage wieder aus. Außerdem sorgt er dafür, dass der Client die ihn interessierenden Teile des Vaults (d.h. einen oder mehrere Unterbäume) mit dem Server synchron halten kann, indem er über Updates benachrichtigt wird.
- Er leitet Plasma-Nachrichten an alle Clients der Welt oder eine festgelegte Liste Empfänger, die sich auch in anderen Welten befinden können, weiter (er könnte den Inhalt der Nachrichten auf Wohlgeformtheit überprüfen, aber nicht auf Sinnhaftigkeit). Diese Nachrichten können KI-Nachrichten enthalten, oder die Mitteilung, dass ein Avatar jetzt die Links-Dreh-Animation angefangen hat, oder ein Hinweis, dass eine Lampe gerade ausgeschaltet wurde.
- Er verwaltet für jede Welt einen Satz Status-Beschreibungen, deren Struktur in SDL-Dateien beschrieben wird und bei denen er wieder keinerlei Sinnhaftigkeit überprüfen kann. Diese Strukturen können sich zum Beispiel auf die Welt an sich beziehen ("Relto-Tür offen"), einen Avatar oder herumtretbaren Gegenstand ("Koordinaten X, Y, Z") oder eine Animation ("Animations-Position 0.38") - nichts davon steht fest im Server drin, er hat nur SDL-Dateien, die ihm sagen, was eine "Animation", ein "Physical" oder einen "Avatar" ausmacht, und speichert das für den Client und reicht es an neu hinzukommende Clients weiter. Schau doch mal in die SDL-Dateien von POTS (in MOUL sind es noch fast dieselben): Wenn nötig, werden selbst die Zustände von intern verwaltete Objekten wie Avataren oder Animationen einfach durch editieren einer Textdatei erweitert. Nur der Client muss wissen, was das alles soll, der Server speichert einfach nur eine Folge von INT, BYTE und BOOL-Werten und rückt sie auf Anfrage wieder raus. Die Namen haben nur den Sinn, dass der Client gut drauf zugreifen kann, und dass der Server bei einer Änderung der Struktur alte und neue Variablen einander zuordnen kann.

Dieses System hat seinen Charme, und man kann einen kompletten Server in 10k-15k Zeilen Code schreiben (wobei SDL hässlich ist, und die Interaktion von SDL und Vault ebenfalls, aber das sind Protokoll-Details). Aber es abzusichern geht m.E. nur, indem eben dieser Charme entfernt wird, weil der Server dafür Verifikation in irgendeiner Form druchführen muss, wofür er nicht nur über die Struktur, sondern auch die Inhalte der Daten, die er hostet, genauere Informationen benötigt.
Ich werde PNs in diesem Forum vermutlich nicht bemerken. Du kannst mich via E-Mail erreichen: "diafero arcor de" (mit At und Punkt an der richtigen Stelle).
Antworten