Veröffentlichung von Securify v2.0 – ChainSecurity

Der Code folgt dem statischen Zuweisungsformular (Single Static Assignment Form, SSA) und weist das Ergebnis jeder Operation einer neuen Variablen zu (gekennzeichnet durch das Etikett der Anweisung). Der Code ist in mehrere Basisblöcke unterteilt. BLOCK00 entspricht der Definition der Funktion inc und BLOCK01 der Definition der Hauptfunktion. Variablen werden in Form von Argumenten zwischen den Blöcken übergeben (siehe beschriftete Kanten). Diese Darstellung ist mit einer begrenzten Anzahl von Knotentypen kurz und enthält nur die für die Analyse erforderlichen Informationen. Die IR ist in dem Sinne vollständig, dass jeder Solidity Smart-Vertrag darauf abgebildet werden kann.

2. Höhere Präzision durch Empfindlichkeit vor Ort

Securify v2.0 erzielt eine höhere Präzision durch die Empfindlichkeit der Anrufstelle. Sehen Sie sich das folgende Beispiel an, um eine bessere Vorstellung davon zu bekommen, was die Sensitivität von Websites ist und wie sich dies auf unsere Analyse auswirkt:

Vertrag CallSitesTest {        Zuordnung (Adresse => uint) aMapping;        Funktions-ID (Adresse x) public returns (Adresse) {                return x;        }        Funktion unrestrictedStorage (Adresse arbitraryAddress) external {                adresse a = id (beliebige adresse);                aMapping[a] = 1;        }        Funktion restrictedStorage (Adresse arbitraryAddress) external {                Adresse b = id (msg.sender);                aMapping[b] = 1;        }}

Im obigen Beispiel funktioniert uneingeschränkte Speicherung und restrictedStorage Akzeptieren Sie eine beliebige Adresse als Argument vom Benutzer. Beachten Sie diese Funktion uneingeschränkte Speicherung ermöglicht es jedem, an eine beliebige Stelle im Speicher zu schreiben, während die Funktion ausgeführt wird restrictedStorage erlaubt einem Benutzer nur zu schreiben aMapping[msg.sender] im Speicher (wo msg.sender ist die Adresse des Benutzers). Um diese Sicherheitsanfälligkeit zu identifizieren, kennzeichnet Securify v2.0 vom Benutzer bereitgestellte Werte als nicht vertrauenswürdig (in diesem Beispiel sind sie fehlerhaft) beliebigeAdresse) und verteilt das Tag entlang des Abhängigkeitsdiagramms des Programms. Eine genaue Analyse würde feststellen, dass es sich bei der Adresse um eine nicht vertrauenswürdige Berichtsfunktion handelt uneingeschränkte Speicherung als anfällig, während Adresse b ist vertrauenswürdig, Berichtsfunktion restrictedStorage so sicher.

Die erste Version von Securify verwendet eine Analyse der Unempfindlichkeit gegenüber Anrufen, die den Rückgabewert der Funktion kennzeichnet Ich würde als nicht vertrauenswürdig, weil es den Wert von zurückgibt beliebigeAdresse wenn funktion Ich würde wird von der Funktion aufgerufen uneingeschränkte Speicherung. Insbesondere unterscheidet die Analyse nicht, ob die Funktion Ich würde wird von der Funktion aufgerufen uneingeschränkte Speicherung oder Funktion restrictedStorage. Infolge dieser Ungenauigkeit gibt die Analyse die restrictedStorage fungieren auch als anfällig.

Im Gegensatz dazu unterscheidet Securify v2.0, ob die Funktions-ID von der Funktion aufgerufen wird uneingeschränkte Speicherung oder restrictedStorage (daher der Name Call-Site-sensitive). Die zusätzliche Genauigkeit identifiziert diese Adresse korrekt b ist nicht unzuverlässig und wiederum die Funktion restrictedStorage ist korrekt als sicher markiert.

3. Verbesserte Skalierbarkeit durch vollständig deklarative Analyse

Die erste Version von Securify implementiert tiefere Schwachstellenprüfungen in einer Kombination aus Java und Datalog. Dies verlangsamt die Analyse, da alle Datenprotokoll-Zwischenergebnisse an Java übergeben werden müssen.

Im Gegensatz dazu ist die Analyse von Securify v2.0 vollständig deklarativ und in Datalog implementiert. Dies verbessert die Leistung und Skalierbarkeit der Analyse erheblich. Darüber hinaus verbessert die vollständig deklarative Analyse die Wartung und Erweiterbarkeit von Securify, da die deklarativen Muster einfacher zu spezifizieren sind.

4. Höhere Schwachstellenabdeckung

