Seite 3 von 53 ErsteErste 123456713 ... LetzteLetzte
Ergebnis 31 bis 45 von 784

Thema: Mod für PB-Spiele: PB Mod_v1

  1. #31
    Say My Name Avatar von Zulan
    Registriert seit
    13.03.08
    Beiträge
    8.901
    Ich habe es heute geschafft einen wild gewordenen Uploader zu stoppen

    Das zu erkennen sollte nicht so schwer sein - wenn ueber eine gewisse Zeit ueber eine IP/Port/IP/Port Kombination nur Daten in eine Richtung gehen ist es wohl kaputt. Von sinnvoll konfigurierten hosts kommen da auch ICMP Port unreachable Packete zurueck (sowohl port unreachable wenn niemand listened, als auch host unreachable vom router wenn er weiss das hinter der IP gerade niemand ist).

    Vielleicht kann man das im Pitboss per Mod auch irgendwie rausfinden?

    Die letzten 2 Packete einer erfolgreich beendeten PB verbindung sehen immer aehnlich aus:

    Code:
    client <-> server
    
    <007affff
    >007a00de
    <007bffff
    >007b00df
    >007c00df
     08b108c4
     
    -> fefe06007c00df
    <- fefe68
    
    -> fefe0600330075
    <- fefe68
    
    -> fefe060030006f
    <- fefe68
    
    -> fefe06004f008f
    <- fefe68
    
    -> fefe0600380087
    <- fefe68
    
    -> fefe060005002d
    <- fefe68
    fefe ist da immer wohl als magic bytes davor.
    06 ist wohl das schliessen der Verbindung.
    Der Blau markierte Teil ist, anhand der vorangegangenenen Pakete zu erkenen wohl, so eine art Sequenznummer die zwischen server und client annaehernd synchron bleibt. Die ist auch groesser je laenger die Verbindung laeuft.
    Ich weiss noch nicht was der letzte Teil macht.

    Ich habe dann einfach mal den client hart gekillt, die UDP-Flut beobachtet und vom client aus ein Fake-Paket geschickt:

    Code:
    import socket
    import pprint
    pp = pprint.PrettyPrinter(indent=4)
    
    R = '192.168.122.17'
    L = '192.168.122.1'
    P = 2056
    
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.bind((L,P))
    s.connect((R,P))
    
    pack = bytearray()
    pack.append(0xfe)
    pack.append(0xfe)
    pack.append(0x06)
    pack.append(0x08) # dafuer habe ich anhand wireshark eine nummer gewaehlt die der server, waehrend der Flut-Zeit schonmal hatte
    pack.append(0xc4) # ...
    pack.append(0x00) # 00 scheint gut zu sein?
    pack.append(0xad) # wahllos geraten
    r = s.send(pack)
    
    print("Sent {} bytes".format(r))
    
    x = s.recv(3)
    pp.pprint(x)
    Und die UDP flut war beendet . In real muesste wohl die Absenderadresse / port gefaelscht werden.

    Da fehlt natuerlich noch einiges, und es muss ausgiebig getestet werden ob das stabil laeuft. Aber prinzipiell ist es wohl moeglich. Als Notfall-Fallback koennen wir ja nun auch den PB neu starten.

  2. #32
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896
    Sehr cool, dass du das analysiert hast
    Über den Einbau einer solchen Lösung hatte ich mir schon ein paar Gedanken gemacht. Ich würde versuchen es in den Pyton-Teil des PB-Servers zu integrieren. An dieser Stelle kann sehr leicht festgestellt werden welche User eingeloggt sind. Wenn man dann noch eine Liste erstellt, die die letzte IP eines eingeloggten Spielers beinhaltet, sollte man periodisch (oder beim Registrieren von Logouts) Fake-Pakete von nicht eingeloggten Usern versenden können.
    Wir müssten nur noch rausfinden, ob das Fälschen des Absenders leicht ist, was ich fast vermute.

  3. #33
    Say My Name Avatar von Zulan
    Registriert seit
    13.03.08
    Beiträge
    8.901
    Uebrigens konnte ich gestern das Uploader Problem nur durch einen harten kill von Civ (kill -9) reproduzieren. Selbst bei alt+f4 wird die Verbindung ordnungsgemaess beendet. So etwas aehnliches hat Redarg vor 6 Jahren auch schonmal rausgefunden.

    http://forums.civfanatics.com/showth...79#post6817179

    Wenn das mit dem "immer zurueck zum Menue!!!" nicht mal das hartnaeckigste langlebigste falsche Geruecht aller Civ-Zeiten ist.

  4. #34
    Registrierter Benutzer Avatar von alpha civ
    Registriert seit
    22.07.06
    Beiträge
    16.757
    Weil ich das hier gerade sehe:

    Code:
    altrootDir + "\\pbSettings.json"
    Verwende lieber os.path.join, dann brauchst du dir über die Pfadtrennzeichen keine Gedanken mehr machen, das regelt Python automatisch.

    Also dann so schreiben:
    Code:
    os.path.join(altrootDir, "pbSettings.json")

  5. #35
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896
    Zitat Zitat von alpha civ Beitrag anzeigen
    Weil ich das hier gerade sehe:
    [...]
    Den Hinweis hast du mir, glaube ich, schon mal gegeben
    Mal sehen, ob ichs mir diesmal merken kann.

    Ich muss jetzt noch eine „Registieren“-Funktion in die Weboberfläche einbauen und dann kann ich eine neue Version hochladen. Wahrscheinlich über Github.
    Dann kann ich mich dem Fix für das Upload-Problem zuwenden.


    Weboberfläche sieht jetzt so aus:
    Bild
    Angehängte Grafiken Angehängte Grafiken

  6. #36
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896
    Auf meinem Rechner verursacht der PB-Server 15% Last ohne dass jmd. eingeloggt ist. Was meint ihr: Könnte dass auch durch dumme Redraw-Algorithmen der Python-Oberfläche des PB-Fensters passieren?! Dann könnten wir die Last wahrscheinlich stark senken

  7. #37
    Say My Name Avatar von Zulan
    Registriert seit
    13.03.08
    Beiträge
    8.901
    Zitat Zitat von Ramkhamhaeng Beitrag anzeigen
    Auf meinem Rechner verursacht der PB-Server 15% Last ohne dass jmd. eingeloggt ist. Was meint ihr: Könnte dass auch durch dumme Redraw-Algorithmen der Python-Oberfläche des PB-Fensters passieren?! Dann könnten wir die Last wahrscheinlich stark senken
    Also bei mir unter linux/wine sinds 2% (eines cores, 18 unclaimed Spieler). In der windows VM siehts aehnlich aus. Drum kann ich schlecht feststellen woran es liegt.

  8. #38
    Registrierter Benutzer Avatar von alpha civ
    Registriert seit
    22.07.06
    Beiträge
    16.757
    Zitat Zitat von Ramkhamhaeng Beitrag anzeigen
    Den Hinweis hast du mir, glaube ich, schon mal gegeben
    Mal sehen, ob ichs mir diesmal merken kann.
    Daran kann ich mich schon gar nicht mehr erinnern.

    Zur Oberfläche: Kannst du den Timer irgendwie mehr hervorheben? An der jetzigen Stelle geht er leicht unter.

  9. #39
    Jesper Portus
    Gast
    @all:

  10. #40
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896
    UffEmoticon: peitsche, ich habs jetzt auf Github-Seite veröffentlicht. Ich hoffe die Installationsanleitung ist ausführlich genug. Weiter verkürzt kriege ich nicht.

    Den DLL-Quellcode werde ich nachreichen, wenn ich mal wieder an dem Win-PC dafür bin. Diese Version enthält auch den Patch, der den Hänger im PB-Fenster (Gamespy-Abschaltung) beseitigt.
    Die Client-Seite hab ich mir noch nicht angeschaut.

  11. #41
    Jesper Portus
    Gast
    So als Laie: Ich konnte den MOD runterladen, installieren und starten. Nur einem Spiel konnte ich nicht beitreten, weil mir kein Testspiel und Server bekannt ist.

  12. #42
    Say My Name Avatar von Zulan
    Registriert seit
    13.03.08
    Beiträge
    8.901
    Zitat Zitat von Ramkhamhaeng Beitrag anzeigen
    UffEmoticon: peitsche, ich habs jetzt auf Github-Seite veröffentlicht. Ich hoffe die Installationsanleitung ist ausführlich genug. Weiter verkürzt kriege ich nicht.

    Den DLL-Quellcode werde ich nachreichen, wenn ich mal wieder an dem Win-PC dafür bin. Diese Version enthält auch den Patch, der den Hänger im PB-Fenster (Gamespy-Abschaltung) beseitigt.
    Die Client-Seite hab ich mir noch nicht angeschaut.
    Github
    Yggdrasil
    Gamespy raus
    PHP Code:

    Sowas:

    Code:
    <?php
    include_once($subdir.'contentmanager/dbClass.php');
    Kann sehr gefaehrlich sein. Unter bestimmten Konfigurationen (register_globals / open_basedir) kann man da mit einem Aufruf von http://goodguy.example.com/contentma...com/shell.phps viel Unheil anrichten.

    Ausserdem hast du beispielsweise hier

    Code:
    echo "Login failed. <a href='".$_SERVER["SCRIPT_NAME"].
    (array_key_exists("from",$_GET)?"?from=".$_GET["from"]:"") .
    "'>Retry</a>";
    eine cross site scripting vunlnerability.

    Es ist leider sehr einfach sich in PHP in den Fuss zu schiessen und dann an einer Blutvergiftung zu sterben.
    • Niemals user inupt vertrauen bzw. ungefiltert fuer irgendwas uebernehmen
    • So wie ich das sehe hast sehr viele Abhaengigkeiten kreuz und quer zwischen den verschiedenen Komponenten bzw zwischen globalem Zustand. Das macht Aenderungen und fixes sehr schwierig weil man nicht weiss was von wem abhaengt.
    • Du erfindeset ziemlich viele Raeder neu: templates, localization, db abstraction


    Soviel erstmal ne knappe Analyse

  13. #43
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896
    Ja, PHP ist Teufelswerk :-( Aber da ich den Webkram eh nicht so leiden kann habe mich da noch nicht
    mit Alternativen beschäftigt.
    Aber mit dem Code liegen ja alle Schnittstellen zum Pitboss-Server offen. Alle Methoden, die mit dem PB-Server kommunizieren sind in php/pbModFunctions.php und php/helper.php zu finden. Wer also den PHP-Unterbau durch eine bessere Lösung ersetzen will möge hervortreten

    Zitat Zitat von Zulan Beitrag anzeigen
    Code:
    <?php
    include_once($subdir.'contentmanager/dbClass.php');
    Kann sehr gefaehrlich sein. Unter bestimmten Konfigurationen (register_globals / open_basedir) kann man da mit einem Aufruf von http://goodguy.example.com/contentma...com/shell.phps viel Unheil anrichten.
    Die Problematik ist mir bekannt, aber zumindest register_globals hat doch niemand mehr aktiviert.
    Wenn der Angreifer beliebige Variablen definieren kann sind include-Befehle sicher das einfachste Einfallstor aber auch sehr viele andere Sachen möglich. Eigentlich ist dann kein Code der Welt zu retten.

    Ausserdem hast du beispielsweise hier

    Code:
    echo "Login failed. <a href='".$_SERVER["SCRIPT_NAME"].
    (array_key_exists("from",$_GET)?"?from=".$_GET["from"]:"") .
    "'>Retry</a>";
    eine cross site scripting vunlnerability.
    Da hast du Recht. Hab gleich mal geguckt und noch drei Aufrufe mit ungefiltertem GET-Aufruf gefunden.
    Ich gucke auch noch mal die (wenigen!) $_SERVER["REQUEST_URI"]; durch… Andererseits… in Hinblick auf den Einsatzzweck der Seite spielen die Angriffszenarien keine Rolle.

    Es ist leider sehr einfach sich in PHP in den Fuss zu schiessen und dann an einer Blutvergiftung zu sterben.
    • Niemals user inupt vertrauen bzw. ungefiltert fuer irgendwas uebernehmen
    • So wie ich das sehe hast sehr viele Abhaengigkeiten kreuz und quer zwischen den verschiedenen Komponenten bzw zwischen globalem Zustand. Das macht Aenderungen und fixes sehr schwierig weil man nicht weiss was von wem abhaengt.
    • Du erfindeset ziemlich viele Raeder neu: templates, localization, db abstraction


    Soviel erstmal ne knappe Analyse
    Nun ja, es ist natürlich gewachsener Code. Meine PHP-Kenntnisse sind auch mehr als bescheiden. Da muss das so aussehen

    Die Abhängigkeiten sind nicht so stark wie es auf den ersten Blick wirkt und außerdem eher baumartig. Die globalen Variablen sind (fast alle) in einer Datei konzentriert.
    Wurzel ist die Konfig-Datei globalVars.php, darüber die Datei mit den gängigen Hilfsfunktionen, helper.php.
    Die nächste Ebene ist dann alles im contentmanager-Verzeichnis, welches die Schnittstellen von Oberfläche und Datenbank-Inhalten darstellt. Ganz oben sind die Seiten für die Html-Ausgabe. Die rufen fast nur Funktionen auf, die den HTML-Code irgendwelcher Listen, wie z.B. die Liste alle Spiele, zurückgeben.

    Ok, die Lokalisierung ist ein Fremdkörper. Vor allem mit der Verwendung zweier globaler Variablen, was absolut nicht notwendig wäre (D.h. das globale Wörterbuch $lang kann in die Klasse verschoben werden.)

    Die Datenbankabstraktion besteht aus simplen Hilfsfunktionen, um ein Handle-Objekt zu erzeugen und der Generierung einiger SQL-Statements. Das ist meiner Meinung sogar zu wenig(!) gekapselt, weil nicht alle Methoden, welche die SQL-Statements erzeugen nicht an einem Ort gebündelt sind.
    Benutzerdaten werden jedenfalls durch Formatierungs-Methoden geleitet und dann mit Prepared Statements verarbeitet. Kann sein, dass noch ein, zwei SQL-Befehle ohne Prepared Statements herum schwirren.


    Wenn du oder ein anderer der Meinung ist, dass der Code wegen Sicherheitsbedenken nicht akzeptabel ist, würde ich vorschlagen komplett neu zu beginnen. Ich wollte hier die Codebasis möglichst übersichtlich halten und da kann man sich nicht gegen alle Angriffsvektoren absichern.
    Z.B. ist ein Fluten mit Datenbankeinträgen problemlos möglich. Da ich keine IP's tracken will und das Senden von Registrierungs-Mails rechtlich bedenklich ist, baue ich da auch keinen Schutz ein.

  14. #44
    Registrierter Benutzer Avatar von alpha civ
    Registriert seit
    22.07.06
    Beiträge
    16.757
    Warum überhaupt PhP und nicht Python nehmen? Dann hat man vor allem eine klarere Trennung zwischen der Logik und Aussehen und kein PhP-Mischmasch.

    Edit: Wobei, man wäre ja dann auf Python 2.4 beschränkt. Andernfalls könnte man so ein Framework wie Djiango nehmen.
    Geändert von alpha civ (14. August 2014 um 17:54 Uhr)

  15. #45
    Say My Name Avatar von Zulan
    Registriert seit
    13.03.08
    Beiträge
    8.901
    Zitat Zitat von Ramkhamhaeng Beitrag anzeigen
    Ja, PHP ist Teufelswerk :-( Aber da ich den Webkram eh nicht so leiden kann habe mich da noch nicht
    mit Alternativen beschäftigt.
    Aber mit dem Code liegen ja alle Schnittstellen zum Pitboss-Server offen. Alle Methoden, die mit dem PB-Server kommunizieren sind in php/pbModFunctions.php und php/helper.php zu finden. Wer also den PHP-Unterbau durch eine bessere Lösung ersetzen will möge hervortreten



    Die Problematik ist mir bekannt, aber zumindest register_globals hat doch niemand mehr aktiviert.
    Wenn der Angreifer beliebige Variablen definieren kann sind include-Befehle sicher das einfachste Einfallstor aber auch sehr viele andere Sachen möglich. Eigentlich ist dann kein Code der Welt zu retten.
    Richtig. Ist sogar seit 5.4 (2012) ganz entfernt, leider gibts immernoch neue 5.3 releases Wollts nur gesagt, keine Ahnung was da an veralteten Webhostings rumgeistert.

    Zitat Zitat von Ramkhamhaeng Beitrag anzeigen
    Da hast du Recht. Hab gleich mal geguckt und noch drei Aufrufe mit ungefiltertem GET-Aufruf gefunden.
    Ich gucke auch noch mal die (wenigen!) $_SERVER["REQUEST_URI"]; durch… Andererseits… in Hinblick auf den Einsatzzweck der Seite spielen die Angriffszenarien keine Rolle.
    Ich bau lieber aus Prinzip sicher als auf Gutartigkeit zu vertrauen. Hab schon zu viel mist erlebt, auch wenn die Civ Community aussergewoehnlich gut ist.

    Zitat Zitat von Ramkhamhaeng Beitrag anzeigen

    Nun ja, es ist natürlich gewachsener Code. Meine PHP-Kenntnisse sind auch mehr als bescheiden. Da muss das so aussehen

    Die Abhängigkeiten sind nicht so stark wie es auf den ersten Blick wirkt und außerdem eher baumartig. Die globalen Variablen sind (fast alle) in einer Datei konzentriert.
    Wurzel ist die Konfig-Datei globalVars.php, darüber die Datei mit den gängigen Hilfsfunktionen, helper.php.
    Die nächste Ebene ist dann alles im contentmanager-Verzeichnis, welches die Schnittstellen von Oberfläche und Datenbank-Inhalten darstellt. Ganz oben sind die Seiten für die Html-Ausgabe. Die rufen fast nur Funktionen auf, die den HTML-Code irgendwelcher Listen, wie z.B. die Liste alle Spiele, zurückgeben.

    Ok, die Lokalisierung ist ein Fremdkörper. Vor allem mit der Verwendung zweier globaler Variablen, was absolut nicht notwendig wäre (D.h. das globale Wörterbuch $lang kann in die Klasse verschoben werden.)

    Die Datenbankabstraktion besteht aus simplen Hilfsfunktionen, um ein Handle-Objekt zu erzeugen und der Generierung einiger SQL-Statements. Das ist meiner Meinung sogar zu wenig(!) gekapselt, weil nicht alle Methoden, welche die SQL-Statements erzeugen nicht an einem Ort gebündelt sind.
    Benutzerdaten werden jedenfalls durch Formatierungs-Methoden geleitet und dann mit Prepared Statements verarbeitet. Kann sein, dass noch ein, zwei SQL-Befehle ohne Prepared Statements herum schwirren.


    Wenn du oder ein anderer der Meinung ist, dass der Code wegen Sicherheitsbedenken nicht akzeptabel ist, würde ich vorschlagen komplett neu zu beginnen. Ich wollte hier die Codebasis möglichst übersichtlich halten und da kann man sich nicht gegen alle Angriffsvektoren absichern.
    Z.B. ist ein Fluten mit Datenbankeinträgen problemlos möglich. Da ich keine IP's tracken will und das Senden von Registrierungs-Mails rechtlich bedenklich ist, baue ich da auch keinen Schutz ein.
    Also auch wenn ich einiges anders gemacht haette, wuerde ich jetzt nicht gleich von vorne anfangen. Das macht sich sowieso besser wenn man damit ein bisschen mehr Anforderungen/Ideen gesammelt hat. Sicherheitstechnisch kann man das mit kleinen Modifikationen verantworten. Ich hab kein Problem das zu hosten (mit ein bisschen paranoiden apache/php settings ).
    Ich werd vermutlich noch ein paar kleine pull requests schicken, kenn mich aber mit github nicht so aus.

Seite 3 von 53 ErsteErste 123456713 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •