Niemand möchte ein Dokument veröffentlichen, in dem jede schwerwiegende Schwachstelle aufgelistet ist, die ein Auditor in seinem eigenen Protokoll gefunden hat. Dusk Network hat genau das mit AEGIS getan, seinem größten Hard Fork seit dem Mainnet-Launch, und ich denke, die Entscheidung, so transparent zu sein, verdient mehr Aufmerksamkeit als die Bugs selbst.
AEGIS lieferte Fixes für 39 Befunde, davon 7 als kritisch eingestuft. Diese lassen sich auf 4 Hauptursachen zurückführen: eine unsolide Speicherverwaltung (Memory Ownership) in der Piecrust-Virtual-Machine-Sandbox, die es zwei ehrlichen Knoten ermöglichen könnte, ohne sichtbaren Hinweis unterschiedliche Ergebnisse aus demselben Code zu berechnen; eine unsichere Deserialisierung nicht vertrauenswürdiger Daten auf der Host-Seite; eine Lücke in der Bindung zwischen Phoenix-Gebühr und -Refund, die potenziell eine Erhöhung des Angebots (Supply Inflation) hätte ermöglichen oder die Kette vollständig hätte anhalten können; sowie eine fehlerhafte BLS-Signaturkonstruktion, die möglicherweise Fälschungen durch eine einzige beobachtete Signatur gestattet hätte. Dusk stellte ausdrücklich klar, dass es keine Hinweise darauf gefunden habe, dass irgendeines dieser Probleme vor dem Ausliefern des Fixes ausgenutzt wurde, und die Fixes gingen über das reine Beheben von Symptomen hinaus: Es wurden Ownership-Modelle neu ausgearbeitet, Prüfungen sowohl bei der Mempool-Zulassung als auch bei der VM-Ausführung erzwungen – statt nur auf einer einzigen Ebene –, und es wurde auf einen korrekten Hash im RFC-9380-Stil für die Kurvenkonstruktion bei BLS umgestellt, inklusive expliziter Domänentrennung.
Was mir auffällt, ist die Einordnung im gesamten Write-up. Dusk trennt wiederholt die Schadensbegrenzung (Mitigation) von der Beseitigung der Root Cause und behandelt beides als notwendig – ein Maß an Ingenieursdisziplin, das man in der Öffentlichkeit nur selten so beschrieben sieht.
Ich möchte aber nicht so tun, als wäre das nur gute Nachricht. Ein Cluster kritischer, kettenrelevanter Schwachstellen, die überhaupt in einem Live-Finanzprotokoll existieren, ist ein ernsthafter Befund – Audit hin oder her. Einen Hard Fork dieser Größenordnung über ein Live-Validator-Set zu koordinieren, ohne irgendjemanden zu alarmieren, der die Befunde möglicherweise zuerst ausnutzen könnte, ist für sich genommen eine stille Ingenieursleistung, die selten die gebührende Anerkennung erhält.
DUSK sichert ein Protokoll ab, das jetzt deutlich schwerer zu knacken ist.
@Dusk $DUSK #dusk
$BTW
AEGIS lieferte Fixes für 39 Befunde, davon 7 als kritisch eingestuft. Diese lassen sich auf 4 Hauptursachen zurückführen: eine unsolide Speicherverwaltung (Memory Ownership) in der Piecrust-Virtual-Machine-Sandbox, die es zwei ehrlichen Knoten ermöglichen könnte, ohne sichtbaren Hinweis unterschiedliche Ergebnisse aus demselben Code zu berechnen; eine unsichere Deserialisierung nicht vertrauenswürdiger Daten auf der Host-Seite; eine Lücke in der Bindung zwischen Phoenix-Gebühr und -Refund, die potenziell eine Erhöhung des Angebots (Supply Inflation) hätte ermöglichen oder die Kette vollständig hätte anhalten können; sowie eine fehlerhafte BLS-Signaturkonstruktion, die möglicherweise Fälschungen durch eine einzige beobachtete Signatur gestattet hätte. Dusk stellte ausdrücklich klar, dass es keine Hinweise darauf gefunden habe, dass irgendeines dieser Probleme vor dem Ausliefern des Fixes ausgenutzt wurde, und die Fixes gingen über das reine Beheben von Symptomen hinaus: Es wurden Ownership-Modelle neu ausgearbeitet, Prüfungen sowohl bei der Mempool-Zulassung als auch bei der VM-Ausführung erzwungen – statt nur auf einer einzigen Ebene –, und es wurde auf einen korrekten Hash im RFC-9380-Stil für die Kurvenkonstruktion bei BLS umgestellt, inklusive expliziter Domänentrennung.
Was mir auffällt, ist die Einordnung im gesamten Write-up. Dusk trennt wiederholt die Schadensbegrenzung (Mitigation) von der Beseitigung der Root Cause und behandelt beides als notwendig – ein Maß an Ingenieursdisziplin, das man in der Öffentlichkeit nur selten so beschrieben sieht.
Ich möchte aber nicht so tun, als wäre das nur gute Nachricht. Ein Cluster kritischer, kettenrelevanter Schwachstellen, die überhaupt in einem Live-Finanzprotokoll existieren, ist ein ernsthafter Befund – Audit hin oder her. Einen Hard Fork dieser Größenordnung über ein Live-Validator-Set zu koordinieren, ohne irgendjemanden zu alarmieren, der die Befunde möglicherweise zuerst ausnutzen könnte, ist für sich genommen eine stille Ingenieursleistung, die selten die gebührende Anerkennung erhält.
DUSK sichert ein Protokoll ab, das jetzt deutlich schwerer zu knacken ist.
@Dusk $DUSK #dusk
$BTW