đ
17. August
Heute sollte das TGE fĂŒr $DGAI eigentlich stattfinden, aber es ist gescheitert. Mal sehen, ob es morgen klapptâich bleibe fĂŒr euch dran.
Ich habe in letzter Zeit Dusk kontinuierlich beobachtet. Wang Taiyu hat mir gesagt, es gebe zwei kritische Schwachstellen, die in der Piecrust-VM versteckt seien. Ich glaubte das erst nicht und habe deshalb die Whitepaper durchgesehen. Als ich dort â7 Erkenntnisse auf Critical-Niveauâ gelesen habe, dachte ich mir: interessant.
Ehrlich gesagt: Bei der Sicherheit hat Dusk wirklich Arbeit investiert. Piecrust ist die VM-Sandbox-Schicht, die die RWA-Privacy-Contracts stĂŒtzt. Sie haben Porter Adams und dergleichen Top-Kryptografen mit einem Audit beauftragt; vor dem Mainnet-Launch wurden bereits ĂŒber 10 unabhĂ€ngige Audits abgeschlossen. Aber âviele Auditsâ und âkeine Schwachstellenâ sind zwei Paar Schuhe.
Von den 39 Problemen, die durch den AEGIS-Hardfork behoben wurden, wurden 7 als âschwerwiegendâ eingestuft. Davon stammten zwei der tödlichsten Schwachstellen direkt aus der Piecrust-VM-Sandbox-Schicht. Das Kernproblem besteht darin, dass das Ownership-Modell von Rust umgangen werden kannâSession- und Instance-Status lassen sich aliasieren, sodass mehrere verĂ€nderliche Referenzen gleichzeitig existieren. In der Laufzeit einer Blockchain bedeutet das: Zwei ehrliche Knoten, die denselben Code ausfĂŒhren, können zu unterschiedlichen Ergebnissen kommen. Damit wird die Determiniertheit der gesamten AusfĂŒhrungsgrenze zerstört. Ein bösartiger Contract muss nur den Runtime-Status in eine bestimmte Konstellation drĂŒcken, dann ist das Typsystem praktisch komplett ausgehebelt.
AuĂerdem gibt es eine Schwachstelle in der unsicheren Deserialisierungâbeim Deserialisieren des host query-Parameters erfolgt keine SicherheitsprĂŒfung. Angreifer könnten diesen Fehler nutzen, um aus der Contract-Sandbox in den Speicher des Host-Prozesses zu entkommen.
Die Reaktion von Dusk ist anerkennenswert: Der AEGIS-Hardfork hat das Ownership-Modell von Piecrust umgeschrieben und die Alias-Schwachstelle damit geschlossen. Das Team hat auĂerdem öffentlich erklĂ€rt, dass es bislang keine Beweise dafĂŒr gebe, dass Schwachstellen ausgenutzt wurden.
Aber die 7 Schwachstellen auf Critical-Niveauâdavon zwei direkt in der VM-Sandbox-Schichtâzeigen: Selbst wenn die Piecrust-Implementierung noch so hochwertig ist, braucht eine neu entwickelte Privacy-VM weiterhin eine ausreichend lange reale Praxis- und Erprobungsphase.
Wenn es bereits eine Privacy-Contract-Plattform gab, die durch eine Schwachstelle in der VM-Sandbox einen Notfall-Hardfork ausgelöst hatâbist du sicher, dass das nĂ€chste Mal ein Ă€hnliches Ownership-Leak nicht in noch tieferen Codepfaden versteckt ist?
Das Obige ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Poste gern im Kommentarbereichâfindest du, dass das VM-Sandbox-Design von Piecrust ein sinnvollen Engineering-Kompromiss ist, oder eher eine Zeitbombe?
#dusk $DUSK @Dusk
Heute sollte das TGE fĂŒr $DGAI eigentlich stattfinden, aber es ist gescheitert. Mal sehen, ob es morgen klapptâich bleibe fĂŒr euch dran.
Ich habe in letzter Zeit Dusk kontinuierlich beobachtet. Wang Taiyu hat mir gesagt, es gebe zwei kritische Schwachstellen, die in der Piecrust-VM versteckt seien. Ich glaubte das erst nicht und habe deshalb die Whitepaper durchgesehen. Als ich dort â7 Erkenntnisse auf Critical-Niveauâ gelesen habe, dachte ich mir: interessant.
Ehrlich gesagt: Bei der Sicherheit hat Dusk wirklich Arbeit investiert. Piecrust ist die VM-Sandbox-Schicht, die die RWA-Privacy-Contracts stĂŒtzt. Sie haben Porter Adams und dergleichen Top-Kryptografen mit einem Audit beauftragt; vor dem Mainnet-Launch wurden bereits ĂŒber 10 unabhĂ€ngige Audits abgeschlossen. Aber âviele Auditsâ und âkeine Schwachstellenâ sind zwei Paar Schuhe.
Von den 39 Problemen, die durch den AEGIS-Hardfork behoben wurden, wurden 7 als âschwerwiegendâ eingestuft. Davon stammten zwei der tödlichsten Schwachstellen direkt aus der Piecrust-VM-Sandbox-Schicht. Das Kernproblem besteht darin, dass das Ownership-Modell von Rust umgangen werden kannâSession- und Instance-Status lassen sich aliasieren, sodass mehrere verĂ€nderliche Referenzen gleichzeitig existieren. In der Laufzeit einer Blockchain bedeutet das: Zwei ehrliche Knoten, die denselben Code ausfĂŒhren, können zu unterschiedlichen Ergebnissen kommen. Damit wird die Determiniertheit der gesamten AusfĂŒhrungsgrenze zerstört. Ein bösartiger Contract muss nur den Runtime-Status in eine bestimmte Konstellation drĂŒcken, dann ist das Typsystem praktisch komplett ausgehebelt.
AuĂerdem gibt es eine Schwachstelle in der unsicheren Deserialisierungâbeim Deserialisieren des host query-Parameters erfolgt keine SicherheitsprĂŒfung. Angreifer könnten diesen Fehler nutzen, um aus der Contract-Sandbox in den Speicher des Host-Prozesses zu entkommen.
Die Reaktion von Dusk ist anerkennenswert: Der AEGIS-Hardfork hat das Ownership-Modell von Piecrust umgeschrieben und die Alias-Schwachstelle damit geschlossen. Das Team hat auĂerdem öffentlich erklĂ€rt, dass es bislang keine Beweise dafĂŒr gebe, dass Schwachstellen ausgenutzt wurden.
Aber die 7 Schwachstellen auf Critical-Niveauâdavon zwei direkt in der VM-Sandbox-Schichtâzeigen: Selbst wenn die Piecrust-Implementierung noch so hochwertig ist, braucht eine neu entwickelte Privacy-VM weiterhin eine ausreichend lange reale Praxis- und Erprobungsphase.
Wenn es bereits eine Privacy-Contract-Plattform gab, die durch eine Schwachstelle in der VM-Sandbox einen Notfall-Hardfork ausgelöst hatâbist du sicher, dass das nĂ€chste Mal ein Ă€hnliches Ownership-Leak nicht in noch tieferen Codepfaden versteckt ist?
Das Obige ist nur meine persönliche Meinung und stellt keine Anlageberatung dar. Poste gern im Kommentarbereichâfindest du, dass das VM-Sandbox-Design von Piecrust ein sinnvollen Engineering-Kompromiss ist, oder eher eine Zeitbombe?
#dusk $DUSK @Dusk
