Vulnerability processing method and device for embedded firmware system, equipment and storage medium

Abstract

The invention provides a vulnerability processing method and device for an embedded firmware system, equipment and a storage medium. The method comprises the following steps: determining a front-end keyword from a front-end file of the embedded firmware system; identifying a rear-end file of the embedded firmware system according to the front-end keyword to obtain an identification result; marking input data as taints, marking keyword entry points in the recognition result as source points of the taints, determining a program calling relationship by utilizing alias analysis based on a structured symbol expression, and determining a vulnerability path of the taints from the source points to a sink according to the program calling relationship; wherein the sink is a preset point with high vulnerability risk.

Description

Technical Field

[0001] The present disclosure relates to the technical field of data processing, and in particular, to a method, apparatus, device, and storage medium for handling vulnerabilities in an embedded firmware system. Background Art

[0002] Embedded firmware systems have been widely used in various fields, and the security issues of embedded firmware systems have become increasingly prominent. However, current vulnerability mining methods can be divided into static analysis methods and dynamic simulation methods, both of which cannot efficiently and accurately mine vulnerabilities in embedded firmware systems.

[0003] In view of this, how to efficiently and accurately mine vulnerabilities in embedded firmware systems has become a technical problem to be solved urgently. Summary of the Invention

[0004] In view of this, the purpose of the present disclosure is to propose a method, apparatus, device, and storage medium for handling vulnerabilities in an embedded firmware system to solve or partially solve the above technical problems.

[0005] Based on the above purpose, the first aspect of the present disclosure proposes a method for handling vulnerabilities in an embedded firmware system, the method comprising:

[0006] Determining front-end keywords from the front-end files of the embedded firmware system;

[0007] Identifying the back-end files of the embedded firmware system according to the front-end keywords to obtain an identification result;

[0008] Marking the input data as tainted, marking the keyword entry points in the identification result as the source points of the taint, determining the program call relationship by using alias analysis based on structured symbolic expressions, and determining the vulnerability path of the taint from the source point to the sink point according to the program call relationship; wherein, the sink point is a point with a high preset vulnerability risk.

[0009] Based on the same inventive concept, the second aspect of the present disclosure proposes an apparatus for handling vulnerabilities in an embedded firmware system, comprising:

[0010] A front-end keyword determination module configured to determine front-end keywords from the front-end files of the embedded firmware system;

[0011] A back-end file entry point identification module configured to identify the back-end files of the embedded firmware system according to the front-end keywords to obtain an identification result;

[0012] A vulnerability path determination module is configured to mark input data as tainted, mark the keyword entry points in the recognition result as the source points of the taint, determine the program call relationship by using alias analysis based on structured symbolic expressions, and determine the vulnerability path of the taint from the source point to the sink point according to the program call relationship; wherein, the sink point is a point with a preset high vulnerability risk.

[0013] Based on the same inventive concept, a third aspect of the present disclosure provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable by the processor. When the processor executes the computer program, the above-mentioned method is implemented.

[0014] Based on the same inventive concept, a fourth aspect of the present disclosure provides a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores computer instructions for causing a computer to execute the above-mentioned method.

[0015] As can be seen from the above, the present disclosure provides a method, apparatus, device, and storage medium for handling vulnerabilities in an embedded firmware system. Determine front-end keywords from the front-end files of the embedded firmware system. Identify the back-end files of the embedded firmware system according to the front-end keywords to obtain a recognition result. Mark the input data as tainted, mark the keyword entry points in the recognition result as the source points of the taint, determine the program call relationship by using alias analysis based on structured symbolic expressions, and determine the vulnerability path of the taint from the source point to the sink point according to the program call relationship; wherein, the sink point is a point with a preset high vulnerability risk. In this way, by identifying the association between the front-end files and the back-end files and using alias analysis based on structured symbolic expressions to determine the program call relationship, potential vulnerability paths can be revealed, thereby efficiently and accurately mining vulnerabilities in the embedded firmware system and improving the security and reliability of the embedded firmware system. At the same time, there is no need to simulate the embedded firmware system, which is simpler and more efficient and convenient for operation and implementation. Description of the Drawings

[0016] In order to more clearly illustrate the technical solutions in the present disclosure or related technologies, the following will briefly introduce the drawings required for use in the embodiments or related technology descriptions. Obviously, the drawings described below are only embodiments of the present disclosure. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0017] Figure 1 It is a flowchart of the method for handling vulnerabilities in the embedded firmware system according to the embodiment of the present disclosure;

