WO2022079779A1 - 検知装置、および、検知プログラム - Google Patents

検知装置、および、検知プログラム Download PDF

Info

Publication number
WO2022079779A1
WO2022079779A1 PCT/JP2020/038543 JP2020038543W WO2022079779A1 WO 2022079779 A1 WO2022079779 A1 WO 2022079779A1 JP 2020038543 W JP2020038543 W JP 2020038543W WO 2022079779 A1 WO2022079779 A1 WO 2022079779A1
Authority
WO
WIPO (PCT)
Prior art keywords
type
instruction
detection device
unit
types
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2020/038543
Other languages
English (en)
French (fr)
Inventor
達大 青島
利宣 碓井
裕平 川古谷
誠 岩村
潤 三好
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to PCT/JP2020/038543 priority Critical patent/WO2022079779A1/ja
Publication of WO2022079779A1 publication Critical patent/WO2022079779A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software

Definitions

  • the present invention relates to a technique for detecting a vulnerability by type confusion of a program.
  • This pointer analysis is a technique for detecting a type confusion vulnerability by enumerating the reference destinations of pointer variables of functions included in a program.
  • the present invention collects the types of variables that can be taken in the conditional branch of the source code by applying an abstract interpretation to the loader unit that reads the source code of the program and the read source code. Then, the dependency between the variables is specified by the dependency type theory, and the filtering of the set of types at the conditional branch destination among the collected types is filtered by using the dependency and the conditions used in the conditional branch. It is characterized by having an instruction interpretation unit for performing.
  • FIG. 1 is a diagram for explaining an outline of processing of the detection device.
  • FIG. 2 is a diagram showing a configuration example of the detection device.
  • FIG. 3 is a diagram showing an example of a definition of a dependent type syntax.
  • FIG. 4 is a diagram for explaining the domain (variable name) of the context.
  • FIG. 5 is a diagram for explaining an example of the type of projection.
  • FIG. 6 is a flowchart showing an example of the processing procedure of the type inspection unit of FIG.
  • FIG. 7 is a flowchart showing an example of the processing procedure of the instruction interpretation unit of FIG.
  • FIG. 8 is a flowchart showing an example of the processing procedure in S40 of FIG.
  • FIG. 9 is a flowchart showing an example of the processing procedure in S44 of FIG.
  • FIG. 10 is a diagram for explaining an operation example of the detection device.
  • FIG. 11 is a diagram showing a configuration example of a computer that executes a detection program.
  • the detection device of this embodiment adopts an abstract interpretation that collects types from all execution paths of the program to be detected in order to reduce false detection of a program type confusion vulnerability. Then, the detection device expresses the dependency between variables by the dependent type theory, solves the branch condition and the dependency, and filters the set of collected types.
  • the detection device recursively processes each sentence in the blocks A and B branched under the condition c to obtain TypeSet A and TypeSet B (S8).
  • the detection device filters the type sets of TypeSet A and TypeSet B by the projection mechanism according to the condition c (S9).
  • the detection device performs type inspection on the type set (TypeSet (v)) obtained as described above, and detects the vulnerability of the type confusion of the program.
  • the detector collects type candidates in consideration of conditional branching, so even if branching by C ++ dynamic type conversion (dynamic_cast between classes in a virtual inheritance relationship) is included, for example. Can accurately list type candidates.
  • the detection device can reduce the false detection of the program type confusion vulnerability.
  • the detection device 10 includes a loader unit 11, a tracer unit 12, an instruction interpretation unit 13, a type inspection unit 14, a context 15, and a queue 16.
  • the loader unit 11 reads and interprets the source code of the program.
  • the tracer unit 12 manages source code functions, blocks, and the like to be processed by the instruction interpretation unit 13. Further, the tracer unit 12 determines the convergence test of the processing by the instruction interpretation unit 13.
  • the instruction interpretation unit 13 interprets each instruction and calculates a type set of variables operated by each instruction while referring to the information of the context 15 and the type inspection unit 14. For example, the instruction interpretation unit 13 interprets each instruction of the function or block instructed by the tracer unit 12 in order, and calculates a type set of variables to be manipulated.
  • the type inspection unit 14 manages type information and performs type inspection. For example, the type inspection unit 14 determines whether the type cast (type conversion) is appropriate based on the type declaration list (type information), and calculates the type of the cast destination. Context 15 manages the mapping from the variable name to the type set corresponding to the variable name for each block of each function. The queue 16 holds a list of functions and blocks to be processed next by the instruction interpreter 13.
  • the loader unit 11 reads the source code of the program to be detected, the environment information held by the type inspection unit 14, the type set held by the context 15, and the list held by the queue 16 are initialized ((1). )-(3)). For example, in (2), the loader unit 11 evaluates the value of the global variable in the context 15 and initializes the type set.
  • the tracer unit 12 starts the analysis of the source code read by the loader unit 11 ((4)).
  • the function for starting the analysis may be, for example, main or may be specified by the user of the detection device 10.
  • the tracer unit 12 extracts the function / block to be processed next from the queue 16 ((5)), and if the preceding block is the branch source, resolves the branch condition and sets the context 15. Update ((6)).
  • the instruction interpretation unit 13 processes each instruction in the block taken out by the tracer unit 12 in order ((7)). For example, the instruction interpretation unit 13 interprets each instruction while referring to the information held in the type check unit 14 and the context 15, and calculates the type set of variables operated by the instruction. Further, the instruction interpretation unit 13 updates the information held in the type inspection unit 14 and the context 15 based on the above calculation result, and if there is a branch destination due to a conditional branch in the process of processing, those (branch destination information). ) Is added to the queue 16.
  • the tracer unit 12 determines that all the type sets in the context 15 have converged by the processing of the instruction interpretation unit 13 ((8)), the error information of the type inspection by the type inspection unit 14 (violation of the type cast). Output the location and the reason for the error). By doing so, the detection device 10 can detect the vulnerability of the program type confusion.
  • FIG. 3 shows the definition of dependent syntax in BNF notation.
  • the concrete type is a basic type or a composite type defined by the C / C ++ standard, but a type that can be handled by other programming languages, an integer / real number interval ([a, b]), and ( It may be a, b), etc.), a convex set in a multidimensional real vector space, or the like.
  • the value is a value corresponding to the type specified in the C / C ++ standard, but it is not limited to this as long as it is a specific type value. Furthermore, although caution is required when modifying the type (TypeExpr), there is no limitation on modifications within the range where the expressiveness does not change, such as increasing the number of subscripts in the field address reference operation to two or more.
  • the tracer unit 12 of the detection device 10 uses Loc to record the substitution location.
  • Loc has a function name (funcName), a block name (BlockName), and an instruction number (InsnIdx).
  • the instruction number shall start from 1.
  • instruction number 0 is used in a pseudo manner for storing the collection result from the preceding block. Note that the tracer unit 12 treats the objects to be traced as different if they have the same type but different initialized parts.
  • Context 15 manages the mapping of the variable name RegPath to the type set in order to hold the possible values of the variable.
  • the tracer unit 12 increments the version of the context 15 for each substitution accompanied by a change for the convergence test.
  • the tracer unit 12 also updates the version of the current node to the version of context 15. Then, the tracer unit 12 determines that the current node version has converged if it is after the version of all the preceding nodes.
  • the tracer unit 12 determines that the substitution involves a change when all of the following conditions (1) to (3) are satisfied.
  • variable assignment location is the current node, which satisfies one of the following two conditions.
  • the instruction number is newer than the previous variable assignment location.
  • the instruction number of the variable assignment location is not 0.
  • the types of projections and the operation of the context 15 in the present embodiment will be described with reference to FIG.
  • the instruction interpretation unit 13 of the detection device 10 constrains the elements of the type set of a specific variable by the projection mechanism.
  • the types of projection are, for example, as follows.
  • the type of projection is not limited to the above as long as it can be clearly defined in which part of the program it is effective.
  • the projection mechanism like context 15, has a mapping to the corresponding variable name and the corresponding type set.
  • the instruction interpreting unit 13 When the instruction interpreting unit 13 acquires a variable type set, it confirms whether or not it is restricted by the projection mechanism, and if it is restricted by the projection mechanism, returns the type set restricted by the projection mechanism. On the other hand, if not restricted by the projection mechanism, it returns the type set held by context 15.
  • the instruction interpreter 13 assigns a type set to a variable, it confirms whether or not it is constrained by the projection mechanism, and if it is constrained by the projection mechanism, it substitutes it into the projection mechanism and is constrained by the projection mechanism. If not, assign it to context 15.
  • the type inspection unit 14 manages type information and performs type inspection.
  • the type check is to determine whether each element of the cast source type set can be cast to the cast destination concrete type. If the type inspection unit 14 fails the type inspection, the error information is recorded and the type for which the type inspection fails is removed from the type set.
  • the type check unit 14 uses, but is not limited to, the C / C ++ standard rules (however, the pointer cast is modified to allow only the cast between the upcast and the function pointer) in the type check. The rules of other programming languages may be used, depending on the definition of the concrete type.
  • the cast destination is limited to the concrete type because it may be limited to the concrete type that appears in the source code in order to determine whether or not it is cast to the expected type in the source code.
  • type inspection unit 14 does not perform type inspection on types that are not subject to tracking.
  • the cast rule when the type inspection unit 14 performs a type inspection on the owned type will be described later with reference to FIG.
  • the type inspection unit 14 recursively expands to the form not including the type while referring to the variables in the context 15 according to the semantics of the type, and the type inspection for the concrete type and the possessed type. To apply.
  • the type inspection unit 14 determines whether the concrete type S can be cast to the concrete type T, and returns the result (the result). S12).
  • the type inspection unit 14 cast the constant type to the concrete type T? Judges whether or not, and if cast is possible, returns the result (S14).
  • the type inspection unit 14 determines that casting is possible if the value of the constant is NULL and T (concrete type T) is a pointer type (Yes in S15). On the other hand, if the value of the constant is NULL and T (concrete type T) is not a pointer type (No in S15), the type inspection unit 14 determines that casting is not possible (S25).
  • the type inspection unit 14 determines whether T is a function pointer type (S17). Then, when T is a function pointer type (Yes in S17), the type inspection unit 14 determines that casting is possible (S24). On the other hand, when T is not a function pointer type (No in S17), the type inspection unit 14 determines that casting is not possible (S25).
  • the type inspection unit 14 determines whether or not S'is a concrete type (S19).
  • S19 when the type inspection unit 14 determines that S'is a specific type (Yes in S19), it determines whether the specific type S' * can be cast to the specific type T, and returns the result (S20).
  • S25 when S is not a function pointer type (No in S16) and is not &S'(No in S18), the type inspection unit 14 determines that casting is not possible (S25).
  • the type inspection unit 14 determines whether or not the specific type T is T' * (S21).
  • the type inspection unit 14 determines that the concrete type T is not T' * (No in S21), it determines whether the concrete type S'can be cast to the concrete type T'and returns the result (S23). ..
  • the instruction interpretation unit 13 performs an assignment process for each element of the type set of the variable to be assigned.
  • the assignment process is a process in which a type check is performed to see if the type set of the assignment source can be cast to the type of the assignment destination, and each assignment destination including the indirect field destination is defined by the type set of the assignment source. That is.
  • the input to the instruction interpretation unit 13 is assumed to be the substitution destination * v and the assignment source w, and the output from the instruction interpretation unit 13 is described as a typeset.
  • the instruction interpreting unit 13 acquires the type set TypeSet (v @ L) of the assignment destination * v from the context 15 and expands all except the non-local variables (S401). Further, the instruction interpreting unit 13 acquires the type set TypeSet (w) of the assignment source w from the context 15 and expands all except the non-local variables (S402).
  • the instruction interpretation unit 13 analyzes the dependency between the function pointer and the argument sequence using, for example, the Least Common Ancestor algorithm. Then, the instruction interpretation unit 13 narrows down the candidates according to the dependency by projecting the contents of the type set of the ancestor variables identified by the above analysis one by one using the projection mechanism at. As a result, the instruction interpreting unit 13 can accurately list the reference destinations of this pointer in the call of the virtual method.
  • the call process here is a process of assigning the type set of the argument string to the formal argument of the callee, and a process of substituting the return value of the callee when receiving the return value.
  • the input to the instruction interpretation unit 13 is the assignment destination v (option), the function pointer f, the argument strings a [1], ..., a [n], and is from the instruction interpretation unit 13.
  • the output of is described as being a typeset.
  • the instruction interpretation unit 13 acquires the type set TypeSet (f) of the function pointer f from the context 15, checks whether it is a function pointer, and expands all the types (S441). Then, the instruction interpreting unit 13 repeats the processes of S443 to S446 shown below for the pointer type F to the global function in TypeSet (f) (S442).
  • the instruction interpretation unit 13 acquires the type set of the argument strings a [1], ..., a [n] from the context 16 and integrates each into the type set of the formal arguments to be called (S443).
  • the instruction interpreting unit 13 integrates the TypeSet (v) with the type set of the return value of the call destination (S445).
  • the instruction interpreting unit 13 adds the called destination F to the queue 16 (S446).
  • S445 is skipped and the call destination F is added to the queue 16 (S446).
  • the instruction interpretation unit 13 performs the call processing for each element of the type set of the function pointer while resolving the dependency, and adds it to the queue 16 as the call destination.
  • the detection device 10 interprets the source code shown in FIG. 10, in a non-null branch (A: cast is possible), only the non-null type of the arr type set is left, and the null branch (B: cast is not possible). Then, only the NULL type is left ((1) Sifting by conditional branching).
  • the detection device 10 operates only the variables that are branching, an impossible combination may occur (for example, obj: Number * , arr: Array * , etc. in (A)), so the dependent obj type. It also calculates the set.
  • the detection device 10 can analyze C ++ inheritance and virtual methods and correctly distribute them to processing according to various types. Further, the detection device 10 takes out the pointer of the virtual method from the object and passes the object as an argument. For example, the detection device 10 can accurately calculate the type set in consideration of the dependency by selecting the types of obj one by one, enumerating the pointers to the virtual methods, and allocating the processing.
  • each component of each of the illustrated parts is a functional concept, and does not necessarily have to be physically configured as shown in the figure. That is, the specific form of distribution / integration of each device is not limited to the one shown in the figure, and all or part of them may be functionally or physically distributed / physically in arbitrary units according to various loads and usage conditions. Can be integrated and configured. Further, each processing function performed by each device may be realized by a CPU and a program executed by the CPU, or may be realized as hardware by wired logic.
  • the detection device 10 described above can be implemented by installing a program as package software or online software on a desired computer. For example, by causing the information processing device to execute the above program, the information processing device can function as the detection device 10 of each embodiment.
  • the information processing device referred to here includes a desktop type or notebook type personal computer.
  • information processing devices include smartphones, mobile communication terminals such as mobile phones and PHS (Personal Handyphone System), and terminals such as PDAs (Personal Digital Assistants).
  • the detection device 10 can be implemented as a server device in which the terminal device used by the user is a client and the service related to the above processing is provided to the client.
  • the server device may be implemented as a Web server, or may be implemented as a cloud that provides services related to the above processing by outsourcing.
  • FIG. 11 is a diagram showing an example of a computer that executes a detection program.
  • the computer 1000 has, for example, a memory 1010 and a CPU 1020.
  • the computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. Each of these parts is connected by a bus 1080.
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012.
  • the ROM 1011 stores, for example, a boot program such as a BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to the hard disk drive 1090.
  • the disk drive interface 1040 is connected to the disk drive 1100.
  • a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100.
  • the serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120.
  • the video adapter 1060 is connected to, for example, the display 1130.
  • the hard disk drive 1090 stores, for example, OS1091, application program 1092, program module 1093, and program data 1094. That is, the program that defines each process executed by the detection device 10 is implemented as a program module 1093 in which a code that can be executed by a computer is described.
  • the program module 1093 is stored in, for example, the hard disk drive 1090.
  • the program module 1093 for executing the same processing as the functional configuration in the detection device 10 is stored in the hard disk drive 1090.
  • the hard disk drive 1090 may be replaced by an SSD.
  • each data used in the processing of the above-described embodiment is stored as program data 1094 in, for example, a memory 1010 or a hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the memory 1010 and the hard disk drive 1090 into the RAM 1012 and executes them as needed.
  • the program module 1093 and the program data 1094 are not limited to those stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). Then, the program module 1093 and the program data 1094 may be read from another computer by the CPU 1020 via the network interface 1070.
  • LAN Local Area Network
  • WAN Wide Area Network

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

