WO2022230074A1 - 検知装置、検知方法及び検知プログラム - Google Patents

検知装置、検知方法及び検知プログラム Download PDF

Info

Publication number
WO2022230074A1
WO2022230074A1 PCT/JP2021/016864 JP2021016864W WO2022230074A1 WO 2022230074 A1 WO2022230074 A1 WO 2022230074A1 JP 2021016864 W JP2021016864 W JP 2021016864W WO 2022230074 A1 WO2022230074 A1 WO 2022230074A1
Authority
WO
WIPO (PCT)
Prior art keywords
type
unit
program
location
automaton
Prior art date
Application number
PCT/JP2021/016864
Other languages
English (en)
French (fr)
Inventor
達大 青島
利宣 碓井
裕平 川古谷
誠 岩村
潤 三好
Original Assignee
日本電信電話株式会社
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 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2021/016864 priority Critical patent/WO2022230074A1/ja
Publication of WO2022230074A1 publication Critical patent/WO2022230074A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the present invention relates to a detection device, a detection method, and a detection program.
  • Non-Patent Document 1 there is known a union type inspection technology for a subset of the C language excluding pointer types (see, for example, Non-Patent Document 1).
  • Non-Patent Document 1 performs structural type checking, extracts the execution context from conditional statements and assignment statements, and verifies using a theoretical solver whether the extracted conditions satisfy the union type specifications. It is something to do.
  • Non-Patent Document 1 can support pointer types by using pointer analysis together and calculating candidates for pointers.
  • the theoretical solver may be a Satisfiability Modulo Theories (SMT) solver or the like.
  • a type confusion vulnerability is a bug that causes a program to confuse data types.
  • pointer analysis in conventional technology cannot correctly calculate the pointer's pointing destination, so there are cases where pointing candidates are overlooked or the number of pointing candidates becomes infinite. This can lead to missing vulnerabilities or endless analysis.
  • the types selected from the union type must be incompatible with each other (cannot be upcast in C and C++) and their conditions must be mutually exclusive (no more than two conditions must be satisfied together). .
  • the conventional technology cannot deal with classes having an inheritance relationship such as C++, which is seen in object-oriented systems.
  • a detection device detects, based on the code of a program, a predetermined condition indicating that type conversion is safe among places where type casting occurs in the program.
  • An enumeration unit that enumerates locations that do not satisfy the above, an extraction unit that extracts the context leading to the location by transitioning the automaton according to the locations enumerated by the enumeration unit, and the location extracted by the extraction unit, in advance and a verification unit that verifies whether the prepared annotation is satisfied.
  • FIG. 1 is a diagram showing a configuration example of a detection device according to the first embodiment.
  • FIG. 2 is a flowchart showing the flow of detection processing.
  • FIG. 3 is a diagram showing an example of sieve type notation.
  • FIG. 4 is a flow chart showing the flow of the castability relationship determination process.
  • FIG. 5 is a flow chart showing the flow of the partial relation determination process.
  • FIG. 6 is a flow chart showing the processing flow of the nested automaton.
  • FIG. 7 is a diagram showing an example of the syntax of the annotation description language.
  • FIG. 8 is a diagram showing an example of annotation.
  • FIG. 9 is a diagram for explaining an operation example.
  • FIG. 10 is a diagram illustrating an example of a computer that executes a detection program;
  • FIG. 1 is a diagram showing an example of the configuration of a detection device according to the first embodiment.
  • the detection device 10 receives input of source code and annotations, detects type confusion vulnerability, and outputs type confusion vulnerability candidate locations.
  • the source code is the IR code (intermediate code) of LLVM (reference URL: https://llvm.org/docs/index.html).
  • the detection device 10 has an interface section 11 , a storage section 12 and a control section 13 .
  • the interface unit 11 is an interface for inputting and outputting data.
  • the interface unit 11 is a NIC (Network Interface Card).
  • the interface unit 11 can transmit and receive data to and from other devices.
  • the interface unit 11 may be connected to an input device such as a mouse or a keyboard. Also, the interface unit 11 may be connected to an output device such as a display and a speaker.
  • the storage unit 12 is a storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), an optical disc, or the like. Note that the storage unit 12 may be a rewritable semiconductor memory such as RAM (Random Access Memory), flash memory, NVSRAM (Non Volatile Static Random Access Memory).
  • RAM Random Access Memory
  • flash memory Non Volatile Static Random Access Memory
  • the storage unit 12 stores an OS (Operating System) and various programs executed by the detection device 10 .
  • the storage unit 12 also stores annotation information 121 .
  • the annotation information 121 may be arbitrarily given by the user, but is not limited to that form.
  • the annotation information 121 may be stored in the detection device 10 in advance.
  • the control unit 13 controls the detection device 10 as a whole.
  • the control unit 13 includes, for example, electronic circuits such as CPU (Central Processing Unit), MPU (Micro Processing Unit), GPU (Graphics Processing Unit), ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array), etc. It is an integrated circuit.
  • the control unit 13 also has an internal memory for storing programs defining various processing procedures and control data, and executes each processing using the internal memory.
  • the control unit 13 functions as various processing units by running various programs.
  • the control unit 13 has an unsafe location enumeration unit 131 , a context extraction unit 132 and a vulnerability verification unit 133 .
  • the non-safe place listing unit 131 has a castability relationship determination unit 131a and a partial type relationship determination unit 131b.
  • FIG. 2 is a flowchart showing the flow of detection processing.
  • the detection device 10 receives input of source code and annotation (step S1).
  • the source code is SSA (Static Single Assignment) format code such as LLVMIR.
  • SSA Static Single Assignment
  • a local variable is assigned at most once.
  • the unsafe location enumeration unit 131 enumerates unsafe locations (structural type checking) (step S2).
  • the context extraction unit 132 extracts the context regarding the unsafe portion (step S3).
  • the vulnerability verification unit 133 verifies vulnerability using a theoretical solver and annotations (step S4).
  • the detection device 10 outputs vulnerability candidates (step S5).
  • non-safe location enumeration unit 131 Processing by the non-safe location enumeration unit 131, the context extraction unit 132, and the vulnerability verification unit 133 will be described in detail below.
  • the unsafe location enumeration unit 131 enumerates locations (non-safe locations) that do not satisfy a predetermined condition indicating that type conversion is safe among locations where type casting occurs in the program. do.
  • the non-safety place enumeration unit 131 is an example of an enumeration unit.
  • the non-safety location enumeration unit 131 enumerates non-safety locations by performing structural type checking on the source code.
  • the unsafe location enumeration unit 131 checks whether type confusion occurs at the type level with respect to type conversion that occurs in memory load, memory store, and argument passing of each instruction that can be specified from the source code. It is determined whether or not it is a point.
  • the non-safety location enumeration unit 131 is based on C and C++ language specifications and Physical Subtyping (Reference 1: Chandra, S., et al. (1999) "Physical Type Checking for C.”). method is used to determine unsafe locations.
  • the non-safe place enumeration unit 131 does not assume that the types of cast destinations and conditions are mutually exclusive, it can also handle classes that have an inheritance relationship.
  • the unsafe location enumeration unit 131 can safely handle pointer types and sieve types.
  • the non-safe place enumeration unit 131 determines the castability relationship and the subtype relationship between the cast source type and the cast destination type.
  • a sieve type is defined as a type that varies conditionally depending on the value of a variable.
  • Sieve types are also known as mathematical objects in academic discussions of the type systems of functional programming languages.
  • Reference 2 (Chugh, R., et al. (2012) "Nested refinements: a logic for dick typing.”) describes an implementation example of a sieve-type system. According to the sieve type system described in reference 2, it is possible to express the property of a tagged union that "the value type is determined when a certain condition is met".
  • tags and values are treated separately in the structure definitions of C and C++, which are the programming languages targeted by this embodiment.
  • C and C++ the process from memory allocation to initialization is sequential, and initialization is not performed when an object is created. Also, simply adding a pointer type to a conventional sieve type system does not guarantee security.
  • FIG. 3 is a diagram showing an example of sieve type notation.
  • each sieve type refined into fields has a separate notation.
  • the same sieve type appears in multiple structures possessed by a structure containing a sieve type. Therefore, by also recording the application location of the sieve type and the offset in the structure, those same sieve types can be distinguished. This makes it possible, for example, to not miss type confusion vulnerabilities, such as setting only a sieve-type tag in one location and a sieve-type value in another location.
  • the non-safe place listing unit 131 performs castability relationship determination processing, as shown in FIG. FIG. 4 is a flow chart showing the flow of the castability relationship determination process.
  • the non-safe place enumeration unit 131 outputs true if the type S can be cast to the type T by the processing in FIG. 4, and outputs false otherwise.
  • * means a pointer type.
  • the non-safe location enumeration unit 131 determines whether or not S is a subtype of T (step S212).
  • the unsafe location enumeration unit 131 determines whether or not S′ is a subtype of T′ (step S213). .
  • FIG. 5 is a flow chart showing the flow of the partial relation determination process.
  • the non-safe place enumeration unit 131 outputs true if the type S is a subtype of the type T, and outputs false otherwise, according to the processing in FIG. Note that in steps S212 and S213 of FIG. 4, the output from the process of FIG. 5 is output as it is.
  • the unsafe location enumeration unit 131 determines whether both S and T are sieve types (step S221).
  • step S221 If both S and T are sieve types (step S221, Yes), the non-safe place listing unit 131 determines that “S and T match” and “S and T ID match, S is DowncastSubtarget and T is DowncastTarget” (step S222).
  • the non-safe place enumeration unit 131 outputs true if it is determined to be true in step S222, and outputs false if it is determined not to be true.
  • step S221, No the non-safe place listing unit 131 determines whether or not T is a sieve type (step S223). If T is a sieve type (step S223, Yes), the unsafe location listing unit 131 outputs false (step S224).
  • the non-safe location listing unit 131 determines whether or not S is a sieve type (step S225).
  • step S225 If S is a sieve type (step S225, Yes), the non-safe place enumeration unit 131 determines whether the ID of S is CastTarget or DowncastTarget and the prototype of S is a subtype of T (step S226).
  • step S226 the non-safe location enumeration unit 131 outputs true if it is determined that the ID of S is CastTarget or DowncastTarget and the prototype of S is a subtype of T, otherwise it outputs false. .
  • the unsafe location enumeration unit 131 determines whether S is a subtype in the sense of physical subtyping of T (step S227).
  • the non-safe place enumeration unit 131 outputs true if it is determined in step S227 that S is a subtype in the sense of physical subtyping of T, and outputs false otherwise.
  • the context extraction unit 132 transitions the automaton according to the locations enumerated by the unsafe location enumeration unit 131, and extracts the context leading to the location.
  • Context extractor 132 is an example of an extractor.
  • the context extracting unit 132 traces instructions in reverse order for locations determined to be false by the unsafe location enumeration unit 131, that is, unsafe locations, and extracts execution contexts (conditions that can reach the unsafe locations) from conditional branches and assignment instructions. ).
  • the context extractor 132 can create arbitrarily complex and recursive expressions simply by designing a transition function that represents what to do when an instruction is seen in the state being extracted. Can be reconfigured.
  • the context extraction unit 132 stops subsequent analysis and outputs the automaton group generated so far.
  • Condition 1-1 When an instruction does not straddle a branch (when following a branch instruction, there are two or more branches exiting from the branch source block)
  • Condition 1-2 When a side effect is hit (when judged to be in an alias relationship by Typed Based Alias Analysis (TBAA)) (Reference 3: Diwan, A., et al. (1998) “Type based alias analysis.” PLDI.)
  • variable state automaton ⁇ VarState'' that identifies variables included in a conditional expression to be extracted and a conditional expression state automaton ⁇ CondState'' that indicates the structure of the conditional expression being extracted are prepared. .
  • the automaton "CondState” corresponds to the first automaton. Also, the automaton “VarState” corresponds to the second automaton.
  • ⁇ StartFrom(k, P, l) An instruction to store the result in the variable v.
  • the type is a pointer type P' to a sieve type
  • the ID of the sieve type. is id
  • Targetptr(k, Ident(id), &v[0][0],l) is transitioned to the state that has been transitioned once by the current instruction.
  • ⁇ Targetptr (k, t, p, l)): branch processing according to the given instruction (p &[i][o]).
  • Var (t, n) BinOp (o, Var (t, l), Var (t, r) for a binary operation instruction of type o that receives variables l and r and stores the result in variable v)
  • VarState Tigetptr (Load, t, &n[0][0], l) is transitioned once by the current instruction.
  • VarState transitions state s with a given command, and when it reaches state s', transitions to a state in which s is replaced with s'.
  • FIG. 6 is a flow chart showing the processing flow of the nested automaton. As shown in FIG. 6, first, the context extraction unit 132 sets the automaton set A to an empty set (step S301).
  • the context extraction unit 132 repeats the processing from step S302 to step S306 for each of the unsafe locations enumerated by the unsafe location enumeration unit 131.
  • the context extraction unit 132 extracts the instruction at point L (step S302).
  • the context extraction unit 132 then adds an automaton to A according to the instruction (step S303).
  • the context extraction unit 132 sets the ID of the sieve type to I and adds the automaton StartStore(I). Also, the context extracting unit 132 adds automaton StartBr(B) with B as the block name of the branch destination in the case of a conditional branch instruction.
  • the context extraction unit 132 transitions each automaton included in A with the current instruction (step S304).
  • the context extraction unit 132 then moves the location L to the immediately preceding instruction (step S305).
  • the context extraction unit 132 gives commands as inputs to the automaton and transfers (updates) the state of the automaton according to the definition of the automaton described above.
  • the context extraction unit 132 extracts conditions from the state of each automaton included in A, and connects them with conjunctions (AND) (step S307).
  • the vulnerability verification unit 133 verifies whether the location extracted by the context extraction unit 132 satisfies the annotation prepared in advance.
  • Vulnerability verification unit 133 is an example of a verification unit.
  • the vulnerability verification unit 133 performs verification using a theoretical solver.
  • Theoretical solver conservatively verifies whether a logical expression such as "If A is B" always holds (appropriate).
  • Constant means that when it is not possible to accurately determine whether a property holds or does not hold, the decision is made in one direction so as not to lead to pessimistic results. For example, when used in the context of finding vulnerabilities conservatively, we show that vulnerabilities can be determined to be vulnerabilities even though they are not overlooked.
  • the theoretical solver in this embodiment may be sound, and may be, for example, a general SMT solver (Z3, CVC4, etc. as an implementation).
  • the SMT solver is a type of theoretical solver, and it performs verification by (wisely) substituting various values for the variables of the logical formula to see if it holds.
  • the vulnerability verification unit 133 uses the execution context extracted by the context extraction unit 132 to verify whether the annotation specifications are satisfied, and outputs a warning if it cannot be determined that they are satisfied. For example, the vulnerability verification unit 133 outputs a list of locations that do not satisfy annotation specifications.
  • the vulnerability verification unit 133 can use the type checking algorithm of the existing sieve type system as it is as the verification algorithm (for example, Reference 4 (Chugh, R., et al. "Nested Refinements for Dynamic Languages.” POPL' 12, Section 4)).
  • annotations can be described by defining conditions for tagged unions as sieve types.
  • the vulnerability verification unit 133 verifies whether or not the location satisfies the annotation described by defining the tagged union condition as a sieve type.
  • Annotations allow the definition of new sieve types by restricting existing sieve types, allowing for patterns that do not need to check tags when in fact only certain kinds of types are stored in a sieve type. .
  • ⁇ Pattern Cast When the tag variable area and the value area are mutually exclusive
  • ⁇ Pattern Downcast When the tag variable area is truly included in the value area ⁇ However, the cast destination is a subtype of the cast source.
  • ⁇ Pattern Restrict When applying a sieve type to restrict an existing sieve type ⁇ Simply narrow down the candidates for the cast destination type, and the handling of the sieve type before restriction will be followed.
  • FIG. 7 is a diagram showing an example of the syntax of the annotation description language.
  • FIG. 8 is a diagram showing an example of annotation.
  • FIG. 9 is a diagram explaining an operation example.
  • FIG. 9 shows an operation example when a source code in a predetermined language (here, Lua 5.4.0) is actually input to the detection device 10 of this embodiment.
  • the unsafe location listing unit 131 lists cast locations (unsafe locations) that are not necessarily safe.
  • the context extraction unit 132 uses nested automaton to extract the conditional execution context in which the unsafe portion is executed.
  • the vulnerability verification unit 133 extracts conditions from the terminal conditions of the automaton and verifies whether the specifications are satisfied by a theoretical solver.
  • the unsafe location enumeration unit 131 selects, based on the code of the program, the locations where type casting occurs in the program that does not satisfy a predetermined condition indicating that the type conversion is safe. List the places.
  • the context extraction unit 132 transitions the automaton according to the locations enumerated by the unsafe location enumeration unit 131, and extracts the context leading to the location.
  • the vulnerability verification unit 133 verifies whether the location extracted by the context extraction unit 132 satisfies annotations prepared in advance.
  • the detection device 10 can detect type confusion vulnerabilities by assuming the existence of pointers by the above method. As a result, according to this embodiment, type confusion vulnerability can be detected effectively.
  • the non-safe location enumeration unit 131 determines the castability relationship and the subtype relationship between the cast source type and the cast destination type. This allows safe handling even when both pointer and sieve types are present.
  • the context extraction unit 132 recursively identifies the variable using the second automaton that identifies the variable.
  • arbitrarily complex and recursive expressions can be reconfigured simply by designing how to process (transition function) when an instruction is seen while extracting a conditional expression in one of the automatons.
  • the vulnerability verification unit 133 verifies whether or not the annotation described as a sieve type for the condition of the tagged union is satisfied at the locations enumerated by the non-safe location enumeration unit 131 . This allows verification without fixing the sieve type data structure.
  • each component of each device illustrated is functionally conceptual, and does not necessarily need to be physically configured as illustrated.
  • the specific form of distribution and integration of each device is not limited to the illustrated one, and all or part of them can be functionally or physically distributed or Can be integrated and configured.
  • all or any part of each processing function performed by each device is realized by a CPU (Central Processing Unit) and a program analyzed and executed by the CPU, or hardware by wired logic can be realized as Note that the program may be executed not only by the CPU but also by other processors such as a GPU.
  • CPU Central Processing Unit
  • the detection device 10 can be implemented by installing a detection program that executes the above-described detection processing as package software or online software on a desired computer.
  • the information processing device can function as the detection device 10 by causing the information processing device to execute the detection program.
  • the information processing apparatus referred to here includes a desktop or notebook personal computer.
  • information processing devices include mobile communication terminals such as smartphones, mobile phones and PHS (Personal Handyphone Systems), and slate terminals such as PDAs (Personal Digital Assistants).
  • the detection device 10 can also be implemented as a detection server device that uses a terminal device used by a user as a client and provides the client with services related to the above-described detection processing.
  • the detection server device is implemented as a server device that provides a detection service that receives source code as input and outputs candidates for type confusion vulnerability.
  • the detection server device may be implemented as a web server, or may be implemented as a cloud that provides services related to the detection processing by outsourcing.
  • FIG. 10 is a diagram showing an example of a computer that executes a detection program.
  • the computer 1000 has a memory 1010 and a CPU 1020, for example.
  • Computer 1000 also has hard disk drive interface 1030 , disk drive interface 1040 , serial port interface 1050 , video adapter 1060 and network interface 1070 . These units are connected by a bus 1080 .
  • the memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012 .
  • the ROM 1011 stores a boot program such as BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • Hard disk drive interface 1030 is connected to hard disk drive 1090 .
  • a disk drive interface 1040 is connected to the disk drive 1100 .
  • a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100 .
  • Serial port interface 1050 is connected to mouse 1110 and keyboard 1120, for example.
  • Video adapter 1060 is connected to display 1130, for example.
  • the hard disk drive 1090 stores, for example, an OS 1091, application programs 1092, program modules 1093, and program data 1094. That is, a program that defines each process of the detection device 10 is implemented as a program module 1093 in which computer-executable code is described. Program modules 1093 are stored, for example, on hard disk drive 1090 .
  • the hard disk drive 1090 stores a program module 1093 for executing processing similar to the functional configuration in the detection device 10 .
  • the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
  • the setting data used in the processing of the above-described embodiment is stored as program data 1094 in the memory 1010 or the hard disk drive 1090, for example. Then, the CPU 1020 reads the program modules 1093 and program data 1094 stored in the memory 1010 and the hard disk drive 1090 to the RAM 1012 as necessary, and executes the processes of the above-described embodiments.
  • the program modules 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program modules 1093 and program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). Program modules 1093 and program data 1094 may then be read by CPU 1020 through network interface 1070 from other computers.
  • LAN Local Area Network
  • WAN Wide Area Network

Landscapes

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

Abstract

非安全箇所列挙部（１３１）は、プログラムのコードを基に、プログラムにおいて型のキャストが発生する箇所のうち、型変換が安全であることを示す所定の条件を満たさない箇所を列挙する。文脈抽出部（１３２）は、非安全箇所列挙部（１３１）によって列挙された箇所に応じたオートマトンを遷移させ、当該箇所に至る文脈を抽出する。脆弱性検証部（１３３）は、文脈抽出部（１３２）によって抽出された箇所が、あらかじめ用意されたアノテーションを満たすか否かを検証する。

Description

検知装置、検知方法及び検知プログラム
　本発明は、検知装置、検知方法及び検知プログラムに関する。
　従来、ポインター型などを除くＣ言語のサブセットに対するunion型の検査技術が知られている（例えば、非特許文献１を参照）。
　非特許文献１に記載の技術は、構造的型検査を行いつつ、条件文や代入文から実行文脈を抽出し、抽出した条件がunion型の仕様を満たすかどうかを、理論ソルバーを用いて検証するものである。
　さらに、非特許文献１に記載の技術は、ポインター解析を併用し、ポインターの指し先の候補を計算することで、ポインター型へ対応することができる。また、理論ソルバーは、Satisfiability　Modulo　Theories（ＳＭＴ）ソルバー等であってよい。
Jhala　,　R.,　et　al.　(2007)　"State　of　the　Union:　Type　Inference　Via　Craig　Interpolation."　TACAS.
　しかしながら、従来の技術には、型混同脆弱性の検知を効果的に行うことができない場合があるという問題がある。型混同脆弱性は、プログラムがデータの型を混同してしまうバグである。
　コンピュータはあらゆるデータを０と１で表現するため、そのデータが数値であるか文字であるか画像であるか、等を区別することはできず、プログラムがそのデータの型を決定する。
　そのため、例えばコンピュータが整数とポインターを混同すると、攻撃者が用意した数値（整数）を、データやプログラムの場所アドレスを示すもの（ポインター）と誤解させることがある。これにより、データの漏洩、改ざん、悪意のある任意コード実行が発生する危険性がある。
　例えば、従来の技術では、ポインターが存在しないと仮定するため、表面上は全く別のポインター変数経由でunion型の値やタグ変数の書き換えができてしまうという問題がある。
　また、従来の技術におけるポインター解析は、ポインターの指し先を正しく計算できないため、指し先の候補を見逃したり、指し先の候補が無限個になる場合がある。これにより、脆弱性を見逃すことや、解析が終わらなくなってしまうことが起こる。
　さらに、union型から選択される型は互いに互換性がなく（Ｃ及びＣ＋＋におけるアップキャスト不可能）、その条件も互いに排反（２つ以上の条件を共に満たすことはない）である必要がある。このため、従来の技術では、オブジェクト指向で見られるＣ＋＋等の継承関係を持つクラスに対応できない。
　上述した課題を解決し、目的を達成するために、検知装置は、プログラムのコードを基に、前記プログラムにおいて型のキャストが発生する箇所のうち、型変換が安全であることを示す所定の条件を満たさない箇所を列挙する列挙部と、前記列挙部によって列挙された箇所に応じたオートマトンを遷移させ、当該箇所に至る文脈を抽出する抽出部と、前記抽出部によって抽出された箇所が、あらかじめ用意されたアノテーションを満たすか否かを検証する検証部と、を有することを特徴とする。
　本発明によれば、型混同脆弱性の検知を効果的に行うことができる。
図１は、第１の実施形態に係る検知装置の構成例を示す図である。 図２は、検知処理の流れを示すフローチャートである。 図３は、篩型の表記の例を示す図である。 図４は、キャスト可能関係の判定処理の流れを示すフローチャートである。 図５は、部分関係の判定処理の流れを示すフローチャートである。 図６は、入れ子オートマトンの処理の流れを示すフローチャートである。 図７は、アノテーションの記述言語の構文の例を示す図である。 図８は、アノテーションの例を示す図である。 図９は、動作例を説明する図である。 図１０は、検知プログラムを実行するコンピュータの一例を示す図である。
　以下に、本願に係る検知装置、検知方法及び検知プログラムの実施形態を図面に基づいて詳細に説明する。なお、本発明は、以下に説明する実施形態により限定されるものではない。
［第１の実施形態の構成］
　まず、図１を用いて、第１の実施形態に係る検知装置の構成について説明する。図１は、第１の実施形態に係る検知装置の構成の一例を示す図である。図１に示すように、検知装置１０は、ソースコードとアノテーションの入力を受け付け、型混同脆弱性の検知を行い、型混同脆弱性の候補箇所を出力する。
　例えば、ソースコードはＬＬＶＭ（参考ＵＲＬ：https://llvm.org/docs/index.html）のＩＲコード（中間コード）である。
　ここで、検知装置１０の各部について説明する。図１に示すように、検知装置１０は、インタフェース部１１、記憶部１２及び制御部１３を有する。
　インタフェース部１１は、データの入力及び出力のためのインタフェースである。例えば、インタフェース部１１はＮＩＣ（Network　Interface　Card）である。インタフェース部１１は他の装置との間でデータの送受信を行うことができる。
　また、インタフェース部１１は、マウスやキーボード等の入力装置と接続されていてもよい。また、インタフェース部１１は、ディスプレイ及びスピーカ等の出力装置と接続されていてもよい。
　記憶部１２は、ＨＤＤ（Hard　Disk　Drive）、ＳＳＤ（Solid　State　Drive）、光ディスク等の記憶装置である。なお、記憶部１２は、ＲＡＭ（Random　Access　Memory）、フラッシュメモリ、ＮＶＳＲＡＭ（Non　Volatile　Static　Random　Access　Memory）等のデータを書き換え可能な半導体メモリであってもよい。
　記憶部１２は、検知装置１０で実行されるＯＳ（Operating　System）や各種プログラムを記憶する。また、記憶部１２は、アノテーション情報１２１を記憶する。なお、アノテーション情報１２１は、ユーザによって任意に与えられるものであってもよいが、その形態に限られない。例えば、アノテーション情報１２１は、あらかじめ検知装置１０に記憶されているものであってもよい。
　制御部１３は、検知装置１０全体を制御する。制御部１３は、例えば、ＣＰＵ（Central　Processing　Unit）、ＭＰＵ（Micro　Processing　Unit）、ＧＰＵ（Graphics　Processing　Unit）等の電子回路や、ＡＳＩＣ（Application　Specific　Integrated　Circuit）、ＦＰＧＡ（Field　Programmable　Gate　Array）等の集積回路である。また、制御部１３は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、内部メモリを用いて各処理を実行する。
　制御部１３は、各種のプログラムが動作することにより各種の処理部として機能する。例えば、制御部１３は、非安全箇所列挙部１３１、文脈抽出部１３２、及び脆弱性検証部１３３を有する。また、非安全箇所列挙部１３１は、キャスト可能関係判定部１３１ａ及び部分型関係判定部１３１ｂを有する。
　図２を用いて、検知装置１０による検知処理の流れを説明する。図２は、検知処理の流れを示すフローチャートである。図２に示すように、まず、検知装置１０はソースコードとアノテーションの入力を受け付ける（ステップＳ１）。
　例えば、ソースコードは、ＬＬＶＭＩＲのようなＳＳＡ（Static　Single　Assignment：静的単一代入）形式のコードである。ＳＳＡ形式のコードでは、ローカル変数は高々１回のみ代入される。
　次に、非安全箇所列挙部１３１は、非安全箇所の列挙（構造的型検査）を行う（ステップＳ２）。続いて、文脈抽出部１３２は、非安全箇所に関する文脈の抽出を行う（ステップＳ３）。そして、脆弱性検証部１３３は、理論ソルバー及びアノテーションによる脆弱性の検証を行う（ステップＳ４）。検知装置１０は、脆弱性候補を出力する（ステップＳ５）。
　以下、非安全箇所列挙部１３１、文脈抽出部１３２、及び脆弱性検証部１３３による処理について詳細に説明する。
　非安全箇所列挙部１３１は、プログラムのコードを基に、プログラムにおいて型のキャストが発生する箇所のうち、型変換が安全であることを示す所定の条件を満たさない箇所（非安全箇所）を列挙する。非安全箇所列挙部１３１は、列挙部の一例である。
　非安全箇所列挙部１３１は、ソースコードに対して構造的型検査を実施することにより非安全箇所を列挙する。
　これにより、型の構造だけを見て安全であると判定できる命令の箇所が、後段の分析対象から取り除かれ、検知処理全体の効率が向上する。
　非安全箇所列挙部１３１は、ソースコードから特定可能な各命令のメモリロード、メモリストア、引数渡しにおいて発生する型変換について、型レベルで型混同が発生しないか、すなわち各命令の箇所が非安全箇所であるか否かを判定する。
　例えば、非安全箇所列挙部１３１は、ＣやＣ＋＋の言語仕様とそれに基づくPhysical　Subtyping（参考文献１：Chandra,　S.,　et　al.　(1999)　"Physical　Type　Checking　for　C."）をベースとする手法を用いて非安全箇所の判定を行う。また、非安全箇所列挙部１３１はキャスト先の型や条件の排反性を仮定しないため、継承関係を持つクラスにも対応できる。
　Physical　Subtypingを用いることで、非安全箇所列挙部１３１はポインター型と篩型を安全に取り扱うことができる。非安全箇所列挙部１３１は、キャスト元の型とキャスト先の型について、キャスト可能関係の判定及び部分型関係の判定を行う。
　ここで、篩型について説明する。篩型は、変数の値に依存して条件によって変わる型と定義される。また、篩型は、関数型プログラミング言語の型システムを学術的に議論する上での数学的な対象として知られている。
　例えば、参考文献２（Chugh　,　R.,　et　al.　(2012)　"Nested　refinements:　a　logic　for　dick　typing."）には、篩型システムの実装例が記載されている。参考文献２に記載の篩型システムによれば、タグ付きunionの「ある条件を満たすときに値の型が決まる」という性質を表現することができる。
　ただし、従来の篩型システムでは、タグと値を不可分なものとして扱っている点、オブジェクト作成時に初期化を強制する点、ポインター型が存在しない点で、本実施形態にはそのまま適用することができない。
　例えば、本実施形態の対象となるプログラミング言語であるＣ及びＣ＋＋の構造体の定義ではタグと値は別々に扱われる。また、Ｃ及びＣ＋＋では、メモリ確保から初期化までが逐次的であり、オブジェクト作成時に初期化はされない。また、従来の篩型システムにポインター型を追加するだけでは安全性が保証されない。
　本実施形態では、篩型は、図３のように表記される。図３は、篩型の表記の例を示す図である。ここで、フィールドへ詳細化された篩型はそれぞれで別の表記を持つ。
　また、篩型を含む構造体が持つ複数の構造体には、同じ篩型が現れる。そのため、篩型の適用箇所と構造体中のオフセットも記録することで、それらの同じ篩型を区別することができる。これにより、例えば、ある場所にある篩型のタグと別の場所にある篩型の値だけを設定するような型混同脆弱性を見逃さないようにすることができる。
　非安全箇所列挙部１３１は、図４に示すように、キャスト可能関係の判定処理を行う。図４は、キャスト可能関係の判定処理の流れを示すフローチャートである。非安全箇所列挙部１３１は、図４の処理により、型Ｓが型Ｔにキャスト可能であれば真を出力し、そうでない場合は偽を出力する。
　図４に示すように、まず、非安全箇所列挙部１３１は、Ｓ＝Ｓ’＊かつＴ＝Ｔ’＊が満たされるか否かを判定する（ステップＳ２１１）。ただし、＊はポインター型を意味する。
　Ｓ＝Ｓ´＊かつＴ＝Ｔ´＊が満たされない場合（ステップＳ２１１、Ｎｏ）、非安全箇所列挙部１３１は、ＳがＴの部分型であるか否かを判定する（ステップＳ２１２）。
　Ｓ＝Ｓ´＊かつＴ＝Ｔ´＊が満たされる場合（ステップＳ２１１、Ｙｅｓ）、非安全箇所列挙部１３１は、Ｓ´がＴ´の部分型であるか否かを判定する（ステップＳ２１３）。
　図５を用いて、図４のステップＳ２１２及びステップＳ２１３に相当する部分型の判定方法を説明する。図５は、部分関係の判定処理の流れを示すフローチャートである。
　非安全箇所列挙部１３１は、図５の処理により、型Ｓが型Ｔの部分型であれば真を出力し、そうでない場合は偽を出力する。なお、図４のステップＳ２１２及びステップＳ２１３では、図５の処理による出力がそのまま出力される。
　図５に示すように、非安全箇所列挙部１３１は、ＳとＴがいずれも篩型であるか否かを判定する（ステップＳ２２１）。
　ＳとＴがいずれも篩型である場合（ステップＳ２２１、Ｙｅｓ）、非安全箇所列挙部１３１は、「ＳとＴが一致」、及び「ＳとＴのＩＤが一致し、ＳがDowncastSubtargetでＴがDowncastTarget」のいずれかが成り立つか否かを判定する（ステップＳ２２２）。
　非安全箇所列挙部１３１は、ステップＳ２２２において成り立つと判定した場合は真を出力し、成り立たないと判定した場合は偽を出力する。
　ＳとＴのいずれかが篩型でない場合（ステップＳ２２１、Ｎｏ）、非安全箇所列挙部１３１は、Ｔが篩型であるか否かを判定する（ステップＳ２２３）。Ｔが篩型である場合（ステップＳ２２３、Ｙｅｓ）、非安全箇所列挙部１３１は、偽を出力する（ステップＳ２２４）。
　Ｔが篩型でない場合（ステップＳ２２３、Ｎｏ）、非安全箇所列挙部１３１は、Ｓが篩型であるか否かを判定する（ステップＳ２２５）。
　Ｓが篩型である場合（ステップＳ２２５、Ｙｅｓ）、非安全箇所列挙部１３１は、ＳのＩＤがCastTargetかDowncastTargetであり、Ｓの原型がＴの部分型であるか否かを判定する（ステップＳ２２６）。
　非安全箇所列挙部１３１は、ステップＳ２２６において、ＳのＩＤがCastTargetかDowncastTargetであり、Ｓの原型がＴの部分型であると判定した場合は真を出力し、そうでない場合は偽を出力する。
　Ｓが篩型でない場合（ステップＳ２２５、Ｎｏ）、非安全箇所列挙部１３１は、ＳがＴのPhysical　Subtypingの意味で部分型であるか否かを判定する（ステップＳ２２７）。
　非安全箇所列挙部１３１は、ステップＳ２２７において、ＳがＴのPhysical　Subtypingの意味で部分型であると判定した場合は真を出力し、そうでない場合は偽を出力する。
　文脈抽出部１３２は、非安全箇所列挙部１３１によって列挙された箇所に応じたオートマトンを遷移させ、当該箇所に至る文脈を抽出する。文脈抽出部１３２は、抽出部の一例である。
　文脈抽出部１３２は、非安全箇所列挙部１３１によって偽と判定された箇所、すなわち非安全箇所について、命令を逆順に辿り、条件分岐や代入命令から実行文脈（当該非安全箇所へ到達しうる条件）を抽出する。
　文脈抽出部１３２は、オートマトンの状態を入れ子にすることにより、抽出中の状態で命令を見たときにどう処理するかを表す推移関数を設計するだけで、任意に複雑で再帰的な式を再構成できる。
　文脈抽出部１３２は、下記の条件のいずれかが満たされた場合、以降の解析を停止し、そこまでに生成したオートマトン群を出力する。
（条件１－１）命令が分岐を跨がない場合（分岐命令へ辿るときに、その分岐元のブロックから出る分岐が２本以上）
（条件１－２）副作用にヒットした場合（Typed　Based　Alias　Analysis（ＴＢＡＡ）によりエイリアス関係にあると判断されたとき）（参考文献３：Diwan　,　A.,　et　al.　(1998)　“Type　based　alias　analysis.”　PLDI.）
　ここで、オートマトンの定義を説明する。本実施形態では、抽出したい条件式に含まれる変数を特定する変数の状態のオートマトン「VarState」と、抽出中の条件式の構造を示す条件式の状態のオートマトン「CondState」と、が用意される。
　本実施形態では、オートマトン「CondState」により条件式を抽出しているとき、変数が現れれば、オートマトン「VarState」を含む状態へ遷移し、再帰的な式の実行と変数の抽出を同時に行う。このことから、本実施形態のオートマトンは、入れ子オートマトンと呼ばれる場合がある。
　オートマトン「CondState」は第１のオートマトンに相当する。また、オートマトン「VarState」は第２のオートマトンに相当する。
　以下に、入れ子オートマトンに関する定義を示す。
＜共通の定義＞
◆ターゲット変数の状態ｔ：Unknown（未特定）かSearchIdent（特定中）、Ident（ｉｄ）（篩型のＩＤ　ｉｄが候補）のいずれか
◆フィールドへのポインターｐ＝＆ｎ［ｉ］［ｏ］：変数名ｎをポインター変数とみなし、インデックスをｉ、オフセットをｏとした先のフィールドへのポインターのこと
◆キャストの種類ｋ：Downcast、Load、Storeのいずれか
＜オートマトン「VarState」に関する定義＞
まず、オートマトンの状態の定義は以下の通り。
◆［初期状態］StartFrom（ｋ，Ｐ，ｌ）：命令の箇所ｌ、キャストの種類ｋに起因し、ポインター型Ｐから遷移を始めることを示す状態
◆Targetptr（ｋ，ｔ，ｐ，ｌ）：命令の箇所ｌ、キャストの種類ｋに起因し、ターゲット変数の状態がｔであり、フィールドへのポインターがｐであることを示す状態
◆Deref（ｓ）：VarStateの状態ｓをデリファレンス（ポインター参照）した結果を示す状態
◆［終端状態］Baseptr（Ｔ，ｐ，ｌ）：命令の箇所ｌで、フィールドへのポインターｐは篩型Ｔを持つことを示す状態
◆［終端状態］HitSideEffect（ｓ，ｌ）：命令の箇所ｌで、VarStateの状態ｓは副作用にヒットし、異常終了したことを示す状態
◆［終端状態］Failed（ｓ，ｌ）：命令の箇所ｌで、CondStateの状態ｓが異常終了した状態
次にオートマトンの状態推移関数の定義は次の通り。
◆StartFrom（ｋ，Ｐ，ｌ）：変数ｖへ結果を格納する命令で、その型が篩型へのポインター型Ｐ’のとき、ＰとＰ’が篩型として一致するなら、篩型のＩＤをｉｄとし、Targetptr（ｋ，Ident（ｉｄ），＆ｖ［０］［０］，ｌ）を現在の命令で１回推移した状態へ推移する。
◆Targetptr（ｋ，ｔ，ｐ，ｌ））：与えられた命令に応じて処理を分岐する（ｐ＝＆［ｉ］［ｏ］とする。
　■ポインター型Ｐ（＝Ｔ＊）の変数ｖからの変数ｎへのロード命令のとき、ＴＢＡＡに従い、Ｐが、すでに解析されたストア命令群による副作用にヒットしない場合、ｐ’＝＆（＊ｖ）［ｉ］［ｐ］とし、
　　■ｔ＝Ident（＿）でないか、Ｐの篩型のＩＤをｉｄとして、ｔ＝Ident（ｉｄ）のとき、Baseptr（Ｔ，ｐ’，ｌ）へ推移する。
　　■ｔ＝Ident（＿）でないとき、Targetptr（ｋ，SearchIdent，ｐ’，ｌ）へ推移する。
　　■ｔ＝Ident（Ｔ）のとき、Baseptr（Ｔ，ｐ’，ｌ）へ推移する。
　■ポインター算術命令のとき、ｐがポインター算術の結果となるように、ベースポインターｐ’＝＆ｎ’［ｉ’］［ｏ’］を求め、ｐとｐ’へ置き変えた状態へ推移する。
◆Deref（ｓ）状態ｓを与えられた命令で推移し、状態ｓ’となるとき、ｓをｓ’で置き変えた状態へ推移する。
＜オートマトン「CondState」に関する定義＞
まず、オートマトンの状態の定義は以下の通り。
◆［初期状態］StartBr（Ｂ）：ブロック名Ｂに分岐しうる命令にいることを示す状態
◆［初期状態］StartStore（ｉｄ）：篩型のＩＤ　ｉｄへのstore命令にいることを示す状態
◆CondVar（ｎ，ｖ）：変数名ｖへ格納される条件式の抽出を行う状態（ｎは条件式の否定の有無）
◆Store（ｌ，Ｐ，Ｔ，ｓ，ｔ）：命令の箇所ｌにおいて、型Ｔの値が篩型へのポインター型Ｐへ代入されたときに、代入元（又は代入先）に対するCondStateの状態ｓ（又はｔ）を持つ状態
◆BinOp（ｏ，ｌ，ｒ）：種類ｏの二項演算子式であり、左辺又は右辺に対するCondStateの状態ｌ（又はｒ）を持つ状態
◆CmpOp（ｏ，ｌ，ｒ）：種類ｏの比較演算子式であり、左辺又は右辺に対するCondStateの状態ｌ（又はｒ）を持つ状態
◆Deref（ｓ）：CondStateの状態ｓをデリファレンスした結果を示す状態
◆Var（ｔ，ｎ）：変数名ｎを探しているときに、ターゲットの状態がｔである状態
◆VarState（ｓ）：VarStateの状態ｓを持つ状態
◆［終端状態］Const（ｃ）：定数ｃを示す状態
◆［終端状態］Failed（ｓ，ｌ）：命令の箇所ｌで、CondStateの状態ｓが異常終了した状態
次にオートマトンの状態推移関数の定義は次の通り。
◆StartBr（Ｂ）：変数ｎに依存する条件分岐命令であるとき、分岐先Ｂがｔｒｕｅの分岐先かどうかを示す真偽値ｃを特定し、CondVar（ｃ，ｎ）へ推移する。
◆StartStore（ｉｄ）：型Ｓの変数ｖをポインター型Ｐの変数ｖ’へ代入するストア命令のとき、ＴＢＡＡに従い、Ｔが、すでに解析されたストア命令群による副作用にヒットしない場合、Store（ｌ，Ｐ，Ｓ，Var（ｔ，ｖ），Var（Ident（ｉｄ，ｖ’）へ推移する。ここで、値ｖが篩型であるなら、篩型のＩＤ　ｉｄを用いて、ｔ＝Ident（ｉｄ）とし、そうでなければ、ｔ＝Unknownとする。
◆CondVar（ｎ，ｖ）：変数ｌ，ｒを比較し、変数ｖへ結果を格納する、種類ｏの命令のとき、ｎで種類ｏを否定して、CmpOp（ｏ’，Var（Unknown，ｌ），Var（Unknown，ｒ））へ推移する。
◆Var（ｔ，ｎ）：変数ｌ，ｒを受け取り、変数ｖへ結果を格納する、種類ｏの二項演算命令のとき、BinOp（ｏ，Var（ｔ，ｌ），Var（ｔ，ｒ）へ推移する。それ以外の変数ｖへ結果を格納する命令のとき、VarState（Targetptr（Load，ｔ，＆ｎ［０］［０］，ｌ）を現在の命令で一回推移した状態へ推移する。
◆Store（Ｌ，Ｐ，Ｔ，ｓ，ｔ），BinOp（ｏ，ｌ，ｒ），CmpOp（ｏ，ｌ，ｒ）：状態ｌ，ｒをそれぞれ与えられた命令で推移し、状態ｌ’，ｒ’となるとき、ｌ，ｒをそれぞれｌ’，ｒ’で置き変えた状態へ推移する。
◆Deref（ｓ），VarState（状態ｓを与えられた命令で推移し、状態ｓ’となるとき、ｓをｓ’で置き変えた状態へ推移する。
　図６は、入れ子オートマトンの処理の流れを示すフローチャートである。図６に示すように、まず、文脈抽出部１３２は、オートマトンの集合Ａを空集合に設定する（ステップＳ３０１）。
　文脈抽出部１３２は、非安全箇所列挙部１３１によって列挙された非安全箇所のそれぞれについて、ステップＳ３０２からステップＳ３０６までの処理を繰り返す。
　文脈抽出部１３２は、箇所Ｌの命令を取り出す（ステップＳ３０２）。そして、文脈抽出部１３２は、命令に応じてＡへオートマトンを追加する（ステップＳ３０３）。
　文脈抽出部１３２は、ストア命令のとき、ストア先の型が篩型であれば、その篩型のＩＤをＩとし、オートマトンStartStore（Ｉ）を追加する。また、文脈抽出部１３２は、条件分岐命令のとき、分岐先のブロック名をＢとして、オートマトンStartBr（Ｂ）を追加する。
　続いて、文脈抽出部１３２は、Ａに含まれる各オートマトンを現在の命令で遷移させる（ステップＳ３０４）。そして、文脈抽出部１３２は、箇所Ｌを直前の命令へ移す（ステップＳ３０５）。
　文脈抽出部１３２は、前述のオートマトンの定義に従い、命令をオートマトンへの入力として与え、オートマトンの状態を移す（更新する）。
　文脈抽出部１３２は、Ａに含まれる各オートマトンの状態から条件を抽出し、連言（ＡＮＤ）でつなげる（ステップＳ３０７）。
　このとき、文脈抽出部１３２は、オートマトンの定義に従い、下記のように状態から条件式を抽出し、出力する。
◆オートマトンStore（＿，＿，＿，Ｌ，Ｒ）から、ＬとＲの条件式をオートマトンの意味通りに抽出し、Ｌ＝Ｒという条件式を出力する。
◆オートマトンCmpOp（ｃ，Ｌ，R）から、ＬとＲの条件式を抽出し、比較の種類ｃによりＬとＲを比較する条件式を出力する。
◆上記以外の場合は真を出力する。
　脆弱性検証部１３３は、文脈抽出部１３２によって抽出された箇所が、あらかじめ用意されたアノテーションを満たすか否かを検証する。脆弱性検証部１３３は、検証部の一例である。
　アノテーションは、解析したいプログラムに対して、満たすべき仕様を付加的に与えるものである。
　また、脆弱性検証部１３３は理論ソルバーを用いて検証を行う。理論ソルバーは、「ＡならばＢ」のような　論理式が必ず成り立つ（妥当）かどうかを保守的に検証する。
　保守的（conservative）とは、ある性質が成り立つか成り立たないかどうかを正確に判定できない場合、悲観的な結果を導かないよう、一方向に倒して判定することである。例えば、脆弱性を保守的に発見する文脈で用いる場合、脆弱性を見逃すことはないが、実際には脆弱性でないものも脆弱性であると判定し得ることを示す。
　本実施形態における理論ソルバーは健全なものであればよく、例えば一般的なＳＭＴソルバー（実装としてはＺ３やＣＶＣ４等）であってよい。
　ＳＭＴソルバーは理論ソルバーの一種であり、論理式の変数に（賢く）色々な値を代入しつつ成り立つかどうかを確かめることで検証を行うものである。
　健全（sound）とは、理論ソルバーに対して用いる場合、論理式を間違って妥当であると判定することはないが、実際には妥当であるものを妥当でないと判定してしまうことは許すことを示す。
　脆弱性検証部１３３は、文脈抽出部１３２によって抽出された実行文脈を用いて、アノテーションの仕様が満たされるかどうかを検証し、満たされると判定できない場合、警告として出力する。例えば、脆弱性検証部１３３は、アノテーションの仕様を満たさない箇所の一覧を出力する。
　脆弱性検証部１３３は、検証のアルゴリズムとして、既存の篩型システムの型検査アルゴリズムをそのまま活用できる（例えば、参考文献４（Chugh　,　R.,　et　al.　“Nested　Refinements　for　Dynamic　Languages.”　POPL’12,　4　節））。
　ここで、アノテーションについて説明する。まず、アノテーションは、タグ付きunionの条件を篩型として定義して記述できる。脆弱性検証部１３３は、タグ付きunionの条件を篩型として定義して記述したアノテーションを、箇所が満たすか否かを検証する。
　既存の篩型システムは、篩型を定義したら、篩型のデータ構造を勝手に固定してしまうのに対し、本実施形態のアノテーションでは、与えられたプログラム中のデータ構造を篩型とみなすこと（詳細化）ができる。
　アノテーションによれば、既にある篩型を制限して新しい篩型を定義できるので、実際には篩型に特定の種類の型しか格納されない場合に、タグの確認が必要なくなるパターンに対応可能になる。
　篩型の適用においては、下記の３つのキャストのパターンがある。
　◆パターンCast:タグ変数の領域と値の領域が互いに排反であるとき
　◆パターンDowncast:タグ変数の領域が値の領域に真に含まれるとき
　　■ただし、キャスト先はキャスト元の部分型である必要がある
　◆パターンRestrict:既存の篩型を制限するように篩型を適用するとき
　　■キャスト先の型の候補を絞るだけで、制限前の篩型の扱いに従うものとする
　アノテーション記述言語の構文は、図７に示す通りである。図７は、アノテーションの記述言語の構文の例を示す図である。また、図８は、アノテーションの例を示す図である。
　図９は、動作例を説明する図である。図９には、実際に所定の言語のソースコード（ここではＬｕａ　５．４．０）を本実施形態の検知装置１０に入力した場合の動作例が示されている。
　まず、図９の（１）に示すように、非安全箇所列挙部１３１は、安全とは限らないキャスト箇所（非安全箇所）を列挙する。
　次に、（２）に示すように、文脈抽出部１３２は、入れ子オートマトンを使って、非安全箇所が実行される条件実行文脈を抽出する。
　そして、（３）に示すように、脆弱性検証部１３３は、オートマトンの終端条件から条件を抽出し、理論ソルバーで仕様を満たすか検証する。
［第１の実施形態の効果］
　これまで説明してきたように、非安全箇所列挙部１３１は、プログラムのコードを基に、プログラムにおいて型のキャストが発生する箇所のうち、型変換が安全であることを示す所定の条件を満たさない箇所を列挙する。文脈抽出部１３２は、非安全箇所列挙部１３１によって列挙された箇所に応じたオートマトンを遷移させ、当該箇所に至る文脈を抽出する。脆弱性検証部１３３は、文脈抽出部１３２によって抽出された箇所が、あらかじめ用意されたアノテーションを満たすか否かを検証する。
　検知装置１０は、上記の方法により、ポインターの存在を仮定した上で型混同脆弱性の検知を行うことができる。その結果、本実施形態によれば、型混同脆弱性の検知を効果的に行うことができる。
　非安全箇所列挙部１３１は、キャスト元の型とキャスト先の型について、キャスト可能関係の判定及び部分型関係の判定を行う。これにより、ポインター型と篩型の両方がある場合であっても、安全に取り扱うことができる。
　文脈抽出部１３２は、第１のオートマトンによる条件式の抽出中に変数が現れた場合、当該変数を特定する第２のオートマトンを用いて当該変数を再帰的に特定する。これにより、一方のオートマトンで条件式を抽出中の状態で命令を見たときにどう処理するか（推移関数）を設計するだけで、任意に複雑で再帰的な式を再構成できる。
　脆弱性検証部１３３は、タグ付きunionの条件を篩型として記述されたアノテーションを、非安全箇所列挙部１３１により列挙された箇所で満たすか否かを検証する。これにより、篩型のデータ構造を固定することなく検証を行うことができる。
［システム構成等］
　また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、各装置の分散及び統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散又は統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部又は任意の一部が、ＣＰＵ（Central　Processing　Unit）及び当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。なお、プログラムは、ＣＰＵだけでなく、ＧＰＵ等の他のプロセッサによって実行されてもよい。
　また、本実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
［プログラム］
　一実施形態として、検知装置１０は、パッケージソフトウェアやオンラインソフトウェアとして上記の検知処理を実行する検知プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、上記の検知プログラムを情報処理装置に実行させることにより、情報処理装置を検知装置１０として機能させることができる。ここで言う情報処理装置には、デスクトップ型又はノート型のパーソナルコンピュータが含まれる。また、その他にも、情報処理装置にはスマートフォン、携帯電話機やＰＨＳ（Personal　Handyphone　System）等の移動体通信端末、さらには、ＰＤＡ（Personal　Digital　Assistant）等のスレート端末等がその範疇に含まれる。
　また、検知装置１０は、ユーザが使用する端末装置をクライアントとし、当該クライアントに上記の検知処理に関するサービスを提供する検知サーバ装置として実装することもできる。例えば、検知サーバ装置は、ソースコードを入力とし、型混同脆弱性の候補箇所を出力とする検知サービスを提供するサーバ装置として実装される。この場合、検知サーバ装置は、Ｗｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記の検知処理に関するサービスを提供するクラウドとして実装することとしてもかまわない。
　図１０は、検知プログラムを実行するコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ（Read　Only　Memory）１０１１及びＲＡＭ（Random　Access　Memory）１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
　ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、検知装置１０の各処理を規定するプログラムは、コンピュータにより実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、検知装置１０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid　State　Drive）により代替されてもよい。
　また、上述した実施形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０は、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して、上述した実施形態の処理を実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local　Area　Network）、ＷＡＮ（Wide　Area　Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　１０　検知装置
　１１　インタフェース部
　１２　記憶部
　１３　制御部
　１２１　アノテーション情報
　１３１　非安全箇所列挙部
　１３１ａ　キャスト可能関係判定部
　１３１ｂ　部分型関係判定部
　１３２　文脈抽出部
　１３３　脆弱性検証部

Claims (6)

  1. 　プログラムのコードを基に、前記プログラムにおいて型のキャストが発生する箇所のうち、型変換が安全であることを示す所定の条件を満たさない箇所を列挙する列挙部と、
    　前記列挙部によって列挙された箇所に応じたオートマトンを遷移させ、当該箇所に至る文脈を抽出する抽出部と、
    　前記抽出部によって抽出された箇所が、あらかじめ用意されたアノテーションを満たすか否かを検証する検証部と、
    　を有することを特徴とする検知装置。
  2. 　前記列挙部は、キャスト元の型とキャスト先の型について、キャスト可能関係の判定及び部分型関係の判定を行うことを特徴とする請求項１に記載の検知装置。
  3. 　前記抽出部は、第１のオートマトンによる条件式の抽出中に変数が現れた場合、当該変数を特定する第２のオートマトンを用いて当該変数を特定することを特徴とする請求項１又は２に記載の検知装置。
  4. 　前記検証部は、タグ付きunionの条件を篩型として定義して記述したアノテーションを、前記箇所が満たすか否かを検証することを特徴とする請求項１から３のいずれか１項に記載の検知装置。
  5. 　検知装置によって実行される検知方法であって、
    　プログラムのコードを基に、前記プログラムにおいて型のキャストが発生する箇所のうち、型変換が安全であることを示す所定の条件を満たさない箇所を列挙する列挙工程と、
    　前記列挙工程によって列挙された箇所に応じたオートマトンを遷移させ、当該箇所に至る文脈を抽出する抽出工程と、
    　前記抽出工程によって抽出された箇所が、あらかじめ用意されたアノテーションを満たすか否かを検証する検証工程と、
    　を含むことを特徴とする検知方法。
  6. 　コンピュータを、請求項１から４のいずれか１項に記載の検知装置として機能させるための検知プログラム。
PCT/JP2021/016864 2021-04-27 2021-04-27 検知装置、検知方法及び検知プログラム WO2022230074A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/016864 WO2022230074A1 (ja) 2021-04-27 2021-04-27 検知装置、検知方法及び検知プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/016864 WO2022230074A1 (ja) 2021-04-27 2021-04-27 検知装置、検知方法及び検知プログラム

Publications (1)

Publication Number Publication Date
WO2022230074A1 true WO2022230074A1 (ja) 2022-11-03

Family

ID=83847877

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/016864 WO2022230074A1 (ja) 2021-04-27 2021-04-27 検知装置、検知方法及び検知プログラム

Country Status (1)

Country Link
WO (1) WO2022230074A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009211622A (ja) * 2008-03-06 2009-09-17 Nec Corp 契約定義関数検証装置、その方法及びそのプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009211622A (ja) * 2008-03-06 2009-09-17 Nec Corp 契約定義関数検証装置、その方法及びそのプログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KAWAI, TOSHIHIRO ET AL.: "A Parametric Execution Time Analysis Method for Reuse of Real-time Software", MODELING OF REAL-TIME SOFTWARE CONSIDERING PARAMETERS, (IEICE TECHNICAL REPORT, vol. 107, no. 505, 31 January 2008 (2008-01-31), JP , pages 97 - 102, XP009540925, ISSN: 0913-5685 *
ZOU, CHANGWEI ET AL.: "TCD: Statically Detecting Type Confusion Errors in C++ Programs", 2019 IEEE 30TH INTERNATIONAL SYMPOSIUM ON SOFTWARE RELIABILITY ENGINEERING (ISSRE)., 28 October 2019 (2019-10-28), pages 292 - 302, XP033708675, ISBN: 978-1-7281- 4982-0, Retrieved from the Internet <URL:https://ieeexplore.ieee.org/document/8987463> [retrieved on 20210611], DOI: 10.1109/ISSRE.2019.00037 *

Similar Documents

Publication Publication Date Title
US10055592B2 (en) Systems and methods to generate a type based self-assembling indirect control flow graph
US8117660B2 (en) Secure control flows by monitoring control transfers
JP6088713B2 (ja) 脆弱性発見装置、脆弱性発見方法、及び脆弱性発見プログラム
KR100942795B1 (ko) 악성프로그램 탐지장치 및 그 방법
US8850581B2 (en) Identification of malware detection signature candidate code
US7849509B2 (en) Detection of security vulnerabilities in computer programs
US9507943B1 (en) Analysis tool for data security
JP2019003596A (ja) 静的分析の要素を用いた悪質なファイルを検出するためのシステム及び方法
WO2022180702A1 (ja) 解析機能付与装置、解析機能付与プログラム及び解析機能付与方法
JP7287480B2 (ja) 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
JP2018129019A (ja) 仮想マシンにおける悪意のあるファイルを分析するシステム及び方法
CN109271789B (zh) 恶意进程检测方法、装置、电子设备及存储介质
JP2021051745A (ja) コンピュータ装置およびメモリ管理方法
US11609985B1 (en) Analyzing scripts to create and enforce security policies in dynamic development pipelines
Arcuri et al. Enhancing search-based testing with testability transformations for existing APIs
JP6662117B2 (ja) 署名に基づく静的解析を用いた悪質ソフトウェアの動作の検出
US20190243976A1 (en) System and method for categorization of .net applications
Pandiaraja et al. A graph-based model for discovering host-based hook attacks
JP5868515B2 (ja) シグニチャ検証装置及びシグニチャ検証方法及びプログラム
US20230021414A1 (en) Security tool integrated into build platform to identify vulnerabilities
JP6954466B2 (ja) 生成方法、生成装置および生成プログラム
WO2022230074A1 (ja) 検知装置、検知方法及び検知プログラム
US11283836B2 (en) Automatic decoy derivation through patch transformation
WO2023067665A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023101574A1 (en) Method and system for static analysis of binary executable code

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: 21939235

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: 21939235

Country of ref document: EP

Kind code of ref document: A1