[0018] Figure 2Flowchart of a vulnerability mining method for an embedded firmware system based on precise alias analysis according to an embodiment of the present disclosure;

[0019] Figure 3 Structural schematic diagram of a vulnerability handling device for an embedded firmware system according to an embodiment of the present disclosure;

[0020] Figure 4 Structural schematic diagram of an electronic device according to an embodiment of the present disclosure. Detailed implementation manners

[0021] To make the objectives, technical solutions, and advantages of the present disclosure clearer and more understandable, the following further describes the present disclosure in detail with reference to specific embodiments and the accompanying drawings.

[0022] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present disclosure should have the ordinary meanings understood by those of ordinary skill in the art to which the present disclosure belongs. The "first", "second", and similar terms used in the embodiments of the present disclosure do not indicate any order, quantity, or importance, but are only used to distinguish different components. The terms such as "including" or "comprising" mean that the elements or items appearing before this term cover the elements or items listed after this term and their equivalents, without excluding other elements or items. The terms such as "connected" or "coupled" are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The terms such as "upper", "lower", "left", and "right" are only used to represent relative positional relationships, and when the absolute position of the object being described changes, the relative positional relationship may also change accordingly.

[0023] Based on the description of the background technology, embedded firmware systems have been widely used in various fields, including smart homes, industrial automation, medical devices, and transportation systems, etc. However, the security issues of embedded firmware systems have become increasingly prominent. In 2022, the number of newly added embedded software vulnerabilities in the China National Vulnerability Database (CNVD) operated by the National Internet Emergency Center exceeded 20,000, among which, medium and high-risk vulnerabilities accounted for 88.87%. The existence of firmware vulnerabilities enables attackers to potentially use these vulnerabilities to carry out malicious attacks, resulting in data leakage, system paralysis, or even more serious consequences.

[0024] The current vulnerability mining methods can be divided into static analysis methods and dynamic simulation methods. Among them, dynamic simulation methods mainly include fuzz testing and hybrid execution. However, these methods have many limitations in the embedded firmware system environment, such as the need to manually generate a large number of test cases, symbolic execution path explosion, etc. Static analysis methods will have a large number of false negatives when facing vulnerability paths involving indirect calls, and the frequent occurrence of variable aliases also hinders the mining of potential vulnerability paths. Therefore, how to efficiently and accurately mine vulnerabilities in embedded firmware systems has become an urgent problem to be solved in the current information security field.

[0025] As described above, how to efficiently and accurately mine vulnerabilities in embedded firmware systems has become an important research issue.

[0026] Based on the above description, as Figure 1 shown, the vulnerability handling method for the embedded firmware system proposed in this embodiment includes:

[0027] Step 101, determine front-end keywords from the front-end files of the embedded firmware system.

[0028] Specifically, when implemented, the firmware in the embedded system is a software located between the hardware and the software. The firmware files of the embedded firmware system include front-end files and back-end files. Specifically, obtain the front-end files from the firmware files of the embedded firmware system, and extract the front-end keywords from the front-end files.

[0029] Step 102, identify the back-end files of the embedded firmware system according to the front-end keywords to obtain an identification result.

[0030] Specifically, when implemented, identify the back-end files of the embedded firmware system according to the front-end keywords. Different matching types use different methods to determine the calling functions, take the calling functions as the keyword entry points, and use the keyword entry points as the identification results.

[0031] Step 103, mark the input data as tainted, mark the keyword entry points in the identification result as the source points of the taint, use alias analysis based on structured symbolic expressions to determine the program call relationship, and determine the vulnerability path of the taint from the source point to the sink point according to the program call relationship; where the sink point is a point with a high preset vulnerability risk.

[0032] Specifically, when implemented, use alias analysis based on structured symbolic expressions (Structured Symbolic Expression, abbreviated as SSE) to determine alias information, construct an inter-process control flow graph according to the alias information, and determine the program call relationship based on the inter-process control flow graph.

[0033] Determine the vulnerability path of taint from the source point to the sink point according to the program call relationship. Among them, the taint is the marked input data, the source point is the marked keyword entry point, and the sink point is the point with a preset high vulnerability risk. In this way, based on the vulnerability path of taint from the source point to the sink point, potential vulnerability paths can be revealed, so as to efficiently and accurately mine vulnerabilities in the embedded firmware system.

