Smart contract vulnerability detection method and system based on taint analysis

Abstract

The present application relates to the field of vulnerability detection, in particular to a smart contract vulnerability detection method and system based on taint analysis, control flow analysis is performed on the EVM bytecode of the smart contract, key operation instructions in the control flow graph and key parameters of each key operation instruction are extracted; based on the defined access permission control condition, the access permission control of the EVM bytecode is identified, and the access permission control check and the access permission control state variable are identified; then based on the key operation instruction, the access permission control state variable sets the taint sink, carries out the taint analysis, generates the constraint condition of the taint flow path through the symbolic execution, efficiently and accurately distinguishes the expected normal operation in the smart contract from the real security vulnerability, takes the inverse of the constraint condition to obtain the negative constraint condition, further solves the negative constraint condition, significantly improves the accuracy and reliability of the smart contract security analysis, and provides strong support for the security protection of the smart contract.

Description

Technical Field

[0001] The present invention relates to the field of vulnerability detection technology, and specifically to a smart contract vulnerability detection method and system based on taint analysis. Background Art

[0002] Smart contracts are computer programs that automatically execute, control, or record legal events and actions. They run on the Ethereum blockchain and can execute complex transactions and agreements without the need for an intermediary. However, once a smart contract is deployed on the blockchain, its code cannot be modified, and any potential security vulnerabilities could be exploited maliciously, leading to financial loss or other serious consequences.

[0003] Programming languages ​​like Solidity, used to write smart contracts, weren't designed with security vulnerabilities related to access control in mind. Smart contract developers are left to set access permissions based on their own judgment and experience, leading to numerous access control vulnerabilities in smart contracts. These vulnerabilities could allow unauthorized users to access or manipulate critical functions within the contract, harming user interests and negatively impacting the stability and credibility of the Ethereum ecosystem.

[0004] Static analysis plays an important role in identifying access control vulnerabilities. However, due to the lack of clear access control policy specifications, accurately identifying access control checks is difficult. Secondly, smart contracts may contain code patterns that appear to be vulnerabilities but are actually part of the contract's functionality. Due to the lack of specification for contract access control, static analysis can be difficult to distinguish these patterns from true vulnerabilities.

[0005] In addition, some existing methods for detecting access control vulnerabilities rely on predefined rules to identify access control checks, assuming that contracts are written in a specific format and that the compiler always generates specific bytecode patterns for these checks. However, these predefined rules have poor generalization capabilities and lack accuracy, making them prone to false positives. Others analyze contract transaction history on the blockchain to identify access control roles and thus permission errors in smart contracts. In reality, not all contract functions are called and generate transactions. For example, the function that deletes a smart contract is only triggered under specific circumstances. These existing methods do not focus on access control vulnerabilities across the entire contract caused by weak or missing access control. Instead, they primarily analyze the lack of access control in specific code statements based on predefined access control patterns. Summary of the Invention

[0006] In order to solve the above problems raised by the background technology, the present invention provides a smart contract vulnerability detection method and system based on taint analysis.

[0007] The technical solutions of the present invention are as follows:

[0008] A smart contract vulnerability detection method based on taint analysis includes the following steps:

[0009] S1. Compile the smart contract into EVM bytecode, perform control flow analysis on the EVM bytecode, obtain a control flow graph, and obtain several key operation instructions in the control flow graph;

[0010] Extract the key parameters of each key operation instruction, slice the key parameters backward on the control flow graph, obtain slices containing instructions directly or indirectly controlled by the attacker, and construct a slice set;

[0011] S2. Identify access control permissions for the EVM bytecode based on defined access control conditions: Perform backward data flow analysis on each conditional statement in the EVM bytecode, identify conditional statements containing instructions in the slice set as access control checks, and construct a condition set based on all access control checks.

[0012] Identify the storage location accessed by the access control check as an access control state variable;

[0013] S3. Set the user input containing the execution operation as the taint source, set the address parameter of the key operation instruction and the SSTORE instruction that writes the access control state variable as the taint sink, perform taint analysis on the control flow graph based on the taint source and taint sink, and mark the contaminated operand as tainted;

[0014] S4. Perform symbolic execution on the taint flow path where the taint flows to the access control state variable, generate constraints for the taint flow path, solve the constraints, and if a value that satisfies the constraints can be found, negate the constraints to obtain negated constraints.

[0015] The negated constraint condition is further solved. If a value that makes the negated constraint condition true can be found, the operand corresponding to the taint is marked as expected normal behavior. If not found, the operand corresponding to the taint is marked as an access permission control vulnerability, and the vulnerability detection result is obtained.