検知装置は、プログラムのソースコードに抽象解釈を適用することにより、ソースコードの条件分岐で取り得る変数の型を収集する。そして、検知装置は、依存型理論により変数間の依存関係を特定し、特定した依存関係と条件分岐で用いられる条件を用いて、条件分岐先における変数の型の集合のフィルタリングを行う。そして、検知装置は、型の集合の各要素がキャスト先の具体型へキャスト可能か否かを判定する型検査を行い、型検査の結果を出力する。また、検知装置は、変数間の依存関係を特定する際、関数ポインターと引数列との間の依存関係も特定する。

Description

検知装置、および、検知プログラム
　本発明は、プログラムの型混同（Type　Confusion）による脆弱性の検知技術に関する。
　従来、プログラムの型混同による脆弱性の検知技術としてポインター解析がある。このポインター解析は、プログラムに含まれる関数のポインター変数の参照先を列挙することにより、型混同の脆弱性を検知する技術である。
　しかし、上記のポインター解析は、解析対象の分岐条件を無視するので、プログラムの動的な型変換による分岐を考慮できず、型の候補を過剰に列挙してしまう。その結果、プログラムの型混同の脆弱性の検知において誤検知が発生しやすいという問題がある。そこで、本発明は、前記した問題を解決し、プログラムの型混同の脆弱性の検知において、誤検知を低減することを課題とする。
　前記した課題を解決するため、本発明は、プログラムのソースコードを読み込むローダー部と、前記読み込んだソースコードに抽象解釈を適用することにより、前記ソースコードの条件分岐で取り得る変数の型を収集し、依存型理論により前記変数間の依存関係を特定し、前記依存関係と前記条件分岐で用いられる条件を用いて、前記収集した型の集合のうち前記条件分岐先における型の集合のフィルタリングを行う命令解釈部と、を備えることを特徴とする。
　本発明によれば、プログラムの型混同の脆弱性の検知において、誤検知を低減することができる。
図１は、検知装置の処理の概要を説明するための図である。 図２は、検知装置の構成例を示す図である。 図３は、依存型の構文の定義の例を示す図である。 図４は、文脈の定義域（変数名）を説明するための図である。 図５は、射影の種類の例を説明するための図である。 図６は、図２の型検査部の処理手順の例を示すフローチャートである。 図７は、図２の命令解釈部の処理手順の例を示すフローチャートである。 図８は、図７のS40における処理手順の例を示すフローチャートである。 図９は、図７のS44における処理手順の例を示すフローチャートである。 図１０は、検知装置の動作例を説明するための図である。 図１１は、検知プログラムを実行するコンピュータの構成例を示す図である。
　以下、図面を参照しながら、本発明を実施するための形態（実施形態）について説明する。本発明は、本実施形態に限定されない。
　本実施形態の検知装置は、プログラムの型混同の脆弱性の誤検知を低減するため、検知対象のプログラムのあらゆる実行パスから型を集める抽象解釈を採用する。そして、検知装置は、変数間の依存関係を依存型（dependent　type）理論により表現し、分岐条件とその依存関係を解決し、収集した型の集合をフィルタリングする。
　図１を用いて、検知装置の処理の概要を説明する。まず、検知装置は、検知対象のプログラムの命令文の入力を受け付けると、オブジェクト確保の度に、命令文の変数（v）が取り得る型の集合（型集合）を初期化する（S1のv=new　T?でYes→S2のTypeSet(v)=｛T｝）。
　また、S1で命令文のv=new　Tではなく（S1でNo）、v=wの場合（S3でYes）、検知装置は、値の代入について、変数wという型式として表現された型を利用し、それのみを含む集合に置き変える（S4：TypeSet（v）=｛w｝)。
　一方、命令文のv=wではなく（S3でNo）、v=&(w->f)の場合（S5でYes）、検知装置は、アドレス操作の度に、型集合の各要素を基点にしたポインター操作の結果であることを型式で表現する（S6：TypeSet（w）=｛&(S->ｆ)|S∈TypeSet(w)｝)。
　一方、命令文のv=&(w->f)ではなく（S5でNo）、条件分岐である場合（S7でYes）、S8へ進む。そして、検知装置は、例えば、まず、条件cで分岐されるブロックA,B中の各文に対して、再帰的に処理し、TypeSetAとTypeSetBを求める（S8）。次に、検知装置は、条件cに応じて、射影機構によりTypeSetAとTypeSetBの型集合をフィルタリングする（S9）。そして、検知装置は、S9のフィルタリングにより出現した各変数vに対して、TypeSet（v)＝TypeSetA（v)∪TypeSetB（v)を求める（S10）。
　一方、命令文が条件分岐ではない場合（S7でNo）、検知装置は、v=op(s[1],…,s[n])、TypeSet（v)＝｛op(T1,…,Tn))|Ti∈TypeSet（s[i]）｝とする（S11）。
　検知装置は、上記のようにして得られた型集合（TypeSet（v））に対し、型検査を行い、プログラムの型混同の脆弱性の検知を行う。このように、検知装置は、条件分岐を考慮して型候補の収集を行うので、例えば、C++の動的な型変換（仮想継承関係にあるクラス間のdynamic_cast）による分岐が含まれる場合でも、型の候補を正確に列挙することができる。その結果、検知装置は、プログラムの型混同の脆弱性の誤検知を低減することができる。
　次に、図２を用いて検知装置の構成例を説明する。検知装置１０は、ローダー部１１と、トレーサー部１２と、命令解釈部１３と、型検査部１４と、文脈１５と、キュー１６とを備える。
　ローダー部１１は、プログラムのソースコードの読み込みと解釈とを行う。トレーサー部１２は、命令解釈部１３で処理すべきソースコードの関数、ブロック等を管理する。また、トレーサー部１２は、命令解釈部１３による処理の収束判定を行う。命令解釈部１３は、文脈１５と型検査部１４の情報を参照しながら、各命令を解釈し、各命令により操作される変数の型集合を計算する。例えば、命令解釈部１３は、トレーサー部１２により指示された関数またはブロックの各命令を順に解釈し、操作される変数の型集合を計算する。
　型検査部１４は、型情報の管理と型検査を行う。例えば、型検査部１４は、型の宣言リスト（型情報）に基づき、型キャスト（型変換）が妥当かどうかを判定し、キャスト先の型を計算する。文脈１５は、各関数のブロックごとに、変数名から当該変数名に対応する型集合への写像を管理する。キュー１６は、命令解釈部１３が次に処理する関数、ブロックのリストを保持する。
　以下、図２を参照しながら、検知装置１０の動作例を説明する。まず、ローダー部１１が検知対象のプログラムのソースコードを読み込むと、型検査部１４で保持される環境情報、文脈１５で保持する型集合、キュー１６で保持するリストそれぞれを初期化する（（１）～（３））。例えば、（２）において、ローダー部１１は、文脈１５のグローバル変数の値を評価し、型集合を初期化する。
　次に、トレーサー部１２は、ローダー部１１で読み込んだソースコードの解析を開始する（（４））。なお、解析を始める関数は、例えば、mainでもよいし、検知装置１０のユーザが指定したものであってもよい。トレーサー部１２は、ソースコードの解析の過程で、キュー１６から次に処理する関数／ブロックを取り出し（（５））、先行ブロックが分岐元であれば、その分岐条件を解決し、文脈１５を更新する（（６））。
　命令解釈部１３は、トレーサー部１２により取り出されたブロック中の各命令を順に処理する（（７））。例えば、命令解釈部１３は、型検査部１４および文脈１５で保持される情報の参照しながら、各命令を解釈し、当該命令により操作される変数の型集合を計算する。また、命令解釈部１３は、上記の計算結果に基づき、型検査部１４および文脈１５で保持される情報を更新し、処理の過程で条件分岐による分岐先があれば、それら（分岐先の情報）をキュー１６に追加する。
　その後、トレーサー部１２が、命令解釈部１３の処理により、文脈１５中のすべての型集合が収束したと判定すると（（８））、型検査部１４による型検査のエラー情報（型キャストに違反した箇所とその理由）を出力する。このようにすることで検知装置１０は、プログラムの型混同の脆弱性の検知を行うことができる。
[依存型の構文の定義例]
　図３を用いて、本実施形態における依存型の構文の定義の例を説明する。図３は、BNF記法による依存型の構文の定義を示す。
　本実施形態では、具体型（ConcreteType）は、C/C++標準で規定された基本型や複合型とするが、他のプログラミング言語で扱える型や、整数／実数区間([a,ｂ]や(a,ｂ)等)、多次元実ベクトル空間中の凸集合等でもよい。
　また、値（Value）は、C/C++標準で規定された型に対応する値としているが、具体型の値であれば、これに限定されない。さらに、型式（TypeExpr）の修正には注意を要するが、フィールドアドレスの参照操作における添え字の数を2つ以上にする等、表現力が変わらない範囲での修正に関しては、限定されない。
[文脈の定義と収束判定の例]
　次に、図４を用いて、本実施形態における文脈の定義と収束判定について説明する。検知装置１０は、ポインターを介した破壊的な代入が可能なプログラムを解析するため、変数の値を代入箇所ごとに区別する必要がある。そこで、検知装置１０のトレーサー部１２は、代入箇所を記録するため、Locを用いる。Locは、関数名（funcName）、ブロック名（BlockName）、命令番号（InsnIdx）を持つ。命令番号は1から始まるものとする。また、命令番号0は、先行ブロックからの回収結果を格納する用途等で擬似的に使う。なお、トレーサー部１２は、トレース対象のオブジェクトが同じ型でも、初期化された箇所が異なれば、別として扱う。
　文脈１５は、変数の取り得る値を保持するため、変数名RegPathを型集合へ対応させる写像を管理する。トレーサー部１２は、収束判定のために、変更を伴う代入の度に、文脈１５のバージョンをインクリメントする。また、トレーサー部１２は、現在のノードのバージョンも文脈１５のバージョンに更新する。そして、トレーサー部１２は、現在のノードのバージョンが、先行するすべてのノードのバージョン以降であれば、収束したと判定する。
　なお、トレーサー部１２は、以下の（１）～（３）の条件をすべて満たすときに、変更を伴う代入と判定する。
（１）変数が射影機構により制約されていない。
（２）変数にはすでに値が代入されていて、変数の代入箇所が現在のノードで、以下の2つの条件のいずれかを満たす。
（２-１）前回の変数の代入箇所より命令番号が新しい。
（２-２）前回の代入における型集合と異なる値を代入する。
（３）変数の代入箇所の命令番号が0でない。
[射影機構の定義と文脈の動作]
　図５を用いて、本実施形態における射影の種類と文脈１５の動作について説明する。検知装置１０の命令解釈部１３は、射影機構により、特定の変数の型集合の要素を制約する。射影の種類は、例えば、以下のようなものがある。
・関数ポインターと引数列間の依存関係を解決するため、一命令でのみ有効なat。
・分岐条件により型集合をフィルタリングするため、分岐先でのみ有効な、true-branch、false-branch。
・エラーにより追跡対象外とするときにフィルタリングするため、それ以降の命令でのみ有効なsince。
　射影の種類は、プログラム中のどの箇所で有効かが明確に定義可能なものであれば上記のものに限定されない。
　射影機構は、文脈１５と同じく、制約する変数名と対応する型集合への写像を持つ。
　なお、命令解釈部１３が変数の型集合を取得するときは、射影機構により制約されているかどうかを確認し、射影機構により制限されている場合は、射影機構により制限された型集合を返す。一方、射影機構により制限されていない場合、文脈１５が保持する型集合を返す。
　また、命令解釈部１３が変数へ型集合を代入するときは、射影機構により制約されているかどうかを確認し、射影機構により制約されている場合は、射影機構へ代入し、射影機構により制約されていなければ、文脈１５へ代入する。
［型検査部］
　型検査部１４は、型情報の管理と型検査を行う。型検査は、キャスト元の型集合の各要素がキャスト先の具体型へキャスト可能かどうかの判定を行うことである。型検査部１４が型検査に失敗した場合は、そのエラー情報を記録し、型検査に失敗した型を型集合から取り除く。型検査部１４は、型検査において、C/C++標準の規則（ただし、ポインターのキャストにおいて、アップキャストと関数ポインター間のキャストのみ認めるように修正したもの））を用いるが、これに限らず、具体型の定義に応じ、他のプログラミング言語の規則を用いてもよい。
　また、キャスト先が具体型に限定されるのは、ソースコードで期待する型へキャストされるかどうかを判定するには、ソースコード中に現れる具体型に限定してよいからである。
　なお、型検査部１４は、追跡対象外の型に関する型検査は行わない。なお、型検査部１４が所有型に対する型検査を行う際のキャスト規則は、図６を用いて後記する。
　また、型検査部１４は、型式に対する型検査では、型式の意味論に従い、文脈１５中の変数を参照しながら、型式を含まない形まで再帰的に展開し、具体型と所有型に対する型検査を適用する。
［型検査を行う際の処理手順の例］
　次に、図６を用いて型検査部１４が、所有型に対する型検査を行う際の処理手順の例を説明する。なお、図６に示す処理における、型検査における型検査部１４への入力は、キャスト元の所有型Sおよびキャスト先の具体型Tであり、型検査部１４からの出力は、キャスト可能か否かの判定結果である。
　まず、型検査部１４は、入力されたS（所有型S）が具体型であれば（S11でYes）、具体型Sが具体型Tへキャスト可能かどうかを判定し、その結果を返す（S12）。
　一方、入力されたS（所有型S）が具体型ではなく（S11でNo）、定数型であれば（S13でYes）、型検査部１４は、定数の型が具体型Tへキャスト可能かどうかを判定し、キャスト可能なら、その結果を返す（S14）。
　S14の後、型検査部１４は、定数の値がNULLで、T（具体型T）がポインター型であれば（S15でYes）、キャスト可と判定する（S24）。一方、型検査部１４は、定数の値がNULLで、T（具体型T）がポインター型でなければ（S15でNo）、キャスト不可と判定する（S25）。
　また、S13において、Sが定数型ではなく（S13でNo）、関数ポインター型である場合（S16でYes）、型検査部１４は、Tが関数ポインター型か否かを判定する（S17）。そして、Tが関数ポインター型である場合（S17でYes）、型検査部１４は、キャスト可と判定する（S24）。一方、Tが関数ポインター型ではない場合（S17でNo）、型検査部１４は、キャスト不可と判定する（S25）。
　また、Sが関数ポインター型ではなく（S16でNo）、&S´である場合（S18でYes）、型検査部１４は、S´が具体型か否かを判定する（S19）。ここで、型検査部１４が、S´は具体型と判定した場合（S19でYes）、具体型S´＊が具体型Tへキャスト可能かを判定し、その結果を返す（S20）。また、Sが関数ポインター型ではなく（S16でNo）、&S´でもない場合（S18でNo）、型検査部１４は、キャスト不可と判定する（S25）。
　一方、型検査部１４が、S´は具体型ではないと判定した場合（S19でNo）、具体型TがT´＊か否かを判定する（S21）。ここで、型検査部１４が具体型TはT´＊であり（S21でYes）、T´＝charであると判定した場合（S22でYes）、キャスト可と判定する（S24）。一方、型検査部１４が、T´＝charではないと判定した場合（S22でNo）、キャスト不可と判定する（S25）。また、型検査部１４が、具体型TはT´＊ではないと判定した場合（S21でNo）、具体型S´が具体型T´へキャスト可能か判定し、その結果を返す（S23）。
［命令解釈部］
　次に、図７を用いて命令解釈部１３の処理手順の例を説明する。なお、図７に示す処理における、命令解釈部１３への入力は、命令文および命令文における命令の箇所Lであり、命令解釈部１３からの出力は、型集合（TypeSet）であるものとして説明する。
　まず、命令解釈部１３は、命令におけるv＝new　Tである場合（S31でYes）、オブジェクトの初期化を行い、TypeSet（v@L)=｛T@L｝とする（S32）。例えば、命令解釈部１３は、オブジェクト中のフィールドT@L[i］を、型定義に従い再帰的に初期化し、型式T@Lで定義する。
　一方、命令におけるv＝new　Tではなく（S31でNo）、v＝wである場合（S33でYes）、命令解釈部１３は、変数の代入を行い、TypeSet（v@L)=｛w｝とする（S34）。例えば、命令解釈部１３は、変数wの型集合を文脈１５から取得し、変数vの型へキャスト可能か型検査を行い、型式wで定義する。
　また、命令におけるv=wではなく（S33でNo）、v=&(w->f)の場合（S35でYes）、命令解釈部１３はアドレス操作を行い、TypeSet（v）=｛&(S->ｆ)|S∈TypeSet(v)｝とする（S36）。例えば、命令解釈部１３は、変数wの型集合を文脈１５から取得し、各要素に対するC/C++フィールド参照規則の適用結果で定義する。
　また、命令におけるv=&(w->f)ではなく（S35でNo）、v=*wの場合（S37でYes）、命令解釈部１３はポインターの参照を行い、TypeSet（v@L)=｛*w｝とする（S38）。例えば、命令解釈部１３は、変数wの型集合を文脈１５から取得し、各要素にC/C++のポインター参照規則を適用し、変数vの型へキャスト可能か型検査を行い、型式*wで定義する。
　また、命令におけるv=*wではなく（S37でNo）、*v=wの場合（S39でYes）、命令解釈部１３はポインターの代入を行う（S40）。なお、このポインターの代入処理については、図８を用いて後記する。
　また、命令における*v=wではなく（S39でNo）、cという条件に応じて、命令の箇所Lへ移動する場合（S41でYes）、命令解釈部１３は、分岐先をキュー１６へ追加する（S42）。一方、cという条件に応じ、命令の箇所Lへ移動しない場合（S41でNo）、命令におけるv=f(a[1],…,a[n])であれば（S43でYes）、命令解釈部１３は関数を呼び出す（S44）。なお、この関数の呼び出し処理については、図９を用いて後記する。
　一方、命令におけるv=f(a[1],…,a[n])でなければ（S43でNo）、命令解釈部１３は、v=op(s[1],…,s[n])、TypeSet（v)＝｛op(T1,…,Tn))|Ti∈TypeSet(s[i])｝とする（S45）。また、命令解釈部１３は、その他の演算では、集合として回収してもよいし、その関係性を型式で表現してもよい。例えば、C++のdynamic_cast操作は、型検査を行い、失敗したらエラーを報告し、その型をnullポインター型へ変換する等の処理を行えばよい。
　［命令解釈部のポインター代入］
　次に、図８を用いて、図７のS40の処理の例を説明する。図７のS40において命令解釈部１３は、代入先の変数の型集合の要素それぞれに対して、代入処理を行う。ここでの代入処理とは、代入元の型集合が代入先の型へキャスト可能か型検査を行い、間接的なフィールド先も含め、代入先それぞれを、代入元の型集合で定義する処理のことである。
　なお、図８に示す処理において、命令解釈部１３への入力は、代入先*vと代入元wであり、命令解釈部１３からの出力は、型集合（TypeSet）であるものとして説明する。
　例えば、命令解釈部１３は、代入先*vの型集合TypeSet（v@L）を文脈１５から取得し、非ローカル変数以外をすべて展開する（S401）。また、命令解釈部１３は、代入元wの型集合TypeSet（w）を文脈１５から取得し、非ローカル変数以外をすべて展開する（S402）。
　S402の後、命令解釈部１３は、TypeSet(*v)、TypeSet(&w)が代入先のソースコード上の型へキャスト可能かどうか型検査を行う（S403）。その後、命令解釈部１３は、TypeSet(*v)に含まれる各変数v´に対して、TypeSet（v´@L)=TypeSet（w）とする処理を繰り返す（S404）。その後、*vがローカル変数でなければ（S405でNo）、命令解釈部１３は、処理を終了する。
　一方、*vがローカル変数であるが（S405でYes）、wはローカル変数でなければ（S406でNo）、命令解釈部１３は、TypeSet（*v@L)=TypeSet（w@L）とする（S407）。そして、処理を終了する。一方、wがローカル変数であれば（S406でYes）、命令解釈部１３は、TypeSet（*v@L)=｛w@L｝とする（S408）。なお、S408において、命令解釈部１３は、代入先*vと代入元wがローカル変数であれば、命令解釈部１３は、ローカル変数間の関係を記録する。
　［命令解釈部の関数呼び出し］
　次に、図９を用いて、図７のS44の処理の例を説明する。図７のS44において、命令解釈部１３は、関数ポインターの型集合の要素それぞれに対して、依存関係の解決を行いつつ、呼び出し処理を行い、呼び出し先としてキュー１６に追加する。
　ここで、命令解釈部１３は、関数ポインターと引数列間の依存関係を、例えば、Least　Common　Ancestorアルゴリズムを用いて解析する。そして、命令解釈部１３は、上記の解析により特定された先祖変数の型集合の中身を、射影機構atを用いて順に1つずつ射影していくことで、依存関係に応じた候補を絞り込む。これにより、命令解釈部１３は、仮想メソッドの呼び出しにおけるthisポインターの参照先を正確に列挙することができる。
　なお、ここでの呼び出し処理とは、引数列の型集合を、呼び出し先の仮引数へ代入する処理と、戻り値を受け取る場合は、呼び出し先の戻り値を代入する処理のことである。
　なお、図９に示す処理において、命令解釈部１３への入力は、代入先v（オプション）、関数ポインターf、引数列a[1],…,a[n]であり、命令解釈部１３からの出力は、型集合（TypeSet）であるものとして説明する。
　まず、命令解釈部１３は、関数ポインターfの型集合TypeSet(f)を文脈１５から取得し、関数ポインターかどうか型検査し、型式をすべて展開する（S441）。そして、命令解釈部１３は、TypeSet(f)中のグローバル関数へのポインター型Fに対して、以下に示すS443～S446の処理を繰り返す（S442）。
　まず、命令解釈部１３は、引数列a[1],…,a[n]の型集合を文脈１６から取得し、それぞれを呼び出し先の仮引数の型集合へ統合する（S443）。ここで、代入先vが存在する場合（S444でYes）、命令解釈部１３は、TypeSet(v)を呼び出し先の戻り値の型集合と統合する（S445）。そして、命令解釈部１３は、呼び出し先Fをキュー１６へ追加する（S446）。一方、代入先vが存在しない場合（S444でNo）、S445をスキップして、呼び出し先Fをキュー１６へ追加する（S446）。
　このようにすることで命令解釈部１３は、関数ポインターの型集合の要素それぞれに対して、依存関係の解決を行いつつ、呼び出し処理を行い、呼び出し先としてキュー１６に追加する。
［動作例］
　次に、図１０を用いて検知装置１０の動作例を説明する。一般にC++のプログラムにおいては、多様なデータを扱う場合は、クラスObjectを継承する形でArrayやNumberなどのデータを表現する。検知装置１０は、ユーザからデータを受け取った後、期待する型かどうかをC++のdynamic_castを用いて、確認する処理を挿入し、型の安全性を確認する
　例えば、検知装置１０は、図１０に示すソースコードを解釈すると、NULLでない分岐(A:　キャスト可)では、arrの型集合のうちNULLでない型のみを残し、NULLな分岐(B:　キャスト不可)では、NULLな型のみを残す（（１）条件分岐によるふるい落とし）。
　また、検知装置１０が、分岐中の変数のみを操作すると、ありえない組み合わせが発生する可能性があるため（例えば、(A)でobj:　Number*,　arr:　Array*等)、依存するobjの型集合も計算する。
　また、検知装置１０は、C++の継承と仮想メソッドを解析し、様々な型に応じた処理へ正しく振り分けることができる。また、検知装置１０は、オブジェクトから仮想メソッドのポインターを取り出し、引数でオブジェクトを渡す。例えば、検知装置１０は、objの型を１つずつ選び、仮想メソッドへのポインターを列挙し、処理を振り分けることで、依存関係を考慮した、型集合の計算を正確に行うことができる。
［システム構成等］
　また、図示した各部の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、CPU及び当該CPUにて実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
　また、前記した実施形態において説明した処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
［プログラム］
　前記した検知装置１０は、パッケージソフトウェアやオンラインソフトウェアとしてプログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記のプログラムを情報処理装置に実行させることにより、情報処理装置を各実施形態の検知装置１０として機能させることができる。ここで言う情報処理装置には、デスクトップ型又はノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やPHS（Personal　Handyphone　System）等の移動体通信端末、さらには、PDA（Personal　Digital　Assistant）等の端末等がその範疇に含まれる。
　また、検知装置１０は、ユーザが使用する端末装置をクライアントとし、当該クライアントに上記の処理に関するサービスを提供するサーバ装置として実装することもできる。この場合、サーバ装置は、Ｗｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の処理に関するサービスを提供するクラウドとして実装することとしてもかまわない。
　図１１は、検知プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、CPU１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ROM（Read　Only　Memory）１０１１及びRAM１０１２を含む。ROM１０１１は、例えば、BIOS（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
　ハードディスクドライブ１０９０は、例えば、OS１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の検知装置１０が実行する各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、検知装置１０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、SSDにより代替されてもよい。
　また、上述した実施形態の処理で用いられる各データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、CPU１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてRAM１０１２に読み出して実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してCPU１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワされたーク（LAN（Local　Area　Network）、WAN（Wide　Area　Network）等）を介して接続他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してCPU１０２０によって読み出されてもよい。
　１０　検知装置
　１１　ローダー部
　１２　トレーサー部
　１３　命令解釈部
　１４　型検査部
　１５　文脈

