Scrolls heutiger Incident-Bericht ist deutlich interessanter als die vier Worte „nicht ausgenutzt“.
Ich habe den Originalbeitrag im Forum nachgeschlagen (11/11, 14:24 UTC). Betroffen war der Verifizierungsvertrag ZkEvmVerifierPostFeynman für Bundle-Proofs im Mainnet (0x7966…B254). Er setzt die Eingaben manuell zusammen und ruft den Halo2-Verifier von OpenVM 2.0 per raw staticcall auf. Die ersten 4 Bytes des Aufrufs stammen direkt aus dem vom Einreicher gelieferten Proof. OpenVM 2.0 hatte genau eine typisierte verify-Funktion mit dem Selector 0x24270d54. Begann ein Proof mit diesen 4 Bytes, landete der Aufruf nicht im Fallback, sondern in dieser Funktion; die öffentlichen Eingaben wurden dabei an einer vom Aufrufer kontrollierten Position gelesen. Das Ergebnis: Ein alter, gültiger Proof konnte dazu verwendet werden, eine neue Zustandswurzel und Auszahlungswurzel zu bestätigen. In einfachen Worten: Theoretisch hätte man eine frei erfundene Auszahlungswurzel bestätigen können – das Geld in der Bridge wäre das Ziel gewesen.
Die Ironie daran: Der Vertrag wurde am 22. September im Zuge des OpenVM-v2.0-Upgrades bereitgestellt. Einer der in der damaligen Ankündigung genannten Gründe für das Upgrade war die Behebung des Sicherheitsproblems aus der v1.7.0-Sicherheitsmeldung. Einer der dort aufgeführten Punkte hieß „OpenVmHalo2Verifier self-call can bypass proof verification“ – ebenfalls ein Bypass auf der Ebene des Verifier-Wrappers. Damals wurde das Ganze als Wartungsupgrade eingestuft: Es gab nur eine Ankündigung, keine Abstimmung. Ein Loch in der Wrapper-Schicht wurde gestopft, und im neuen Vertrag wurde auf derselben Ebene ein neues aufgerissen, das 49 Tage lang offenstand (22.9. bis 10.11.).
Warum ist nichts passiert? Im Bericht steht es selbst: Für einen Angriff wäre entweder die Rolle eines zugelassenen Provers nötig gewesen oder der erzwungene Batch-Modus, der erst nach 7 Tagen ohne Finalisierung freigeschaltet wird. Während der 748 Finalisierungen, die der anfällige Vertrag online war, wurden ausschließlich gültige Proofs verwendet; der erzwungene Modus wurde nie aktiviert.
Was diese 49 Tage also tatsächlich abgesichert hat, war nicht die ZK-Mathematik, sondern: „Nur Scrolls eigene Prover können Proofs einreichen.“ Normalerweise kritisieren alle die Zentralisierung der L2-Prover. Diesmal war es ausgerechnet die Zentralisierung, die die Tür geschlossen hielt. Noch bitterer wird es, wenn man die Sache umdreht: Die 7-Tage-Notausstiegsmöglichkeit, die als Zensurresistenz-Mechanismus gedacht ist, würde nach ihrer Aktivierung zum Angriffseinstieg für jedermann.
Für die Offenlegung gibt es von mir ein Lob. Der Whitehat ZHOUCHUNGONG meldete den Fehler am 3.11.; am 10.11. wurde der reparierte Vertrag registriert. Die neue Adresse, der Fix-PR und die Registrierungstransaktion wurden alle veröffentlicht, dazu eine Anleitung, mit der man die Angaben selbst überprüfen kann. Das ist besser als bei vielen Projekten. Aber die Behauptung „Mit einem validity proof muss man dem Betreiber nicht vertrauen“ wurde diesmal vom eigenen Bericht höchstpersönlich auseinandergenommen. Wer L2-Assets hält, sollte nicht nur fragen, ob es ZK ist, sondern auch, wer den Prover betreibt, wie oft der Verifizierungsvertrag ausgetauscht wird und ob es beim Austausch eine Abstimmung und ein Audit gibt. Wie hoch die Prämie war und ob der neue Vertrag extern geprüft wurde, steht nicht im Bericht – darüber spekuliere ich nicht.
#Scroll #以太坊L2
Ich habe den Originalbeitrag im Forum nachgeschlagen (11/11, 14:24 UTC). Betroffen war der Verifizierungsvertrag ZkEvmVerifierPostFeynman für Bundle-Proofs im Mainnet (0x7966…B254). Er setzt die Eingaben manuell zusammen und ruft den Halo2-Verifier von OpenVM 2.0 per raw staticcall auf. Die ersten 4 Bytes des Aufrufs stammen direkt aus dem vom Einreicher gelieferten Proof. OpenVM 2.0 hatte genau eine typisierte verify-Funktion mit dem Selector 0x24270d54. Begann ein Proof mit diesen 4 Bytes, landete der Aufruf nicht im Fallback, sondern in dieser Funktion; die öffentlichen Eingaben wurden dabei an einer vom Aufrufer kontrollierten Position gelesen. Das Ergebnis: Ein alter, gültiger Proof konnte dazu verwendet werden, eine neue Zustandswurzel und Auszahlungswurzel zu bestätigen. In einfachen Worten: Theoretisch hätte man eine frei erfundene Auszahlungswurzel bestätigen können – das Geld in der Bridge wäre das Ziel gewesen.
Die Ironie daran: Der Vertrag wurde am 22. September im Zuge des OpenVM-v2.0-Upgrades bereitgestellt. Einer der in der damaligen Ankündigung genannten Gründe für das Upgrade war die Behebung des Sicherheitsproblems aus der v1.7.0-Sicherheitsmeldung. Einer der dort aufgeführten Punkte hieß „OpenVmHalo2Verifier self-call can bypass proof verification“ – ebenfalls ein Bypass auf der Ebene des Verifier-Wrappers. Damals wurde das Ganze als Wartungsupgrade eingestuft: Es gab nur eine Ankündigung, keine Abstimmung. Ein Loch in der Wrapper-Schicht wurde gestopft, und im neuen Vertrag wurde auf derselben Ebene ein neues aufgerissen, das 49 Tage lang offenstand (22.9. bis 10.11.).
Warum ist nichts passiert? Im Bericht steht es selbst: Für einen Angriff wäre entweder die Rolle eines zugelassenen Provers nötig gewesen oder der erzwungene Batch-Modus, der erst nach 7 Tagen ohne Finalisierung freigeschaltet wird. Während der 748 Finalisierungen, die der anfällige Vertrag online war, wurden ausschließlich gültige Proofs verwendet; der erzwungene Modus wurde nie aktiviert.
Was diese 49 Tage also tatsächlich abgesichert hat, war nicht die ZK-Mathematik, sondern: „Nur Scrolls eigene Prover können Proofs einreichen.“ Normalerweise kritisieren alle die Zentralisierung der L2-Prover. Diesmal war es ausgerechnet die Zentralisierung, die die Tür geschlossen hielt. Noch bitterer wird es, wenn man die Sache umdreht: Die 7-Tage-Notausstiegsmöglichkeit, die als Zensurresistenz-Mechanismus gedacht ist, würde nach ihrer Aktivierung zum Angriffseinstieg für jedermann.
Für die Offenlegung gibt es von mir ein Lob. Der Whitehat ZHOUCHUNGONG meldete den Fehler am 3.11.; am 10.11. wurde der reparierte Vertrag registriert. Die neue Adresse, der Fix-PR und die Registrierungstransaktion wurden alle veröffentlicht, dazu eine Anleitung, mit der man die Angaben selbst überprüfen kann. Das ist besser als bei vielen Projekten. Aber die Behauptung „Mit einem validity proof muss man dem Betreiber nicht vertrauen“ wurde diesmal vom eigenen Bericht höchstpersönlich auseinandergenommen. Wer L2-Assets hält, sollte nicht nur fragen, ob es ZK ist, sondern auch, wer den Prover betreibt, wie oft der Verifizierungsvertrag ausgetauscht wird und ob es beim Austausch eine Abstimmung und ein Audit gibt. Wie hoch die Prämie war und ob der neue Vertrag extern geprüft wurde, steht nicht im Bericht – darüber spekuliere ich nicht.
#Scroll #以太坊L2