JPWO2022078632A5 - - Google Patents

Description

According to an embodiment of the present invention, the step of performing the enrichment process may include a write-state-analysis. The write-state-analysis may include collecting all statements that change state variables of the smart contract and assigning a writes-state-label to the collected statements and their surrounding functions. The write-state-analysis may further include collecting all internal function calls that call functions that update/write state variables and assigning a writes-state-label to the collected internal function calls and their surrounding functions. Thus, it is possible to collect appropriate information to be efficiently applied and used in the vulnerability detection process.

According to an embodiment of the present invention, the step of performing the vulnerability detection process may include querying the code property graph for the statement s _w that writes the state and the function f that surrounds it . Then, taking into account the control flow of the function f, the code property graph may be searched for c _e that transitively leads from the foreign function call c _e to s _w . The state variables s v handled by s _w are also captured. If such a pattern is found, the code property graph may also be queried in the vulnerability detection process for all functions f _c that belong to the smart contract and write to s v. Thus, reentrant vulnerabilities may be efficiently detected. To this end, a reentrant vulnerability pattern may be searched for, which includes the state variable s _v , the statement s _w that writes to the state variable s v , the function f that surrounds the statement s _w , c _e that transitively leads from the foreign function call c e to s _w considering the control flow of f, and a set of cross functions f _c that write to s v .

According to an embodiment of the present invention, during vulnerability detection, the code property graph may be queried for the state-writing statement s _w and the surrounding function f. Instead of external calls, the generation-based reentrancy detection may search for c _c that transitively lead to s _w from the constructor call c _c given the control flow of f. The CPG-based analysis allows to analyze the constructor being called. In this way, the vulnerability may be reported only if the constructor contains an external call. This is valid because reentrancy cannot occur without an external call. If the constructor calls an external function, the control property graph may be queried again for all functions that belong to the same contract and also write to s v. Thus, reentrancy vulnerabilities can be detected efficiently.

After labeling all function calls, the HCC labels the functions that contain them with ContainsDelegateCall, ContainsExternalCall, and ContainsConstructorCall, where appropriate. Note that the HCC iterates over all function calls in the CPG, and that the functions surrounding those function calls may be part of another contract. This means that a function called by a Constructorcall is either subject to this analysis or does not contain the function call.

In the first analysis step, HCC collects all statements that modify the state variables of a contract. The collected statements and their surrounding functions are then labeled with WritesState, and edges are added to the state variables they handle. These edges are labeled with WRITES.

In the second step of the write state analysis, the HCC collects all internal function calls that call functions that update the contract state. These calls and the functions surrounding them receive labels and edges similar to the above statement, but this second step is repeated until no new labels are added to the CPG.

Reentrancy detection: Reentrancy vulnerability detection may be performed as follows: First, HCC queries the CPG for a state-writing statement s _w and its surrounding functions f. Then, HCC searches for c _e that transitively lead to s _w from an external call c _e given the control flow of f. HCC also captures state variables s v handled by s _w . If such a pattern is found, HCC queries the CPG for all functions f _c belonging to the same contract that also write to s v. This approach works for classical reentrancy as well as cross-function reentrancy and representative case (ii) reentrancy.

Creation-based reentrancy detection in HCC may be performed much like the basic detection described above. The CPG is queried for a statement s _w that writes state and for the function f that surrounds it . Instead of external calls, creation-based reentrancy detection searches for c _c that transitively lead to s _w from a constructor call c _c given the control flow of f. However, the CPG-based analysis allows HCC to analyze the constructor being called. In this way, if a constructor contains an external call, HCC will only report this vulnerability. This is valid because reentrancy cannot occur without external calls. If the constructor calls an external function, HCC again queries the CPG for all functions that belong to the same contract and also write to sv.

Recall that reentrancy consists of a state variable sv, a statement _sw that writes to this state variable, a foreign function call _ce , a surrounding function f, and a set of cross functions _fc that also write to sv. As a first step, HCC creates a lock variable (l _sv ) for sv as a state variable. This involves checking whether sv already has a lock variable. The type of the variable l _sv depends on the type of sv itself, e.g., if sv has a basic type like uint256 then l _sv will be of type Boolean, but for mapping types only the type of the value will be of type Boolean.

Claims (14)