Securify v2.0 unterstützt 37 bekannte Schwachstellenmuster. Es klassifiziert sie in fünf Schweregrade: kritisch, hoch, Mittel, niedrig, und die Info. Ähnlich wie in der ersten Version des Tools werden in Securify v2.0 Verstöße gemeldet, bei denen es sich garantiert um Verhalten handelt, das gegen eine bestimmte Sicherheitseigenschaft verstößt, und Warnungen, bei denen es sich um Verhalten handelt, das möglicherweise gegen die Sicherheitseigenschaft verstößt.

Der einfachste Weg, Security v2.0 mit seinem Docker-Image wie folgt zu verwenden:

docker run -it -v `pwd`: / share securify /share/myContract.sol

Eine alternative Methode zum Installieren von Securify v2.0 als Python-Paket gemäß den Anweisungen auf GitHub:

myContract.sol sichern

Zusätzlich zur Analyse eines Solidity-Vertrags kann Securify v2.0 jeden auf Etherscan.io verfügbaren Vertrag analysieren:

Verbriefung -b  - key /path/to/api_key.txt

Benutzer können mit dem Argument -i steuern, welche Schweregrade von Securify gemeldet werden sollen:

myContract.sol -i CRITICAL HIGH sichern

Darüber hinaus können Benutzer mit dem Argument -p angeben, welche Sicherheitsanfälligkeit überprüft werden soll:

Sichern Sie myContract.sol -p LockedEther

Weitere Hilfe finden Sie in der README-Anleitung von GitHub.

Securify v2.0 unterstützt die folgende Liste von Sicherheitsanfälligkeiten.

| ---- | ----------------------------------- | --------- | --------- |
| ID | Mustername | Schweregrad | SWC ID | 
| ---- | ----------------------------------- | --------- | --------- |
| 1 | TODAmount | Kritisch | SWC-114 |
| 2 | TODReceiver | Kritisch | SWC-114 |
| 3 | TODTransfer | Kritisch | SWC-114 |
| 4 | Uneingeschränktes Schreiben | Kritisch | SWC-124 | 
| 5 | RightToLeftOverride | Hoch | SWC-130 |
| 6 | ShadowedStateVariable | Hoch | SWC-119 | 
| 7 | Uneingeschränkte Selbstzerstörung Hoch | SWC-106 |
| 8 | UninitializedStateVariable | Hoch | SWC-109 |
| 9 | Nicht initialisierter Speicher | Hoch | SWC-109 |
| 10 | UnrestrictedDelegateCall | Hoch | SWC-112 |
| 11 | DAO | Hoch | SWC-107 |
| 12 | ERC20Interface | Mittel | - |
| 13 | ERC721Interface | Mittel | - |
| 14 | IncorrectEquality | Mittel | SWC-132 |
| 15 | LockedEther | Mittel | - |
| 16 | WiedereintrittNoETH | Mittel | SWC-107 |
| 17 | TxOrigin | Mittel | SWC-115 |
| 18 | UnhandledException | Mittel | - |
| 19 | UneingeschränkterAndererFluss | Mittel | SWC-105 |
| 20 | UninitializedLocal | Mittel | SWC-109 |
| 21 | UnbenutztRückgabe | Mittel | SWC-104 |
| 22 | ShadowedBuiltin | Niedrig | - |
| 23 | ShadowedLocalVariable | Niedrig | - |
| 24 | CallToDefaultConstructor | Niedrig | - |
| 25 | CallInLoop | Niedrig | SWC-104 |
| 26 | ReentrancyBenign | Niedrig | SWC-107 |
| 27 | Zeitstempel | Niedrig | SWC-116 |
| 28 | AssemblyUsage | Info | - |
| 29 | ERC20Indexed | Info | - |
| 30 | LowLevelCalls | Info | - |
| 31 | Namenskonvention | Info | - |
| 32 | SolcVersion | Info | SWC-103 |
| 33 | UnusedStateVariable | Info | - |
| 34 | TooManyDigits | Info | - |
| 35 | ConstableStates | Info | - |
| 36 | ExternalFunctions | Info | - | 
| 37 | StateVariablesDefaultVisibility | Info | SWC-108 |
| ---- | ----------------------------------- | --------- | --------- |

Die folgenden SWC-Schwachstellen gelten nicht für Solidity-Verträge mit Pragma> = 0,8 und werden daher von Securify v2.0 nicht überprüft:

• SWC-118 (falscher Konstruktorname)
• SWC-129 (Verwendung von + =)

Securify v2.0 ist auf GitHub unter https://github.com/eth-sri/securify2 verfügbar.

Um einen Beitrag zu leisten, melden Sie bitte alle Probleme und Fehler, auf die Sie bei der Verwendung des Tools gestoßen sind.

Die folgenden Personen haben zu Securify v2.0 beigetragen:

Das Team dankt auch der Ethereum Foundation, die die Entwicklung von Securify v2.0 teilweise finanziert hat.