[0016] Specifically, the access permission control conditions defined in S2 are:

[0017] Define access control check: If there is a conditional statement C in the EVM bytecode, and caller A passes the verification of conditional statement C, then caller A can execute the code controlled by conditional statement C. This conditional statement C is the access control check;

[0018] Define access control state variables: If there is an access control check C in the EVM bytecode, the value V in the storage data item D can be compared with the caller A, or the access control check C can be calculated using the value V loaded from the storage data item D, then the storage data item D is the access control state variable;

[0019] Defined authorized user: If in the EVM bytecode, the access control state variable D contains the address of caller A, then caller A is an authorized user protected by the defined access control check C.

[0020] Furthermore, S2 also includes excluding non-access right control checks that do not meet the access right control check judgment condition from the condition set, and the access right control check judgment condition is:

[0021] If there is no data mapping relationship in the conditional statement, or if there is a data mapping relationship in the conditional statement and the state variable used in the conditional statement stores a Boolean value, the condition is an access control check.

[0022] The key operation instructions in S1 include CALL, CALLCODE, DELEGATECALL and SELFDESTRUCT instructions.

[0023] The S1 obtains a slice containing instructions directly or indirectly controlled by the attacker. The instructions directly controlled by the attacker include: ORIGIN, CALLER, CALLVALUE, CALLDATALOAD, CALLDATASIZE, CALLDATACOPY, and the instructions indirectly controlled by the attacker include: SLOAD, MLOAD.

[0024] The key parameters in S1 include: target address, amount of currency to be sent, and input data.

[0025] In S3, taint analysis is performed on the control flow graph based on the taint source and taint sink, and the polluted operands are marked as tainted. Specifically:

[0026] Backward slicing of the taint sink is performed on the control flow graph to obtain all path fragments that can reach the taint sink. Then, starting from the taint source, along the execution order of the path fragments, the tainted operands are marked as tainted using the TaintAnalyse function.

[0027] Further, in the taint analysis process, further comprising: starting from each taint source, traversing the control flow graph to find all paths of the SSTORE instruction flowing to the write storage slot, if the storage slot is contaminated by the taint and the taint source is not the storage slot itself or the taint source has been marked as taint, marking the storage slot as taint, and recording the address of the SSTORE instruction writing to the storage slot.

[0028] The constraint condition and the negative constraint condition in S4 are solved by using a Z3 solver.

[0029] The application further provides an intelligent contract vulnerability detection system based on taint analysis, comprising:

[0030] The static analysis module is configured to compile the intelligent contract into EVM bytecode, perform control flow analysis on the EVM bytecode to obtain a control flow graph, and acquire a plurality of key operation instructions in the control flow graph; extract key parameters of each key operation instruction, perform backward slicing on the key parameters on the control flow graph to obtain a slice set containing instructions directly or indirectly controlled by an attacker; and construct the slice set.

[0031] The access permission control identification module is configured to perform access permission control identification on the EVM bytecode based on the defined access permission control condition: perform backward data flow analysis on each conditional statement in the EVM bytecode, identify conditional statements containing instructions in the slice set as access permission control checks, construct a condition set based on all access permission control checks; and identify storage locations accessed by the access permission control checks as access permission control state variables.

[0032] The taint analysis module is configured to set user input containing execution operations as a taint source, set address parameters of the key operation instructions and SSTORE instructions writing to the access permission control state variables as taint sinks, perform taint analysis on the control flow graph based on the taint source and the taint sink, and mark a contaminated operand as taint.

[0033] The vulnerability detection module is configured to perform symbolic execution on a taint flow path where taint flows to the access permission control state variable, generate a constraint condition of the taint flow path, solve the constraint condition, take the complement of the constraint condition if a value making the constraint condition true can be found, obtain a negative constraint condition, further solve the negative constraint condition, and mark an operand corresponding to the taint as expected normal behavior if a value making the negative constraint condition true can be found, or mark the operand corresponding to the taint as an access permission control vulnerability if a value making the negative constraint condition true cannot be found, to obtain a vulnerability detection result.

[0034] The application has the following beneficial effects:

[0035] 1. The present invention provides a smart contract vulnerability detection method based on taint analysis. By performing control flow analysis on the EVM bytecode of the smart contract, key information is screened, including key operation instructions and key parameters. In combination with the taint analysis method, the detection of access control vulnerabilities is transformed into a taint analysis problem. This method does not rely on predefined access control modes or existing transaction records. It can significantly improve the accuracy and reliability of smart contract security analysis, providing strong support for the security of smart contracts.

