Ich habe in den letzten Tagen die AEGIS-Sicherheitsanalyse zu @Dusk durchgesehen. Am Anfang habe ich mir nur „39 Fixes, 7 critical“ gemerkt. Erst nach dem Detail-Teil wurde mir klar: Die Zahlen sind nicht das Entscheidende. Die sieben schwerwiegenden Probleme haben sich am Ende auf vier Klassen von Root Causes verdichtet: Alias-Probleme in der VM-Sandbox, unsichere Deserialisierung auf der Host-Seite, dass Phoenix-Gebühr und Erstattung nicht vollständig an dieselbe Semantik gebunden sind, sowie ein Pfad zur Fälschung von BLS-Signaturen.
Warum sollte man sich die Root Causes ansehen, statt nur die Anzahl der Schwachstellen? Weil es, wenn dieselbe Vertrauensgrenze nicht sauber eingezeichnet wird, in unterschiedlichen Modulen immer wieder zu Problemen kommt. Zum Beispiel: Wenn Eingaben noch nicht validiert sind und dann deserialisiert wird, wirkt es zunächst wie ein einmaliger Parsing-Fehler—tatsächlich kann man aber auf die Sicherheitsschwächen des Host-Speichers stoßen. Die Phoenix-Themen sind außerdem nicht nur „eine Kleinigkeit bei der Gebührenberechnung“: Die Beweisführung, die Signatur und die Ausführung der Erstattung erzählen nicht dieselbe Semantik. Im schlimmsten Fall trifft das auf Liefer-/Integritätsfähigkeit und Funds-Sicherheit.
Offiziell heißt es, dass derzeit keine dieser criticals vor der Behebung ausgenutzt worden sind. Ich will das als Untersuchungsergebnis akzeptieren und es nicht zu einem „absolut nie passiert“ hochstufen. Für $DUSK ist das Positive an AEGIS, dass das Team interne Funde öffentlich gemacht hat—inklusive Root-Cause-Analyse und Reparaturlogik. Das Negative ist ebenfalls klar: Nach dem Mainnet-Launch gab es tatsächlich gefährliche Lücken im Kern-Stack, die Ausführung, Konsens-Authentifizierung und die Kettenverfügbarkeit beeinträchtigen können.
Daher werde ich #dusk nicht mit dem Argument „es gab viele Audits“ einfach ein Sicherheits-Gütesiegel geben. Nützlicher ist die Beobachtung: Wird in der nächsten Runde weiterhin offengelegt? Gibt es Regressionstests für ähnliche Grenzen? Kann die externe Prüfung auch den Code nach AEGIS abdecken? Worauf legt ihr mehr Wert—darauf, dass das Projekt nie große Probleme gezeigt hat, oder darauf, dass es sie offengelegt hat und anschließend Root Cause, Auswirkungen und die Reparaturkette klar erklärt?
$USELESS $BOME
Warum sollte man sich die Root Causes ansehen, statt nur die Anzahl der Schwachstellen? Weil es, wenn dieselbe Vertrauensgrenze nicht sauber eingezeichnet wird, in unterschiedlichen Modulen immer wieder zu Problemen kommt. Zum Beispiel: Wenn Eingaben noch nicht validiert sind und dann deserialisiert wird, wirkt es zunächst wie ein einmaliger Parsing-Fehler—tatsächlich kann man aber auf die Sicherheitsschwächen des Host-Speichers stoßen. Die Phoenix-Themen sind außerdem nicht nur „eine Kleinigkeit bei der Gebührenberechnung“: Die Beweisführung, die Signatur und die Ausführung der Erstattung erzählen nicht dieselbe Semantik. Im schlimmsten Fall trifft das auf Liefer-/Integritätsfähigkeit und Funds-Sicherheit.
Offiziell heißt es, dass derzeit keine dieser criticals vor der Behebung ausgenutzt worden sind. Ich will das als Untersuchungsergebnis akzeptieren und es nicht zu einem „absolut nie passiert“ hochstufen. Für $DUSK ist das Positive an AEGIS, dass das Team interne Funde öffentlich gemacht hat—inklusive Root-Cause-Analyse und Reparaturlogik. Das Negative ist ebenfalls klar: Nach dem Mainnet-Launch gab es tatsächlich gefährliche Lücken im Kern-Stack, die Ausführung, Konsens-Authentifizierung und die Kettenverfügbarkeit beeinträchtigen können.
Daher werde ich #dusk nicht mit dem Argument „es gab viele Audits“ einfach ein Sicherheits-Gütesiegel geben. Nützlicher ist die Beobachtung: Wird in der nächsten Runde weiterhin offengelegt? Gibt es Regressionstests für ähnliche Grenzen? Kann die externe Prüfung auch den Code nach AEGIS abdecken? Worauf legt ihr mehr Wert—darauf, dass das Projekt nie große Probleme gezeigt hat, oder darauf, dass es sie offengelegt hat und anschließend Root Cause, Auswirkungen und die Reparaturkette klar erklärt?
$USELESS $BOME