[0034] Through the above embodiments, the front-end keywords are determined from the front-end files of the embedded firmware system. The back-end files of the embedded firmware system are identified according to the front-end keywords to obtain the identification result. The input data is marked as taint, and the keyword entry point in the identification result is marked as the source point of the taint. The alias analysis based on the structured symbolic expression is used to determine the program call relationship, and the vulnerability path of the taint from the source point to the sink point is determined according to the program call relationship; among them, the sink point is the point with a preset high vulnerability risk. In this way, by identifying the association between the front-end file and the back-end file and using the alias analysis based on the structured symbolic expression to determine the program call relationship, potential vulnerability paths can be revealed, so as to efficiently and accurately mine vulnerabilities in the embedded firmware system, improving the security and reliability of the embedded firmware system. At the same time, there is no need to simulate the embedded firmware system, which is simpler and more efficient and convenient for operation and implementation.

[0035] In some embodiments, step 101 includes:

[0036] Step 1011, obtain the front-end file of the embedded firmware system.

[0037] Step 1012, extract the front-end strings from the front-end file, and filter out the invalid keywords in the front-end strings to obtain the front-end keywords.

[0038] Specifically, when implementing, identify the front-end files in the embedded firmware system, where the front-end files include: HTML files, XML files, and JS files. Extract the front-end strings in these front-end files as the front-end keywords and filter out the invalid keywords.

[0039] Through the above solution, by extracting the front-end strings from the front-end files, the front-end keywords can be accurately obtained. By filtering out the invalid keywords in the front-end strings, the obtained front-end keywords are more accurate, avoiding inaccurate identification of the back-end files due to the existence of invalid keywords in the front-end keywords.

[0040] In some embodiments, the front-end files include: HTML files, XML files, and JS files; step 1012 includes:

[0041] Step 1012A: Perform matching processing on the HTML file and the XML file through regular expressions to obtain a front-end string.

[0042] Step 1012B: Parse the JS file into an abstract syntax tree, and extract the front-end string from the text nodes in the abstract syntax tree.

[0043] Step 1012C: Filter out the invalid keywords in the front-end string to obtain front-end keywords.

[0044] In specific implementation, obtain the front-end files of the embedded firmware system. The front-end files include: HTML files, XML files, and JS files.

[0045] Specifically, for HTML files and XML files, use regular expressions for matching to obtain the front-end string. For JS files, parse the JS file into an abstract syntax tree, and extract the front-end keywords from the text nodes in the abstract syntax tree. Filter out the invalid keywords in the front-end string to obtain the front-end keywords. Finally, construct a front-end keyword set and pass it to the back-end entry point recognition module.

[0046] Through the above solution, for HTML files and XML files, accurate matching processing can be performed through regular expressions to obtain the front-end string. For JS files, by parsing the JS file into an abstract syntax tree, the front-end keywords can be accurately extracted from the text nodes of the abstract syntax tree.

[0047] In some embodiments, the back-end files include: back-end binary files; Step 102 includes:

[0048] Step 1021: Extract the back-end string from the back-end binary file of the embedded firmware system according to the front-end keywords.

[0049] Step 1022: Match the back-end string with the front-end keywords to obtain the number of matches, and use the back-end binary file with the number of matches greater than the preset number as the back-end boundary binary file.

[0050] Step 1023: Determine the matching type, determine the calling function based on the matching type, and determine the keyword entry point as the recognition result based on the calling function.

[0051] In specific implementation, according to the front-end keywords, extract the string from each back-end binary file and match it with the front-end keywords. Use the back-end binary file with the number of matches exceeding the threshold (default set to 5) as the back-end boundary binary file. Among them, the back-end boundary binary file refers to the file with a relatively high risk of vulnerabilities.

[0052] Determine the first matching type between the backend string and the frontend keyword, and determine the second matching type between the backend binary files. Different matching types use different methods to determine the calling function, and based on the calling function, determine the keyword entry point as the recognition result.

[0053] Through the above solution, the backend string is matched with the frontend keyword to obtain the number of matches, and the backend binary files with the number of matches greater than the preset number are used as the backend boundary binary files, so that the backend boundary binary files with a greater risk of vulnerabilities can be identified. Different matching types use different methods to determine the calling function, which can accurately determine the calling function, and thus accurately identify the keyword entry point.

