Philip DiSarro meldet zwei kritische Schwachstellen in der CIP-113 Implementierung von Aiken

Philip DiSarro, Gründer und CEO von Anastasia Labs sowie Autor von CIP-143, sagte am 24. Juli, er habe während der Überprüfung der Aiken Implementierung von Cardanos CIP-113 Framework für programmierbare Token zwei kritische Schwachstellen identifiziert. Im selben Thread veröffentlichte er aktualisierte Benchmarks, die die Aiken Codebasis mit der ursprünglichen Plutarch Implementierung vergleichen, die von DiSarro und dem Input Output Team entwickelt wurde. Die Offenlegung erfolgt, während sich CIP-113 weiterhin in der Phase Last Check befindet und die Implementierung die Sicherheitsprüfung durchläuft.

Plutarch verzeichnet geringere Kosten in allen CIP-113 Benchmarks

Die veröffentlichte Benchmark Datei vergleicht die beiden Implementierungen unter Cardanos maximalem Transaktionsbudget von 10 Milliarden CPU Einheiten und 14 Millionen Speichereinheiten. Sowohl Aiken als auch Plutarch werden letztlich zu Untyped Plutus Core kompiliert, dem Code, der von Cardano Knoten ausgeführt wird.

Plutarch verzeichnete in jedem der fünf hervorgehobenen Szenarien einen geringeren Gesamtverbrauch an CPU und Speicher.

Im Standard Transfer Test verbrauchte Aiken 1,19 mal mehr CPU und 1,17 mal mehr Speicher als Plutarch. Den größten Unterschied unter den gezeigten Szenarien zeigte der Test, der eine Seizure Aktion, ein externes Skript und 50 Public Key Inputs kombinierte; dort benötigte Aiken 3,23 mal mehr CPU und 2,36 mal mehr Speicher.

Beide Implementierungen blieben im Test mit 16 Swaps auf dem $NIGHT DEX innerhalb der Transaktionslimits von Cardano. Plutarch nutzte 6,66 Prozent des verfügbaren CPU Budgets und 11,68 Prozent des Speicherbudgets, verglichen mit 7,59 Prozent und 15,25 Prozent bei Aiken.

Die Veröffentlichung von DiSarro enthielt zudem lineare Projektionen dazu, wie viele Elemente in eine Transaktion passen könnten. Die Schätzungen setzten Plutarch bei 658 Inputs gegenüber 162 bei Aiken, 472 Outputs gegenüber 334, 36.489 Tokens gegenüber 1.661 sowie 527 Policies gegenüber 160 an. Diese Zahlen sind Projektionen der Skriptkapazität auf Basis getesteter Ausführungskosten und keine Messungen des Durchsatzes im Mainnet.

Der Vergleich der kompilierten Skripte ergab kleinere Plutarch Skripte in sechs von sieben Kategorien. Das Skript directoryNodeSpending maß 331 Bytes bei Plutarch und 1.698 Bytes bei Aiken. Eine Ausnahme war programmableLogicGlobal, wo Aiken ein Skript mit 3.157 Bytes erzeugte, verglichen mit 3.437 Bytes bei Plutarch.

CIP-113 fügt programmierbare Regeln zu Cardano Native Assets hinzu

CIP-113 schlägt ein Framework vor, um Cardano Native Assets programmierbare Validierungsregeln hinzuzufügen, ohne eine Änderung des Ledgers oder einen Hard Fork zu erfordern. Emittenten könnten Bedingungen definieren, die bei Token Übertragungen, dem Minten und dem Burnen ausgeführt werden.

Die Regeln können Allowlists, Denylists, Transferbeschränkungen, Time Locks sowie optionale Freeze oder Seizure Funktionen umfassen. Das Framework ist für Stablecoins, tokenisierte Wertpapiere und Real World Assets gedacht, die Kontrollen bezüglich Eigentum und Bewegung erfordern.

In der vorgeschlagenen Architektur werden programmierbare Token an einer gemeinsamen Smart Contract Adresse gehalten, während das Eigentum über Stake Credentials repräsentiert wird. Ein On Chain Register verknüpft jede Token Policy mit ihren Transferregeln, der Emissionslogik und gegebenenfalls autorisierten Drittparteikontrollen.