[0036] 2. The present invention generates constraints for the taint flow path through symbolic execution, efficiently and accurately distinguishing expected normal operations in smart contracts from real security vulnerabilities, negating the constraints to obtain negated constraints, and further solving the negated constraints to distinguish whether unauthorized users can obtain access control permissions to the contract in a manner that conforms to the expected functional logic under specific circumstances. Through symbolic execution analysis, potential expected normal behaviors are distinguished from clear access control vulnerabilities, thereby reducing the false alarm rate of vulnerability detection. DETAILED DESCRIPTION

[0037] Exemplary embodiments of the present disclosure will be described in more detail below with reference to examples.

[0038] Example

[0039] This embodiment provides a smart contract vulnerability detection method based on taint analysis, including the following steps:

[0040] S1. Compile the smart contract into EVM bytecode, perform control flow analysis on the EVM bytecode, obtain a control flow graph, and obtain several key operation instructions in the control flow graph;

[0041] Extract the key parameters of each key operation instruction, slice the key parameters backward on the control flow graph, obtain the slices containing the instructions directly or indirectly controlled by the attacker, and construct a slice set.

[0042] This invention primarily detects access control vulnerabilities, which fall into two main categories. The first category stems from weak access control checks, allowing attackers to bypass them. We define this category as "access control violations." The second category stems from the lack of necessary access control, which we term "access control missing." In addition, normal contract operations designed by developers are defined as "expected normal operations."

[0043] Table 1 illustrates examples of access control violations. The access control vulnerability in the smart contract (BAFCToken) in Table 1 is primarily due to a naming error in the constructor UBSecToken. It should have been named the contract name BAFCToken to ensure that its constructor is executed only once upon deployment. Due to this naming error, the UBSecToken function can still be called after the smart contract is deployed, allowing anyone to set themselves as the owner of the smart contract, thereby bypassing the access control check implemented by the onlyOwner modifier. Furthermore, since the owner variable can be arbitrarily changed, attackers can exploit this to freeze and unfreeze any account, including their own, bypassing the check implemented by the unFrozenAccount modifier. Furthermore, the incorrect variable name in the switchLiquidity function may prevent the function from executing correctly. The transfer function, lacking the onlyTransferable modifier, may have lax access control, increasing the risk of malicious exploitation of the smart contract. These vulnerabilities collectively compromise the access control mechanism of the smart contract, allowing unauthorized users to perform critical operations such as freezing accounts and switching liquidity states.

[0044] Table 1 Access control violations

[0045]

[0046] The lack of access control is illustrated in the example in Table 2. The self-destruct instruction in line 3 of the code in Table 2 removes the contract from the blockchain and sends any remaining balance in the smart contract to the address provided as a parameter to the instruction (msg.sender). Therefore, only authorized users (e.g., the owner) should be allowed to call the remContract function. Furthermore, the self-destruct instruction's parameters should not be set by unauthorized users.

[0047] Table 2 Access control missing

[0048]