[0054] In some embodiments, step 1023 includes:

[0055] Step 1023A, determine the first matching type between the backend string and the frontend keyword, and determine the second matching type between the backend binary files.

[0056] Step 1023B, in response to determining that the first matching type is the direct reference type, use the calling function between the backend string and the frontend keyword as the keyword entry point, and use the keyword entry point as the recognition result.

[0057] Step 1023C, in response to determining that the first matching type is a keyword with backend input and non-existent frontend file, and there is a function with a similar code pattern in the code context of the identified keyword entry point, use the function with the similar code pattern as the keyword entry point, and use the keyword entry point as the recognition result.

[0058] Step 1023D, in response to determining that the second matching type is the cross-binary data flow type, and the variable name parameters of the functions between the backend binary files are the same, determine the variable name parameters of the NVRAM configuration function and the environment variable setting function, and use the NVRAM configuration function and the environment variable setting function as the keyword entry point, and use the keyword entry point as the recognition result.

[0059] In specific implementation, for the case where a string is directly referenced, the calling function is recognized as the keyword entry point; for the case where the backend obtains user input and the corresponding keyword does not exist in the frontend file, it is detected whether there is a function with a similar code pattern in the code context of the recognized keyword entry point. If so, this function is also recognized as the entry point; for cross-binary data streams, all NVRAM configuration functions (for example, the nvram_safe_set function) and environment variable setting functions (for example, the setenv and getenv functions) are recognized, and the variable name parameters of these functions are identified. If the corresponding functions between binary files share the same variable name, it is determined that there is a data stream transfer between the binary files.

[0060] Through the above solution, when the type between the backend string and the frontend keyword is direct reference, the calling function is used as the keyword entry point. When the type between the backend string and the frontend keyword is backend input and the keyword does not exist in the frontend file, the function with a code pattern in the code context is used as the keyword entry point. When the type between the backend binary files is cross-binary data stream, it is determined that there is a data stream transfer between the binary files, and the NVRAM configuration function and the environment variable setting function are used as the keyword entry point. In this way, for different matching types, the keyword entry point can be accurately recognized.

[0061] In some embodiments, step 103 includes:

[0062] Step 1031, mark the input data as tainted, and mark the keyword entry point in the recognition result as the source point of the taint.

[0063] Step 1032, use alias analysis based on structured symbolic expressions to determine alias information, construct an inter-process control flow graph according to the alias information, and determine the program call relationship based on the inter-process control flow graph.

[0064] Step 1033, determine the vulnerability path of the taint from the source point to the sink according to the program call relationship.

[0065] In specific implementation, mark the input data as tainted and mark the keyword entry point as the source point of the taint. Use alias analysis based on SSE to determine alias information, construct an inter-process control flow graph according to the alias information, and determine the program call relationship based on the inter-process control flow graph. Determine the vulnerability path of the taint from the source point to the sink according to the program call relationship.

[0066] Alias analysis is a method for determining whether two pointers point to the same object or the same memory address. First, use SSE alias expressions to encode the nested context information of relevant program points, and then use IDA Pro to recover the Inter-procedural Control Flow Graph (ICFG) and identify all indirect call instructions.

[0067] Through the above solution, determine the vulnerability path of taint from the source point to the sink point according to the program call relationship. In this way, based on the vulnerability path of taint from the source point to the sink point, potential vulnerability paths can be revealed, so as to efficiently and accurately detect vulnerabilities in the embedded firmware system.

[0068] In some embodiments, step 1032 includes:

[0069] Step 1032A, encode the nested context information of the program using alias analysis based on structured symbolic expressions to obtain alias information.

[0070] Step 1032B, update the alias information iteratively in the define-use chain and the use-define chain, and parse the indirect call according to the alias relationship between the alias of the indirect call target and the function pointer, construct the inter-procedural control flow graph, and determine the program call relationship based on the inter-procedural control flow graph.

[0071] Specifically, the SSE expression iteratively follows the update rule in the define-use chain and the use-define chain until a fixed point is reached, that is, no new aliases are generated. For indirect call instructions, scan the binary file to find all references to value-taking functions, including function pointers and function table pointers, track these reference targets, find all aliases of the indirect call target and all aliases of the original reference, and check the data dependency relationship between the aliases. If the former (all aliases of the indirect call target) is an alias of the latter (all aliases of the original reference), the indirect call relationship can be directly recorded, and the call target can be calculated from the aliases to the indirect call target; if the former (all aliases of the indirect call target) can be represented by load(function table address + i * step), it is very likely to represent a function table reference, and at this time, the return value is added to the indirect call target.