1. A computer-implemented method for supporting smart contracts in a blockchain network, comprising:
translating a source code of the smart contract into an abstract syntax tree model;
generating a code property graph based on the abstract syntax tree model;
performing an augmentation process to augment the code property graph using information inferable from the abstract syntax tree model;
performing a vulnerability detection process, wherein the code property graph is examined for one or more predefined vulnerability patterns to find one or more predefined vulnerabilities;
performing a vulnerability patching process, in which one or more patches are applied to fix vulnerabilities found in the vulnerability detection process, and the patches are inserted into the code property graph to generate a patched code property graph; and performing the enrichment process includes invocation analysis, the invocation analysis comprising:
iterating over function call representations in the code property graph;
assigning a call label to each external function call;
4. A computer-implemented method comprising : The method of claim 1, wherein the blockchain network is a decentralized network having nodes, and the blockchain enables the nodes to engage in transactions with each other through the use of cryptographically secure signatures. The method of claim 1 or 2, wherein whenever a transaction is sent to the address of the smart contract, the smart contract is triggered and executed in a virtual machine by a node that validates and adds the transaction to the blockchain. The method of any one of claims 1 to 3, wherein the code property graph comprises a combined representation of a control flow graph, a data flow graph and/or a dominator tree. The step of performing the enrichment process includes a contains-call-analysis,
analyzing sub-expressions of statements in the code property graph to find function calls;
and assigning a call label to each statement having an external function call. The step of performing the enrichment process includes write-state-analysis,
collecting statements that modify state variables of a smart contract;
assigning a writes-state-label to the collected statements and their surrounding functions;
collecting internal function calls that call functions that update/write state variables;
and assigning a writes-state - label to the collected internal function calls and their surrounding functions. The method of any one of claims 1 to 6 , wherein the vulnerability pattern is associated with a predefined vulnerability, the predefined vulnerability may comprise a reentrancy, an integer overflow bug and/or an integer underflow bug. 8. The method of claim 1 , wherein the vulnerability pattern is expressed in the form of a subgraph, and the step of performing the vulnerability detection process comprises searching a subgraph within a code property graph of the smart contract. The step of performing the vulnerability detection process includes:
Querying a code property graph for state-writing statements s _w and their surrounding functions f;
searching for a c _e that transitionally leads from a foreign function call c _e to s _w by considering the control flow of a function f;
taking in the state variables sv handled by s _w ;
9. The method of claim 1, further comprising: querying a code property graph for all functions f _c that belong to the smart contract and write to sv. The step of performing the vulnerability detection process includes:
Querying a code property graph for state-writing statements s _w and their surrounding functions f;
Considering the control flow of a function f, there are steps of retrieving a constructor call c _c that transitively passes from a constructor call c c to s _w and invokes a foreign function call c _{e ;}
taking in the state variables sv handled by s _w ;
10. The method of claim 1, further comprising: querying a code property graph for all functions f _c that belong to the smart contract and write to sv. executing the vulnerability patching process to apply a patch,
providing a lock variable l _sv of sv as a state variable;
generating assignment statements that set the state of a lock_l _sv , where a lock statement lock_l _sv sets the value of the state to true and an unlock statement unlock_l _sv sets the value of the state to false;
and modifying the control flow of function f such that the lock statement and the foreign function call c _e , or the constructor call c _c and the unlock statement, immediately follow each other: lock_l _sv → c _e , or c _c → unlock_l _sv . The method of claim 1 , wherein the patch is created specifically for the one or more vulnerability patterns. 13. The method of any one of claims 1 to 12 , wherein the patched code property graph is traversed to generate new source code for the smart contract that incorporates the one or more applied patches. A computer system for supporting smart contracts in a blockchain network, the computer system comprising a storage device and one or more processors configured to execute, alone or in combination, a method, in particular a method according to any one of claims 1 to 13 , the method comprising:
translating a source code of the smart contract into an abstract syntax tree model;
generating a code property graph based on the abstract syntax tree model;
performing an augmentation process to augment the code property graph using information inferable from the abstract syntax tree model;
performing a vulnerability detection process, wherein the code property graph is examined for one or more predefined vulnerability patterns to find one or more predefined vulnerabilities;
and performing a vulnerability patching process, wherein one or more patches are applied to fix vulnerabilities found in the vulnerability detection process, and the patches are inserted into the code property graph to generate a patched code property graph.