Claims (4)

  1. 　プログラムのソースコードを読み込むローダー部と、
    　前記読み込んだソースコードに抽象解釈を適用することにより、前記ソースコードの条件分岐で取り得る変数の型を収集し、依存型理論により前記変数間の依存関係を特定し、前記依存関係と前記条件分岐で用いられる条件を用いて、前記収集した型の集合のうち前記条件分岐先における型の集合のフィルタリングを行う命令解釈部と、
    　を備えることを特徴とする検知装置。
  2. 　前記型の集合の各要素がキャスト先の具体型へキャスト可能か否かを判定する型検査を行い、前記型検査の結果を出力する型検査部
    　をさらに備えることを特徴とする請求項１に記載の検知装置。
  3. 　前記命令解釈部は、
    　前記変数間の依存関係を特定する際、さらに、関数ポインターと引数列との間の依存関係を特定する
    　ことを特徴とする請求項１に記載の検知装置。
  4. 　プログラムのソースコードを読み込む工程と、
    　前記読み込んだソースコードに抽象解釈を適用することにより、前記ソースコードの条件分岐で取り得る変数の型を収集し、依存型理論により前記変数間の依存関係を特定し、前記依存関係と前記条件分岐で用いられる条件を用いて、前記収集した型の集合のうち、前記条件分岐先における型の集合のフィルタリングを行う工程と、
    　をコンピュータに実行させることを特徴とする検知プログラム。