[0072] A complete inter-procedural control flow graph can be constructed based on the complete alias information, and finally the path of taint propagation from the source to the sink can be found.

[0073] Through the above solution, by parsing the indirect call according to the alias relationship between the alias of the indirect call target and the function pointer, the inter-procedural control flow graph can be accurately constructed. Based on the inter-procedural control flow graph, the program call relationship can be accurately determined.

[0074] Through the above embodiments, front - end keywords are determined from the front - end files of the embedded firmware system. The back - end files of the embedded firmware system are identified according to the front - end keywords, and an identification result is obtained. The input data is marked as tainted, and the keyword entry points in the identification result are marked as the source points of the taint. The alias analysis based on structured symbolic expressions is used to determine the program call relationship, and the vulnerability path of the taint from the source point to the sink point is determined according to the program call relationship; wherein, the sink point is a point with a preset high vulnerability risk. In this way, by identifying the association between the front - end file and the back - end file and using the alias analysis based on structured symbolic expressions to determine the program call relationship, potential vulnerability paths can be revealed, so as to efficiently and accurately mine the vulnerabilities in the embedded firmware system, improving the security and reliability of the embedded firmware system. At the same time, there is no need to simulate the embedded firmware system, which is more simple and efficient and convenient for operation and implementation.

[0075] It should be noted that the embodiments of the present disclosure can be further described in the following ways:

[0076] Figure 2 This is a flowchart of a vulnerability mining method for an embedded firmware system based on precise alias analysis according to an embodiment of the present disclosure. As Figure 2 shown, the front - end and back - end files are automatically identified from the firmware files. Among them, the front - end files include HTML files, XML files, and JS files, and the back - end files can be back - end boundary binary files. Front - end keyword extraction is performed on the front - end files; the input entries of the back - end binary files are identified using the keyword set; through the taint analysis engine, precise alias analysis based on SSE is used to determine alias information, and an inter - process control flow graph is constructed according to the alias information. The program call relationship is determined based on the inter - process control flow graph; sensitive data streams are input, and warning messages are output.

[0077] Taking the embedded firmware system R7000P - V1.3.0.8_1.0.93 as an example, the specific process of the vulnerability mining method for the embedded firmware system based on precise alias analysis is as follows:

[0078] (1) Extract front - end file keywords

[0079] This system takes the decompressed firmware file system as input. There are many front - end files in the file system. HTML files, XML files, and JS files are scanned and identified, and the keywords in these front - end files are extracted and the file directories corresponding to the keywords are recorded. For example, the id attribute "domain" can be parsed in the front - end file / webroot_ro / pptp_client.html as a front - end keyword.

[0080] (2) Back - end entry identification point

[0081] Traverse the binary file of R7000P, extract strings and match them with the front-end keywords. For example, in the httpd file, 313 keywords were retrieved by the attack, and 247 of them appeared in the front-end keyword set, including the keyword "domain".

[0082] For the case of identifying contextually similar code, in the formSetSambaConf() function of the httpd file, there are a large number of getweb_var functions inside the function to obtain user input, and its parameters contain multiple strings such as "password" and "premitEn" that exist in the front-end keyword set, while "usbName" does not exist in the front-end keyword set. In this case, mark all string parameters of the getweb_var function and identify it as an entry point.

[0083] (3) Alias analysis

[0084] First, restore the inter-procedural control flow graph (ICFG) and identify all indirect call instructions through IDA pro, and then use the SSE-based alias expression to restore accurate and complete alias information.

[0085] Among them, off_xxx represents the starting address of the function table. At this time, the alias information of R3 can be expressed as load(function table address + i * step + offset constant), and the indirect call target address can be calculated when i takes different values.

[0086] Finally, for the firmware R7000P-V1.3.0.8_1.0.93, 84 indirect call points can be detected, 278 indirect call targets are detected, and a total of 70 vulnerable paths are identified, including 9 Nday vulnerabilities.