[0049] For expected normal operation, as shown in the example of Table 3. In certain situations, a smart contract can be intentionally designed by the developer to allow users to modify the state variables related to access control when certain conditions are met. These cases need to be distinguished from real exploitable vulnerabilities to identify the real expected behavior. We define this kind of case as expected normal operation. Take the code snippet in Table 3 as an example, the changeNamesymb function has an access control check in line 4 to ensure that only the owner of the contract (the owner's address is stored in the owner state variable) can call this function. At the same time, the contract also contains a changeOwner function that allows users to buy the ownership of the contract. Most existing tools will mistakenly report the changeOwner function as a vulnerability when looking for untrusted write operations to access control data, because the function allows anyone to change the owner state variable. In fact, this is a pre-set functional behavior: the designer of the contract intentionally allows users to transfer ownership by paying a certain amount. When the corresponding funds are transferred to the current owner's account, the owner state variable will be updated to the buyer's address.

[0050]

[0051] Table 3 Expected normal operation

[0052] In step S1, control flow analysis is performed on the EVM bytecode to obtain a control flow graph, and a plurality of key operation instructions in the control flow graph are obtained, the plurality of key operation instructions including CALL, CALLCODE, DELEGATECALL, and SELFDESTRUCT instructions.

[0053] The main function of the CALL instruction and the CALLCODE instruction is to accurately send a specific amount of money to the target contract or the specified address. The function of the SELFDESTRUCT instruction is to permanently destroy the smart contract. However, if the parameter of the instruction can be manipulated by the attacker, a very dangerous situation will occur, the smart contract will send its balance to the attacker, resulting in illegal transfer of assets. The DELEGATECALL instruction has a unique operation mechanism, which replaces the code of the called smart contract with the code of the current smart contract. In this process, the called smart contract can successfully access and operate the storage space of the current smart contract, and has complete consistency with the current smart contract in terms of permissions and access control. This feature also provides an opportunity for attackers to implant malicious code into the smart contract using the DELEGATECALL instruction, thereby posing a serious threat to the security of the smart contract.

[0054] Then the key parameters of each key operation instruction are extracted, including: target address, sent currency amount, input data. Further, the key parameters are backward sliced on the control flow graph to obtain a slice set containing instructions directly or indirectly controlled by the attacker. Among them, the instructions directly controlled by the attacker include: ORIGIN, CALLER, CALLVALUE, CALLDATALOAD, CALLDATASIZE, CALLDATACOPY, and the instructions indirectly controlled by the attacker include: SLOAD, MLOAD.

[0055] In addition, the SSTORE instruction is responsible for storing the given key-value pair into the persistent state of the smart contract, and the corresponding SLOAD instruction can load the value of the specified key from the state storage of the smart contract. However, this process also has security risks. If the transfer amount of the smart contract is read through the SLOAD instruction and can be modified by the SSTORE instruction, the attacker may interfere with or even control the transfer behavior of the smart contract by deliberately modifying the state variable, thereby disrupting the normal operation logic and fund flow order of the smart contract.

[0056] S2, access permission control identification of EVM bytecode based on defined access permission control conditions: backward data flow analysis is performed on each conditional statement in the EVM bytecode, and the conditional statement containing instructions in the slice set is identified as an access permission control check, and a condition set is constructed based on all access permission control checks;

[0057] The storage location accessed by the access permission control check is identified as an access permission control state variable.

[0058] In step S2, first, the access permission control identification of EVM bytecode based on the defined access permission control conditions is performed, and the defined access permission control conditions are as follows:

[0059] Define access permission control check: if there is a conditional statement C in the EVM bytecode, and the caller A passes the verification of the conditional statement C, then the caller A can execute the code controlled by the conditional statement C, and this conditional statement C is an access permission control check;

[0060] Define access permission control state variable: if there is an access permission control check C in the EVM bytecode, the value V in the storage data item D can be compared with the caller A, or the value V loaded from the storage data item D is used to calculate the access permission control check C, then the storage data item D is an access permission control state variable, and the access permission control state variable stores the key information used for access permission control decision;

[0061] Definition of authorized user: If in the EVM bytecode, the access permission control state variable D contains the address of the caller A, then the caller A is the authorized user protected by the defined access permission control check C.

[0062] From the above definition, all access permission control checks have a core function, that is, according to the access permission control state variable representing various authorized users, the caller of the smart contract is verified. In the smart contract, the built-in global variable msg.sender can be used to obtain the contract caller in the source code, and in the bytecode, the caller related mechanism is used to realize it.

[0063] Table 4 Access permission control identification algorithm

[0064]

[0065] Algorithm 1 in Table 4 shows the identification process of access permission control check, which takes the conditional statement in EVM bytecode as input, and takes the access permission control check and the corresponding access permission control state variable as output. For each conditional statement in the smart contract, backward data flow analysis is performed, and if the data flow SLOAD instruction and the CALLER instruction are found, the conditional statement containing the instruction is identified as an access permission control check, and the corresponding storage location (read by SLOAD instruction) is identified as an access permission control state variable.

[0066] Based on all access permission control checks, a condition set is constructed, which may contain non-access permission control checks, which behave similarly to access permission control checks, such as require(balances[msg.sender]>= amount). In order to solve this problem, the conditional statement returned by the backward data flow analysis needs to be further analyzed, and the non-access permission control checks that do not meet the access permission control check judgment condition are excluded from the condition set.

[0067] The access permission control check judgment condition is: if there is no data mapping relationship in the conditional statement (lines 6-7), or there is a data mapping relationship in the conditional statement and the state variable used stores a Boolean value (lines 8-9), then the condition is an access permission control check. The state variable includes: account balance, user permission.

[0068] S3, set the user input containing the execution operation as the source of the stain, set the address parameter of the key operation instruction and the SSTORE instruction writing the access permission control state variable as the sink of the stain, and perform stain analysis on the control flow graph based on the source of the stain and the sink of the stain. The contaminated operands are marked as stains.

[0069] Taint analysis is to determine whether data can propagate from a taint source to a taint sink by studying the data dependency between program variables without executing and modifying the code. The taint source refers to the source that may contain malicious data, and the taint sink is a critical position in the program. If the taint data can reach the taint sink, it may cause security risks.

[0070] In the process of detecting access control vulnerabilities by combining taint analysis, the taint source and the taint sink are set first. The user input containing the execution operation is set as the taint source, which means that the execution operation entering the program from the user input is marked as possibly containing taint from the beginning, so its propagation during program execution needs to be tracked. The address parameter of the critical operation instruction and the SSTORE instruction writing the access control state variable are set as the taint sink. In this embodiment, in addition to the SSTORE instruction, the address parameters of the SELFDESTRUCT and DELEGATECALL instructions are also regarded as the taint sink. This setting is because if the critical position where these instructions are located is affected by data from the taint source, it may cause problems in access control, such as access control violation and access control absence, thus meeting the goal of detecting access control vulnerabilities.

[0071] Table 5 Taint analysis algorithm

[0072]

[0073] Algorithm 2 in Table 5 shows the process of taint analysis for detecting access control vulnerabilities. Based on the taint source and the taint sink, taint analysis is performed on the control flow graph. For each potential taint sink (sink), reverse slicing is performed on the control flow graph to obtain all path segments that can reach the taint sink. Each path segment obtained by reverse slicing may contain taint propagation (lines 1-2). Then, starting from the taint source, the operands that are contaminated are marked as taint along the execution order of the path segment using the TaintAnalyse function.

[0074] In the process of taint analysis, it also includes starting from each taint source, traversing the control flow graph to find all paths leading to the SSTORE instruction writing to the storage slot. If the storage slot is contaminated by taint and the source of the taint is not the storage slot itself or the source of the taint has been marked as taint, the storage slot is marked as taint, and the address of the SSTORE instruction writing to the storage slot is recorded (lines 9-11).

[0075] S4, symbolically execute the taint flow path leading to the access control state variable to which the taint belongs, generate the constraint condition of the taint flow path, and solve the constraint condition. If a value that satisfies the constraint condition can be found, negate the constraint condition to obtain the negated constraint condition;

[0076] Further solving the negative constraint, if a value that makes the negative constraint true is found, the operand corresponding to the stain is marked as expected normal behavior, and if not, the operand corresponding to the stain is marked as access control vulnerability, and the vulnerability detection result is obtained.

[0077] In the analysis of smart contract access control vulnerabilities, simple access control absence does not necessarily mean that there is a vulnerability, because the developer may have adopted other non-access control checks. Specifically, the smart contract code may intentionally allow unauthorized users to operate the access control state variable under certain non-access control conditions. Because there is usually no explicit access control policy, it greatly increases the difficulty of identifying real vulnerabilities. For example, in a specific scenario, unauthorized users can write to the access control state variable owner under the condition of paying a certain amount of money, and traditional static analysis methods are likely to misjudge this as a vulnerability.

[0078] To effectively address this issue, the present application uses a verification method based on symbolic execution, aiming to infer the non-access control checks implemented under these specific conditions, and mark the operands that meet such conditions as expected normal behavior. The idea is that statements that are not subject to traditional access protection mechanisms but operate on access control state variables under certain non-access control conditions are likely to be intentional design by the developer.

[0079] In smart contracts, situations where access control checks are not applied but access control state variables are operated based on other non-access control constraints should generally be considered as intended behavior, i.e., expected normal behavior, and cannot be considered as access control vulnerabilities. A relatively simple method to screen expected normal behavior is to mark any unprotected statement that updates access control data and is protected by non-access control checks as expected normal behavior. However, if this method is used blindly, some actual vulnerabilities may be misjudged as expected normal behavior. For example, when a function initializes the access control state variable operator, the developer fails to correctly set initialized to true in the subsequent code, thus causing a vulnerability. However, if the intended behavior is determined only based on the implemented access control checks, this vulnerability will be incorrectly identified as expected normal behavior.

[0080] In view of this, the present application uses symbolic execution technology to infer the constraint conditions followed when the operation accesses the access permission control state variable, and accurately distinguishes between expected normal behavior and actual vulnerabilities. The reason for choosing the symbolic execution method is that the constraints implemented in the expected normal behavior are relatively few, have high processability, and can be solved with the Z3 solver.

[0081] Specifically, when detecting that the taint flows to the access permission control state variable, the symbolic execution operation is performed on the taint flow path where the taint is located, and then the constraint condition of the taint flowing from the taint source to the access control state variable is generated, and then the feasibility of the taint flow path is verified by using the Z3 solver to solve the constraint condition. If the path is feasible, that is, the Z3 solver can successfully find the value that makes the constraint condition true, then the constraint condition is negated to obtain the negated constraint condition.

[0082] Further, the negated constraint condition is solved using the Z3 solver, and if a value that makes the negated constraint condition true can be found, the operand corresponding to the taint is marked as expected normal behavior, and if not, the operand corresponding to the taint is marked as an access permission control vulnerability, and the vulnerability detection result is obtained.

[0083] As evidenced by a specific example, when it is found that owner is contaminated at a certain line of code, the symbolic execution operation is performed on the taint flow path, and the constraint condition of owner being contaminated is generated. After solving the constraint condition, the synthesized path constraint is!msg.value≥BecomeOwner=2000. Since the path is feasible, the Z3 solver will find a msg.value assignment that satisfies the negated constraint to prove that the original constraint condition is not always true, and if a value that makes the negated constraint condition true can be found, the operand corresponding to the taint is marked as expected normal behavior. The reason for marking the expected normal behavior is that the update operation on the owner state variable is limited by implementing a specific constraint, which is most likely intended by the developer to manage the owner write operation.

[0084] When a solution that makes the negated constraint condition true cannot be found successfully, if the constraint condition depends on a storage variable that is updated in the taint flow path, the Z3 solver will be called again. This step aims to infer the intended behavior that is usually used to initialize the storage variable only once, and then set a specific storage variable to prevent future repeated initialization operations.

[0085] The present application can efficiently and accurately distinguish between expected normal behavior and actual access control vulnerabilities by combining symbolic execution and constraint inference, thereby significantly improving the accuracy and reliability of smart contract security analysis, and providing strong support for the security of smart contracts.

[0086] The present invention also provides a smart contract vulnerability detection system based on taint analysis, comprising:

[0087] Static analysis module: used to compile smart contracts into EVM bytecode, perform control flow analysis on the EVM bytecode to obtain a control flow graph, and obtain several key operation instructions in the control flow graph; extract key parameters of each key operation instruction, perform backward slicing on the key parameters on the control flow graph, obtain slices containing instructions directly or indirectly controlled by the attacker, and construct a slice set;

[0088] Access control identification module: used to identify access control of EVM bytecode based on defined access control conditions: perform backward data flow analysis on each conditional statement in the EVM bytecode, identify the conditional statement containing instructions in the slice set as an access control check, build a condition set based on all access control checks; identify the storage location corresponding to the access control check as an access control state variable;

[0089] Taint analysis module: used to set user input containing execution operations as taint sources, set the address parameters of key operation instructions and the SSTORE instruction that writes access control state variables as taint sinks, perform taint analysis on the control flow graph based on the taint sources and taint sinks, and mark the contaminated operands as tainted;

[0090] Vulnerability detection module: used to perform symbolic execution on the taint flow path where the taint flows to the access control state variable, generate constraints for the taint flow path, solve the constraints, and if a value that makes the constraint true can be found, then the constraint is negated to obtain a negated constraint; further solve the negated constraint, and if a value that makes the negated constraint true can be found, then the operand corresponding to the taint is marked as expected normal behavior; if it cannot be found, then the operand corresponding to the taint is marked as an access control vulnerability, and the vulnerability detection result is obtained.

[0091] Experimental content

[0092] The specific experimental environment settings are shown in Table 6.

[0093] Table 6 Experimental environment

[0094]

[0095] Dataset:

[0096] The present application uses two data sets to evaluate the method. The first data set is a smart contract with vulnerability labels obtained from the data set in SmartBugs, which contains 20 smart contracts with access control vulnerabilities. The second data set is 12000 verified real smart contracts obtained from Etherscan.

[0097] Evaluation indicators:

[0098] In the experiment, three evaluation indicators were collected: precision, recall, and F1 score. In the experiment, we obtained three key measurements: true positives (TP), false positives (FP), and false negatives (FN). Among them, TP represents successfully detected smart contract vulnerabilities, FP represents smart contracts incorrectly labeled as vulnerabilities, and FN represents undetected smart contract vulnerabilities. Based on these three measurements, the precision (P), recall (R), and F1 score (F) can be calculated as follows:

[0099]

[0100]

[0101]

[0102] Experimental results and analysis:

[0103] The method of the present application was compared with four other detection methods: Mythril, SPCon, Slither, and Ethainter on two data sets. Mythril is a symbolic execution detection method, Slither is a smart contract vulnerability detection method using intermediate representation, and SPCon and Ethainter are static analysis methods. Through the first data set, based on the true positive (TP), false positive (FP), and false negative (FN) values, the precision (P), recall (R), and F1 score (F) of the integer overflow vulnerability detection were further calculated. The experimental results of the four detection methods are shown in Table 7. By calculating the precision and recall of each detection method, it can be concluded that the precision, recall, and F1 score of the present application method are the highest.

[0104] Table 7 Comparison of experimental results on the first data set

[0105]

[0106] ​​​It can be seen that the use of Slither and Mythril presents a higher false positive and false negative, and these methods do not conduct in-depth research on the access control vulnerability in the entire contract range caused by weak or missing access control. They mainly rely on predefined access control patterns, focusing on analyzing the lack of access control in specific code statements, and fail to comprehensively cover all relevant vulnerabilities that may exist in the contract. Ethainter reduces the false positive and false negative of detecting vulnerabilities, however, our research finds that the generalization ability of these predefined rules is weak, resulting in the unsatisfactory performance of Ethainter when dealing with a large number of samples. In addition, the predefined patterns of access control checks lack sufficient precision, which can easily cause false positives. This means that in actual application, Ethainter may mistakenly identify some normal behaviors in certain contracts as vulnerabilities, affecting its reliability and effectiveness of detection.

[0107] Due to the diversity and complexity of smart contracts, a single predefined rule is difficult to cover all possible code structures and logic, resulting in challenges in actual vulnerability detection. SPCon mines smart contract permission errors by analyzing the transaction history of the contract on the blockchain to obtain access control roles, which has certain limitations. It assumes that all functions of the analyzed smart contract have transaction records, but in reality, some contract functions may only be called in specific situations, such as functions to delete smart contracts, which may not generate transaction history records. Moreover, SPCon assumes that each transaction is benign and is executed by authorized accounts according to the expected security policy, but this assumption does not hold true for contracts with access control vulnerabilities that are exploited by malicious users. These limitations make it difficult for SPCon to comprehensively cover potential access control issues when identifying permission errors, especially for complex contracts. Its effectiveness in practical application is greatly reduced, and it cannot accurately and completely capture all possible access control vulnerabilities and related risks.

[0108] To further verify the ability of the method of the present application in detecting vulnerabilities in real smart contracts, the method of the present application is applied to 12000 smart contracts obtained from Etherscan, and 3000 smart contracts are extracted from the second dataset for manual inspection. The detection results are compared with Mythril, SPCon, Slither and Ethainter. By manually analyzing the vulnerabilities detected by each detection method, they are classified as true positives (TP), false positives (FP) or false negatives (FN), and the results are shown in Table 8.

[0109] Table 8 Comparison of experimental results on the second dataset

[0110]

[0111] It can be seen that the method of the present application can correctly detect more access permission control vulnerabilities in real-world smart contracts, and the number of false positives and false negatives reported is relatively small.

[0112] In summary, the smart contract vulnerability detection method and system based on taint analysis used by the present application can significantly improve the accuracy and reliability of smart contract security analysis by performing control flow analysis on the EVM bytecode of the smart contract, screening key information, and combining the taint analysis method to convert the detection of access permission control vulnerabilities into a pollution analysis problem. It does not rely on pre-defined access permission control patterns or existing transaction records, and provides strong support for the security of smart contracts. The present application generates constraint conditions for taint flow paths through symbolic execution, efficiently and accurately distinguishes between expected normal operation and real security vulnerabilities in smart contracts, takes the inverse of the constraint conditions to obtain negative constraint conditions, and further solves the negative constraint conditions to distinguish whether unauthorized users can obtain access control permissions of the contract in a specific case. The expected normal behavior and explicit access permission control vulnerabilities are distinguished, reducing the false positive rate of vulnerability detection.

Claims

1. A smart contract vulnerability detection method based on taint analysis, characterized in that: The following steps are involved: S1. Compile the smart contract into EVM bytecode, perform control flow analysis on the EVM bytecode, obtain a control flow graph, and obtain several key operation instructions in the control flow graph; Extract the key parameters of each key operation instruction, slice the key parameters backward on the control flow graph, obtain slices containing instructions directly or indirectly controlled by the attacker, and construct a slice set; S2. Identify access control permissions for the EVM bytecode based on defined access control conditions: Perform backward data flow analysis on each conditional statement in the EVM bytecode, identify conditional statements containing instructions in the slice set as access control checks, and construct a condition set based on all access control checks. Identify the storage location accessed by the access control check as an access control state variable; S3. Set the user input containing the execution operation as the taint source, set the address parameter of the key operation instruction and the SSTORE instruction that writes the access control state variable as the taint sink, perform taint analysis on the control flow graph based on the taint source and taint sink, and mark the contaminated operand as tainted; S4. Perform symbolic execution on the taint flow path where the taint flows to the access control state variable, generate constraints for the taint flow path, solve the constraints, and if a value that satisfies the constraints can be found, negate the constraints to obtain negated constraints. The negated constraint condition is further solved. If a value that makes the negated constraint condition true can be found, the operand corresponding to the taint is marked as expected normal behavior. If not found, the operand corresponding to the taint is marked as an access permission control vulnerability, and the vulnerability detection result is obtained.

2. The smart contract vulnerability detection method based on taint analysis according to claim 1 is characterized in that: The access permission control conditions defined in S2 are specifically: Define access control check: If there is a conditional statement C in the EVM bytecode, and caller A passes the verification of conditional statement C, then caller A can execute the code controlled by conditional statement C. This conditional statement C is the access control check; Define access control state variables: If there is an access control check C in the EVM bytecode, the value V in the storage data item D can be compared with the caller A, or the access control check C can be calculated using the value V loaded from the storage data item D, then the storage data item D is the access control state variable; Defined authorized user: If in the EVM bytecode, the access control state variable D contains the address of caller A, then caller A is an authorized user protected by the defined access control check C.

3. The smart contract vulnerability detection method based on taint analysis according to claim 1 is characterized in that: The step S2 further includes excluding non-access right control checks that do not meet the access right control check judgment conditions from the condition set. The access right control check judgment conditions are: If there is no data mapping relationship in the conditional statement, or if there is a data mapping relationship in the conditional statement and the state variable used in the conditional statement stores a Boolean value, the condition is an access control check.

4. The smart contract vulnerability detection method based on taint analysis according to claim 1 is characterized in that: The key operation instructions in S1 include CALL, CALLCODE, DELEGATECALL and SELFDESTRUCT instructions.

5. The smart contract vulnerability detection method based on taint analysis according to claim 1 is characterized in that: The S1 obtains a slice containing instructions directly or indirectly controlled by the attacker. The instructions directly controlled by the attacker include: ORIGIN, CALLER, CALLVALUE, CALLDATALOAD, CALLDATASIZE, CALLDATACOPY, and the instructions indirectly controlled by the attacker include: SLOAD, MLOAD.

6. The method for detecting smart contract vulnerabilities based on taint analysis according to claim 1, characterized in that: The key parameters in S1 include: target address, amount of currency to be sent, and input data.

7. The method for detecting smart contract vulnerabilities based on taint analysis according to claim 1, characterized in that: In S3, taint analysis is performed on the control flow graph based on the taint source and taint sink, and the polluted operands are marked as tainted. Specifically: Backward slicing of the taint sink is performed on the control flow graph to obtain all path fragments that can reach the taint sink. Then, starting from the taint source, along the execution order of the path fragments, the tainted operands are marked as tainted using the TaintAnalyse function.

8. The method for detecting smart contract vulnerabilities based on taint analysis according to claim 7, characterized in that: The taint analysis process also includes starting from each taint source, traversing the control flow graph to find all paths of SSTORE instructions that flow to the storage slot. If the storage slot is contaminated by the taint and its taint source is not the storage slot itself or the taint source has been marked as tainted, then the storage slot is marked as tainted, and the address of the SSTORE instruction written to the storage slot is recorded.

9. The method for detecting smart contract vulnerabilities based on taint analysis according to claim 1, characterized in that: In S4, the constraints and negated constraints are solved using the Z3 solver.

10. A smart contract vulnerability detection system based on taint analysis, characterized in that: include: Static analysis module: used to compile smart contracts into EVM bytecode, perform control flow analysis on the EVM bytecode to obtain a control flow graph, and obtain several key operation instructions in the control flow graph; extract key parameters of each key operation instruction, perform backward slicing on the key parameters on the control flow graph, obtain slices containing instructions directly or indirectly controlled by the attacker, and construct a slice set; Access control identification module: used to identify access control of EVM bytecode based on defined access control conditions: backward data flow analysis is performed on each conditional statement in the EVM bytecode, conditional statements containing instructions in the slice set are identified as access control checks, and a condition set is constructed based on all access control checks; Identify the storage location accessed by the access control check as an access control state variable; Taint analysis module: used to set user input containing execution operations as taint sources, set the address parameters of key operation instructions and the SSTORE instruction that writes access control state variables as taint sinks, perform taint analysis on the control flow graph based on the taint sources and taint sinks, and mark the contaminated operands as tainted; Vulnerability detection module: used to perform symbolic execution on the taint flow path where the taint flows to the access control state variable, generate constraints for the taint flow path, solve the constraints, and if a value that makes the constraint true can be found, then the constraint is negated to obtain a negated constraint; further solve the negated constraint, and if a value that makes the negated constraint true can be found, then the operand corresponding to the taint is marked as expected normal behavior; if it cannot be found, then the operand corresponding to the taint is marked as an access control vulnerability, and the vulnerability detection result is obtained.

Images