PCT/JP2020/038543 2020-10-12 2020-10-12 検知装置、および、検知プログラム Ceased WO2022079779A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/038543 WO2022079779A1 (ja) 2020-10-12 2020-10-12 検知装置、および、検知プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/038543 WO2022079779A1 (ja) 2020-10-12 2020-10-12 検知装置、および、検知プログラム

Publications (1)

Publication Number Publication Date
WO2022079779A1 true WO2022079779A1 (ja) 2022-04-21

Family

ID=81207768

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/038543 Ceased WO2022079779A1 (ja) 2020-10-12 2020-10-12 検知装置、および、検知プログラム

Country Status (1)

Country Link
WO (1) WO2022079779A1 (ja)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
EICHBERG MICHAEL EICHBERG@INFORMATIK.TU-DARMSTADT.DE; HERMANN BEN HERMANN@CS.TU-DARMSTADT.DE; MEZINI MIRA MEZINI@INFORMATIK.TU-DAR: "Hidden truths in dead software paths", USER INTERFACE SOFTWARE AND TECHNOLOGY, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 30 August 2015 (2015-08-30) - 19 October 2016 (2016-10-19), 2 Penn Plaza, Suite 701 New York NY 10121-0701 USA , pages 474 - 484, XP058520005, ISBN: 978-1-4503-4531-6, DOI: 10.1145/2786805.2786865 *
FERRARA, P.: "Static type analysis of pattern matching by abstract interpretation", FORMAL TECHNIQUES FOR DISTRIBUTED SYSTEM, 2010 *
HIROSHI UNNO ; NAOKI KOBAYASHI: "Dependent type inference with interpolants", PRINCIPLES AND PRACTICE OF DECLARATIVE PROGRAMMING, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 7 September 2009 (2009-09-07) - 9 September 2009 (2009-09-09), 2 Penn Plaza, Suite 701 New York NY 10121-0701 USA , pages 277 - 288, XP058175038, ISBN: 978-1-60558-568-0, DOI: 10.1145/1599410.1599445 *