[0087] Through the above embodiments, the vulnerability mining method for embedded firmware based on accurate alias analysis, by identifying the association between front-end resources and back-end boundary binaries, uses the SSE-based alias analysis engine to construct a complete inter-procedural control flow graph, reveals potential vulnerability paths, and improves the security and reliability of the embedded system. At the same time, there is no need to simulate the firmware, which is simpler and more efficient and convenient to operate and implement.

[0088] It should be noted that the method of the embodiments of the present disclosure can be executed by a single device, such as a computer or a server. The method of this embodiment can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In this case of a distributed scenario, one of the multiple devices can only execute one or more steps of the method of the embodiments of the present disclosure, and these multiple devices will interact with each other to complete the described method.

[0089] It should be noted that some embodiments of the present disclosure have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the above embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require the particular order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0090] Based on the same inventive concept, corresponding to the method of any of the above embodiments, the present disclosure also provides a vulnerability handling device for an embedded firmware system.

[0091] Referring to Figure 3 , the vulnerability handling device for the embedded firmware system includes:

[0092] A front-end keyword determination module 301, configured to determine front-end keywords from the front-end files of the embedded firmware system;

[0093] A back-end file entry point identification module 302, configured to identify the back-end files of the embedded firmware system according to the front-end keywords to obtain an identification result;

[0094] A vulnerability path determination module 303, configured to mark the input data as tainted, mark the keyword entry point in the identification result as the source point of the taint, determine the program call relationship by using alias analysis based on structured symbolic expressions, and determine the vulnerability path of the taint from the source point to the sink point according to the program call relationship; wherein, the sink point is a point with a preset high vulnerability risk.

[0095] In some embodiments, the front-end keyword determination module 301 includes:

[0096] A front-end file acquisition unit, configured to acquire the front-end files of the embedded firmware system;

[0097] A filtering processing unit, configured to extract front-end strings from the front-end files and filter out invalid keywords in the front-end strings to obtain front-end keywords.

[0098] In some embodiments, the front-end files include: HTML files, XML files, and JS files; the filtering processing unit includes:

[0099] A matching processing subunit, configured to perform matching processing on the HTML files and the XML files through regular expressions to obtain front-end strings;

[0100] The extraction processing subunit is configured to parse the JS file into an abstract syntax tree and extract front-end strings from the text nodes in the abstract syntax tree;

[0101] The filtering processing subunit is configured to filter out invalid keywords in the front-end strings to obtain front-end keywords.

[0102] In some embodiments, the backend file includes: a backend binary file; the backend file entry point recognition module 302 includes:

[0103] The backend string extraction unit is configured to extract backend strings from the backend binary file of the embedded firmware system according to the front-end keywords;

[0104] The matching unit is configured to match the backend strings with the front-end keywords to obtain a matching count, and use the backend binary files with the matching count greater than a preset count as backend boundary binary files;

[0105] The recognition unit is configured to determine a matching type, determine a call function based on the matching type, and determine a keyword entry point based on the call function as the recognition result.

[0106] In some embodiments, the recognition unit includes:

[0107] The matching type determination subunit is configured to determine a first matching type between the backend strings and the front-end keywords, and determine a second matching type between the backend binary files;

[0108] The first recognition subunit is configured to, in response to determining that the first matching type is a direct reference type, use the call function between the backend strings and the front-end keywords as the keyword entry point, and use the keyword entry point as the recognition result;

[0109] The second recognition subunit is configured to, in response to determining that the first matching type is a keyword with backend input and non-existent front-end file, and there is a function with a similar code pattern in the code context of the recognized keyword entry point, use the function with the similar code pattern as the keyword entry point, and use the keyword entry point as the recognition result;

[0110] The third recognition subunit is configured to, in response to determining that the second matching type is a cross-binary data flow type, and the variable name parameters of the functions between the backend binary files are the same, determine the variable name parameters of the NVRAM configuration function and the environment variable setting function, and use the NVRAM configuration function and the environment variable setting function as the keyword entry point, and use the keyword entry point as the recognition result.

[0111] In some embodiments, the vulnerability path determination module 303 includes:

[0112] A marking unit configured to mark the input data as tainted and mark the keyword entry point in the recognition result as the source point of the taint;

[0113] A program call relationship determination unit configured to determine alias information by using alias analysis based on structured symbolic expressions, construct an inter-process control flow graph according to the alias information, and determine the program call relationship based on the inter-process control flow graph;

[0114] A vulnerability path determination unit configured to determine the vulnerability path of the taint from the source point to the sink point according to the program call relationship.

[0115] In some embodiments, the program call relationship determination unit includes:

[0116] An encoding processing subunit configured to perform encoding processing on the nested location information of the program by using alias analysis based on structured symbolic expressions to obtain alias information;

[0117] An inter-process control flow graph construction subunit configured to update the alias information iteratively in the define-use chain and the use-define chain, and resolve indirect calls according to the alias relationship between the alias of the indirect call target and the function pointer, construct an inter-process control flow graph, and determine the program call relationship based on the inter-process control flow graph.

[0118] For the convenience of description, the above devices are described by dividing them into various modules according to their functions. Of course, when implementing the present disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0119] The devices in the above embodiments are used to implement the vulnerability handling method of the corresponding embedded firmware system in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0120] Based on the same inventive concept, corresponding to the method in any of the above embodiments, the present disclosure further provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, it implements the vulnerability handling method of the embedded firmware system in any of the above embodiments.

[0121] Figure 4FIG. 0 shows a more specific schematic diagram of the hardware structure of the electronic device provided in this embodiment. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. Among them, the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are communicatively connected to each other inside the device through the bus 1050.

[0122] The processor 1010 may be implemented in the form of a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0123] The memory 1020 may be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, etc. The memory 1020 may store an operating system and other application programs. When implementing the technical solutions provided in the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0124] The input / output interface 1030 is used to connect to an input / output module to implement information input and output. The input / output module may be configured as a component in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Among them, the input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0125] The communication interface 1040 is used to connect to a communication module (not shown in the figure) to implement communication interaction between this device and other devices. Among them, the communication module may implement communication in a wired manner (such as USB (Universal Serial Bus), network cable, etc.) or in a wireless manner (such as mobile network, WIFI (Wireless Fidelity), Bluetooth, etc.).

[0126] The bus 1050 includes a path for transmitting information between various components of the device (such as the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040).

[0127] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, those skilled in the art can understand that the above device may also only include the components necessary to implement the solution of the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0128] The electronic device of the above embodiment is used to implement the vulnerability handling method of the corresponding embedded firmware system in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0129] Based on the same inventive concept, corresponding to the method of any of the above embodiments, the present disclosure also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the vulnerability handling method of the embedded firmware system as described in any of the foregoing embodiments.

[0130] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device.

[0131] The computer instructions stored in the storage medium of the above embodiment are used to cause the computer to execute the vulnerability handling method of the embedded firmware system as described in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0132] Those of ordinary skill in the art should understand that the discussion of any of the above embodiments is only exemplary and is not intended to imply that the scope of the present disclosure is limited to these examples; under the concept of the present disclosure, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of the embodiments of the present disclosure as described above, which are not provided in detail for the sake of brevity.

[0133] In addition, for simplicity of explanation and discussion, and so as not to make the embodiments of the present disclosure difficult to understand, well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Further, the devices may be shown in block diagram form in order to avoid making the embodiments of the present disclosure difficult to understand, and this also takes into account the fact that details regarding the implementation of these block diagram devices are highly dependent on the platform on which the embodiments of the present disclosure are to be implemented (i.e., these details should be entirely within the understanding of those skilled in the art). In cases where specific details (such as circuits) are set forth to describe exemplary embodiments of the present disclosure, it will be apparent to those skilled in the art that the embodiments of the present disclosure may be practiced without these specific details or with variations of these specific details. Accordingly, these descriptions should be regarded as illustrative rather than restrictive.

[0134] Although the present disclosure has been described in connection with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (such as dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0135] Embodiments of the present disclosure are intended to cover all such alternatives, modifications, and variations that fall within the broad scope of the present disclosure. Accordingly, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of the present disclosure shall be included within the protection scope of the present disclosure.

Claims

1. A vulnerability handling method for an embedded firmware system, characterized in that The method includes: Determining front-end keywords from the front-end files of the embedded firmware system; Identifying the back-end files of the embedded firmware system according to the front-end keywords to obtain an identification result; Marking the input data as tainted, marking the keyword entry points in the identification result as the source points of the taint, determining the program call relationship by using alias analysis based on structured symbolic expressions, and determining the vulnerability path of the taint from the source point to the sink point according to the program call relationship; wherein, the sink point is a point with high preset vulnerability risk.

2. The method according to claim 1, characterized in that, The determining front-end keywords from the front-end files of the embedded firmware system includes: Obtaining the front-end files of the embedded firmware system; Extracting front-end strings from the front-end files, and filtering out invalid keywords in the front-end strings to obtain front-end keywords.

3. The method according to claim 2, characterized in that, The front-end files include: HTML files, XML files, and JS files; The extracting front-end strings from the front-end files, and filtering out invalid keywords in the front-end strings to obtain front-end keywords includes: Performing matching processing on the HTML files and the XML files through regular expressions to obtain front-end strings; Parsing the JS files into abstract syntax trees, and extracting front-end strings from the text nodes in the abstract syntax trees; Filtering out invalid keywords in the front-end strings to obtain front-end keywords.

4. The method according to claim 1, wherein The back-end files include: back-end binary files; The identifying the back-end files of the embedded firmware system according to the front-end keywords to obtain an identification result includes: Extracting back-end strings from the back-end binary files of the embedded firmware system according to the front-end keywords; Matching the back-end strings with the front-end keywords to obtain a matching quantity, and taking the back-end binary files with the matching quantity greater than a preset quantity as back-end boundary binary files; Determining the matching type, determining the calling function based on the matching type, and determining the keyword entry point based on the calling function as the identification result.

5. The method according to claim 4, wherein The determining the matching type, determining the calling function based on the matching type, and determining the keyword entry point based on the calling function as the identification result includes: Determining the first matching type between the back-end strings and the front-end keywords, and determining the second matching type between the back-end binary files; In response to determining that the first matching type is the direct reference type, taking the calling function between the back-end strings and the front-end keywords as the keyword entry point, and taking the keyword entry point as the identification result; In response to determining that the first matching type is a keyword with back-end input and non-existent front-end file, and there is a function with a similar code pattern in the code context of the identified keyword entry point, taking the function with the similar code pattern as the keyword entry point, and taking the keyword entry point as the identification result; In response to determining that the second matching type is the cross-binary data stream type and the variable name parameters of the functions between the backend binary files are the same, determine the variable name parameters of the NVRAM configuration function and the environment variable setting function, use the NVRAM configuration function and the environment variable setting function as keyword entry points, and use the keyword entry points as the recognition result.

6. The method according to claim 1, characterized in that, Mark the input data as tainted, mark the keyword entry points in the recognition result as the source points of the taint, use alias analysis based on structured symbolic expressions to determine the program call relationship, and determine the vulnerability path of the taint from the source point to the sink point according to the program call relationship, including: Mark the input data as tainted and mark the keyword entry points in the recognition result as the source points of the taint; Use alias analysis based on structured symbolic expressions to determine alias information, construct an inter-process control flow graph according to the alias information, and determine the program call relationship based on the inter-process control flow graph; Determine the vulnerability path of the taint from the source point to the sink point according to the program call relationship.

7. The method according to claim 6, characterized in that, The using alias analysis based on structured symbolic expressions to determine alias information, constructing an inter-process control flow graph according to the alias information, and determining the program call relationship based on the inter-process control flow graph includes: Use alias analysis based on structured symbolic expressions to encode the nested location information of the program to obtain alias information; Iteratively update the alias information in the define-use chain and the use-define chain, and construct an inter-process control flow graph by resolving indirect calls according to the alias relationship between the alias of the indirect call target and the function pointer, and determine the program call relationship based on the inter-process control flow graph.

8. An apparatus for handling vulnerabilities in an embedded firmware system, characterized in that, Including: A front-end keyword determination module configured to determine front-end keywords from the front-end files of the embedded firmware system; A backend file entry point recognition module configured to recognize the backend files of the embedded firmware system according to the front-end keywords to obtain a recognition result; A vulnerability path determination module configured to mark the input data as tainted, mark the keyword entry points in the recognition result as the source points of the taint, use alias analysis based on structured symbolic expressions to determine the program call relationship, and determine the vulnerability path of the taint from the source point to the sink point according to the program call relationship; wherein, the sink point is a point with a preset high vulnerability risk.

9. An electronic device, characterized in that, Including a memory, a processor, and a computer program stored on the memory and running on the processor, and when the processor executes the program, the method according to any one of claims 1 to 7 is implemented.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing a computer to execute the method according to any one of claims 1 to 7.

Images