Wallets müssten Stake Credentials auflösen, um Salden korrekt anzuzeigen. Dezentrale Börsen, Indexer, Explorer und andere Anwendungen müssten ebenfalls den zusätzlichen Validierungsprozess unterstützen, bevor Nutzer über die bestehende Cardano Infrastruktur mit programmierbaren Token interagieren könnten.

Aiken und Plutarch bieten unterschiedliche Entwicklungsansätze, kompilieren jedoch in dasselbe On Chain Codeformat. Cardanos Entwicklerdokumentation stellt Aiken als leicht zugänglichen Einstieg mit integriertem Testing und einer zweckgebundenen Syntax dar. Plutarch ist eine in Haskell eingebettete Sprache, die Entwicklern eine detailliertere Kontrolle über generierten Code und Ausführungskosten gibt.

DiSarro verfasste CIP-143, Interoperable Programmable Tokens, und arbeitete mit dem Input Output Team an der ursprünglichen Plutarch Referenzimplementierung. Das Repository der Cardano Foundation führt aus, dass die aktuellen Aiken Validatoren aus jener Implementierung migriert und für das breitere CIP-113 Framework angepasst wurden.

Seine direkte Beteiligung an der ursprünglichen Architektur und Codebasis verortet den neuen Benchmark Vergleich innerhalb der Entwicklungsgeschichte des Projekts. CIP-143 ist nun als inaktiv markiert, nachdem es in den Kandidaten CIP-113 aufgenommen wurde, der sich weiterhin in der Last Check Review Phase der CIP Editoren befindet.

Zwei gemeldete Schwachstellen warten auf technische Offenlegung

DiSarro sagte, seine Überprüfung der Aiken Implementierung habe zwei kritische Schwachstellen aufgedeckt, die während des Audit Prozesses übersehen wurden. Sein Thread nannte weder den betroffenen Code noch mögliche Angriffspfade, potenzielle Auswirkungen oder den Stand der Behebung.

Das Repository enthält bereits öffentliche Feststellungen aus dem ersten Audit, darunter zwei geschlossene Issues mit der Einstufung kritisch. Issue 56 beschrieb einen Pfad, über den neu gemintete Token während einer Drittparteiaktion der programmierbaren Verwahrung entkommen konnten. Issue 64 befasste sich mit der möglichen Kontamination nicht zusammenhängender UTxOs durch dieselbe administrative Funktion.

Diese Feststellungen wurden während des ersten Audits gemeldet und können ohne weitere technische Offenlegung nicht als die zwei Schwachstellen identifiziert werden, deren Auffinden DiSarro später meldete.

Auch in der CIP-113 Review Diskussion wurden Sicherheitsbedenken geäußert. Ein Mitwirkender sagte am 20. Juli, dass mehrere Schwachstellen mit hoher Schwere übersehen worden seien und dass einige vorgeschlagene Verbesserungen der Nutzbarkeit zusätzliche Sicherheitsprobleme einführten. Während der anschließenden CIP Review waren sich die Teilnehmenden einig, dass der nächste Schritt ein umfassenderes Audit beinhalten sollte, während der Vorschlag im Status Last Check verbleibt.

Das Repository der Cardano Foundation führt aus, dass die Feststellungen aus dem ersten Audit und einem anschließenden Re Audit im Main Branch behoben wurden. Der endgültige Audit Bericht ist jedoch weiterhin unveröffentlicht, und das Repository stuft die Implementierung als ungeeignet für den produktiven Einsatz mit realen Assets ein, bis der Bericht, breiteres Testing und weitere Expertenreviews abgeschlossen sind.

Bevor die CIP-113 Implementierung in Richtung Einsätze mit realen Assets voranschreiten kann, stehen drei konkrete Ergebnisse aus: die Veröffentlichung des endgültigen Audit Berichts, die Offenlegung und Behebung der von DiSarro gemeldeten zwei Schwachstellen sowie der Abschluss der im CIP Prozess angeforderten breiteren Sicherheitsüberprüfung. Diese Ergebnisse werden festlegen, welche Änderungen an Code und Spezifikation aufgenommen werden, bevor der Vorschlag gemergt wird und die Implementierung für den produktiven Einsatz in Betracht gezogen wird.