Similar Documents

Publication Publication Date Title
JP7776247B2 (ja) コード更新時におけるソースコード有効性のチェック
Lhoták et al. Points-to analysis with efficient strong updates
US20210073107A1 (en) Testing source code changes
US20130031531A1 (en) Method and system for performing backward-driven path-sensitive dataflow analysis
US10514898B2 (en) Method and system to develop, deploy, test, and manage platform-independent software
US20170308457A1 (en) Warning data management with respect to a development phase
US10831637B2 (en) Warning data management with respect to an execution phase
US10642583B2 (en) Development data management for a stream computing environment
Saltaformaggio et al. {DSCRETE}: Automatic rendering of forensic information from memory images via application logic reuse
US9459986B2 (en) Automatic generation of analysis-equivalent application constructs
US10614227B2 (en) Method and system for identifying functional attributes that change the intended operation of a compiled binary extracted from a target system
Kirbas et al. The relationship between evolutionary coupling and defects in large industrial software
US10977017B2 (en) Warning data management for distributed application development
CN115705250A (zh) 监测堆栈使用量以优化程序
JP6088031B2 (ja) 柔軟性の高いメタデータの合成
Yoo et al. Recovery of object oriented features from c++ binaries
US11947966B2 (en) Identifying computer instructions enclosed by macros and conflicting macros at build time
US20170308363A1 (en) Warning data management with respect to a compilation phase
JP7513116B2 (ja) コールグラフ作成装置、コールグラフ作成方法及びプログラム
Seifermann Architectural data flow analysis
US11983090B2 (en) Setting breakpoints for source code segments enclosed by macros
CN111240987A (zh) 移植程序检测方法、装置、电子设备及计算机可读存储介质
US20230281539A1 (en) Systems and methods for determining architecture drift
Raffa et al. Towards inter-service data flow analysis of serverless applications
CN110297639B (zh) 用于检测代码的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20957608

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20957608

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP