Etherpad-lite: SQL-Injection-Versuche töten Etherpad lite

Das stimmt.
Danke für die wertvollen Informationen, @fpoulain , sehr geschätzt!

Hey Leute, nur eine Erinnerung an die verantwortungsvolle Offenlegung. Öffentlich zu posten, ohne uns die Chance zu geben, etwas auszuwählen, kann ziemlich gefährlich sein.

Hey Leute, nur eine Erinnerung an die verantwortungsvolle Offenlegung. Öffentlich zu posten, ohne uns die Chance zu geben, etwas auszuwählen, kann ziemlich gefährlich sein.

Hm...eigentlich wurde es schon bekannt gegeben, weil es von einigen fiesen Typen benutzt wird.

Außerdem sehe ich nicht, wie ich es auf nicht öffentliche Weise melden soll. Die Projektbeschreibung erwähnt sowieso keine private Feedbackschleife für Sicherheitsprobleme. Wie denkst du hätte ich es gemeldet?

Afaik haben wir eine verantwortungsvolle Offenlegungsrichtlinie. Ich dachte, es wäre auf etherpad.org und der Github-Readme.

Von: François Poulain [email protected]
Gesendet: Montag, 21. Januar 2019 11:16 Uhr
An: ether/etherpad-lite
CC: John McLear; Kommentar
Betreff: Re: [ether/etherpad-lite] SQL-Injection-Versuche töten Etherpad lite (#3502)

Hey Leute, nur eine Erinnerung an die verantwortungsvolle Offenlegung. Öffentlich zu posten, ohne uns die Chance zu geben, etwas auszuwählen, kann ziemlich gefährlich sein.

Hm...eigentlich wurde es schon bekannt gegeben, weil es von einigen fiesen Typen benutzt wird.

Außerdem sehe ich nicht, wie ich es auf nicht öffentliche Weise melden soll. Die Projektbeschreibung erwähnt sowieso keine private Feedbackschleife für Sicherheitsprobleme. Wie denkst du hätte ich es gemeldet?

-
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/ether/etherpad-lite/issues/3502#issuecomment-456039980 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/ AANewII6dbcPV2hlcP4uA5c4OHESwQJuks5vFaK4gaJpZM4X1_tz .

Es könnte eine gute Idee sein, eine Einladung hinzuzufügen "Sicherheitsproblem gefunden? Informieren Sie uns über ...". Bevor ich diese Ausgabe geöffnet habe, habe ich einige Minuten in der Readme-Datei von github und auf etherpad.org verbracht, ohne eine solche Einladung zu finden. Auch als nicht muttersprachlicher englischer Leser hätte ich die guten Begriffe verpassen können, nach denen ich suchen musste.

Bemerkt. Tnx

Von: François Poulain [email protected]
Gesendet: Montag, 21. Januar 2019 14:35 Uhr
An: ether/etherpad-lite
CC: John McLear; Kommentar
Betreff: Re: [ether/etherpad-lite] SQL-Injection-Versuche töten Etherpad lite (#3502)

Es könnte eine gute Idee sein, eine Einladung hinzuzufügen "Sicherheitsproblem gefunden? Informieren Sie uns über ...". Bevor ich diese Ausgabe geöffnet habe, habe ich einige Minuten auf github und auf etherpad.org verbracht, ohne eine solche Einladung zu finden. Auch als nicht muttersprachlicher englischer Leser hätte ich die guten Begriffe verpassen können, nach denen ich suchen musste.

-
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/ether/etherpad-lite/issues/3502#issuecomment-456096384 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/ AANewFZlv6xtuszRP2CCBwWoDHGgTrFwks5vFdGEgaJpZM4X1_tz .

Ich konnte auch keinen finden, aber ich habe festgestellt, dass Sie einen PR angefordert haben, um einen hinzuzufügen https://github.com/ether/etherpad-lite/issues/2499.

Vielleicht erwägen Sie einfach, als schnelle Lösung ein https://securitytxt.org/ zu erstellen?

Anstößiger Code ist irgendwo hier drin: https://github.com/ether/yajsml/blob/master/server.js#L98

Haftungsausschluss: Ich bin nicht schlau genug, um dieses Problem zu lösen. Ich brauche jemanden, der sich auskennt!

Hey! Werde das jetzt mal untersuchen.

Zunächst einmal: um alle Ängste vor SQLi abzuwehren: Das hat nichts mit SQL-Injection zu tun, wie diese alternative Nutzlast beweist, die auch den gleichen Absturz verursacht:

/javascripts/lib/ep_etherpad-lite/static/js/pad.js?callback=require.define&footlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootlefootle

Dies ist ein Problem mit der Dateinamenlänge in der Caching-Middleware.

Derzeit wird der Cache-Schlüssel wie folgt generiert:

var cacheKey = Buffer.from(path).toString('base64').replace(/[/+=]/g, '');

Dies bewirkt, dass die Länge des Cache-Schlüssels durch die Länge des Pfads gesteuert wird.

Dies ist ein Problem, wenn der Cache-Schlüssel als Dateiname auf der Festplatte verwendet wird, da viele Dateisysteme die Dateinamenlänge auf 255 Zeichen beschränken. Aus diesem Grund gibt es einen ENAMETOOLONG Fehler im Protokoll.

Um dies zu beheben, schlage ich vor, den Cache-Schlüssel zu einem Hash des Pfads anstelle der base64-codierten Version zu machen. Dadurch wird ein Dateiname mit fester Länge sichergestellt.

Ich werde in Kürze eine PR einreichen, die dies tut.

Hallo, @tomnomnom , das ist clever. Es ist durchaus sinnvoll, dass Cache-Schlüssel eine feste Länge haben. Auf diese Weise bleiben sie abhängig vom Inhalt, mit praktisch keiner Kollisionsgefahr.

Ich schau heute Abend mal nach.
Gut erledigt!

Die PR zusammengeführt, vielen Dank!

Ein weiterer Hinweis dazu: Aus den nodejs-Dokumenten müssen wir möglicherweise die Möglichkeit in Betracht ziehen, dass das Modul crypto nicht verfügbar ist :

Es ist möglich, dass Node.js ohne Unterstützung für das Kryptomodul erstellt wird. In solchen Fällen führt der Aufruf von require('crypto') dazu, dass ein Fehler ausgegeben wird

Vielleicht haben eingebettete Plattformen es nicht (zB: ARM, MIPS, Raspberry PIs & ähnliches)? Ich weiß nicht. Eine Beschreibung solcher Szenarien finden Sie hier :

• Ausführen eines Nicht-Standard-Knotens in einer Umgebung mit eingeschränkten Ressourcen oder Sicherheit (siehe Knoten Nr. 5611 für die explizite Unterstützung dieses Szenarios)
• läuft in emulierter Umgebung (browserify, webpack etc.)
• Knoten aus der Quelle erstellen und openssl/crypto aus zufälligen Gründen weglassen (siehe StackOverflow-Frage oder einen anderen nodejs-Beitrag )

Wie auch immer, die TypeScript-Leute haben sich mit demselben Problem in https://github.com/microsoft/TypeScript/issues/19100 befasst und es auf elegante Weise in https://github.com/microsoft/TypeScript/commit/ gelöst.

Wenn das Importieren von Krypto zur Laufzeit fehlschlägt, ersetzen sie den Hash-Algorithmus durch den djb2-Algorithmus , der viel schwächer ist, aber für ihren Fall funktioniert.

Ein für unseren Fall angepasstes Beispiel könnte sein:

function djb2Hash(data) {
    const chars = data.split("").map(str => str.charCodeAt(0));
    return `${chars.reduce((prev, curr) => ((prev << 5) + prev) + curr, 5381)}`;
}

console.log(Buffer.from(djb2Hash('This is a 😎 test of the djb2 hash function')).toString('hex'));
// prints 36373536373437333033

Ich bitte Sie nicht, dies zu tun, aber die Geschichte von djb2 macht Spaß: siehe hier , und den originalen Mailinglisten-Post von Daniel Bernstein von 1991. Er war damals 20 Jahre alt.

Follow-up, das djb2 wenn keine Krypto-Unterstützung vorhanden ist: #3797.