KR102494838B1 - Methods and apparatus for disarming a link on documentsummaryinformation stream in ms-cfb - Google Patents

Abstract

A method of a server to disarm link information of a DocumentSummaryInformation stream checks a PropertySetStream record in the DocumentSummaryInformation stream; checks a field value of NumPropertySets in the PropertySetStream record; determines whether the field values of FMTID0 and FMTID1 are appropriate based on the field value of NumPropertySets indicating 2; checks a VtHyperlinks record based on whether the field values of FMTID0 and FMTID1 are appropriate; and disarms the link information based on the VtHyperlinks record.

Description

Method and apparatus for disarming Link in DocumentSummaryInformation stream of MS-CFB {METHODS AND APPARATUS FOR DISARMING A LINK ON DOCUMENTSUMMARYINFORMATION STREAM IN MS-CFB}

The present specification relates to a method and apparatus for disarming a Link in a DocumentSummaryInformation stream of MS-CFB.

In the Advanced Persistent Threat (APT) attack, an attacker sets a specific target and applies advanced attack techniques to continuously utilize various types of malicious codes to steal target information. In particular, APT attacks are often undetectable at the initial intrusion stage and often use Non-Portable Executable (Non-PE) files containing malicious codes rather than Portable Executable (PE) files.

A non-executable file is a concept opposite to an executable file, and means a file that is not executed by itself. Examples of non-executable files include document files such as word files, Excel files, Hangul files, and PDF files, image files, video files, JavaScript files, and HTML files. The reason why non-executable files containing malicious codes are frequently used in APT attacks is that applications that execute non-executable files basically have some level of security vulnerability. In addition, if the malicious code is included in the non-executable file, the modified malicious code can be easily created by changing the file.

A document action is an action in which a non-executable file executes an associated application action. Existing APT solutions operate based on document behavior, so after the document behavior occurs, changes in the sandbox (Virtual Machine, VM) are observed to determine whether it is malicious. This takes a long time to analyze because it waits for all document behaviors to appear and then determines whether or not it is malignant.

In addition, existing APT solutions such as CDR can remove malicious active content, but security gaps occur because they cannot remove vulnerabilities that occur in essential elements (eg body text, fonts) of documents.

Since there is a possibility that harmful link information may be included in non-executable files, link information must be harmless. In this case, there should be no problem that the layout of non-executable files is changed or distorted.

The purpose of this specification is to propose a method for harmless Link in the DocumentSummaryInformation stream of MS-CFB.

The technical problems to be achieved by this specification are not limited to the above-mentioned technical problems, and other technical problems not mentioned are clear to those skilled in the art from the detailed description of the specification below. will be understandable.

One aspect of the present specification is a method for disarming link information of a DocumentSummaryInformation stream by a server, comprising: checking a PropertySetStream record in the DocumentSummaryInformation stream; checking field values of NumPropertySets of the PropertySetStream record; determining whether the field values of FMTID0 and FMTID1 are valid based on the fact that the field value of the NumPropertySets indicates 2; verifying a VtHyperlinks record based on valid field values of the FMTID0 and the FMTID1; and harmless the link information based on the VtHyperlinks record. can include

In addition, the step of determining whether the field values of the FMTID0 and the FMTID1 are valid is because the FMTID0 field value is a D5CDD502-2E9C-101B-9397-08002B2CF9AE value and the FMTID1 field value is a D5CDD505-2E9C-101B-9397-08002B2CF9AE value. can be based

In addition, the checking of the VtHyperlinks record may include checking encoding information related to a Dictionary Property in CodePage Property; and checking a character string “_PID_HLINKS” in the Dictionary Property based on the encoding information; can include

Also, based on the confirmation of “_PID_HLINKS”, the VtHyperlinks record may be included in TypedPropertyValue.

In addition, the step of harmless link information may include checking a VtHyperlinkValue record through a vtValue field of the VtHyperlinks record; checking an array of VtHyperlinks through an rgHyperlink field of vecHyperlink of the VtHyperlinkValue record; and detoxifying the hlink1 and hlink2 fields of the VtHyperlink record.

In addition, the step of disarming the hlink1 and hlink2 fields may include leaving only schemes in the hlink1 and hlink2 fields; can include

Also, based on the harmless link information, modifying the dwHash field; can include

Another aspect of the present specification is a server for disarming link information of a DocumentSummaryInformation stream, comprising: a communication unit; Memory; and a processor functionally controlling the communication unit and the memory, wherein the processor checks a PropertySetStream record in the DocumentSummaryInformation stream, checks a field value of NumPropertySets of the PropertySetStream record, and determines that a field value of the NumPropertySets is 2. Based on the indication, it is determined whether the field values of FMTID0 and FMTID1 are valid, and based on whether the field values of FMTID0 and FMTID1 are valid, the VtHyperlinks record is identified, and the link information is harmless based on the VtHyperlinks record. can do.

According to an embodiment of the present specification, Link can be harmless in the DocumentSummaryInformation stream of MS-CFB.

Effects obtainable in the present specification are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below. .

1 is a diagram showing a server or client related to the present specification.
2 is an example of an abnormal input that can be applied to this specification.
3 illustrates a URI configuration to which this specification can be applied.
4 illustrates a method of harmless a DocumentSummaryInformation stream to which this specification can be applied.
5 is an example of a PropertySet to which this specification can be applied.
6 is an example of PropertySetStream to which this specification can be applied.
7 is an example of a DocumentSummaryInformation stream to which this specification can be applied.
8 is an example of VtHyperlinks to which the present specification can be applied.
9 is an example of VtHyperlink to which the present specification can be applied.
The accompanying drawings, which are included as part of the detailed description to aid understanding of the present specification, provide examples of the present specification and describe technical features of the present specification together with the detailed description.

Hereinafter, the embodiments disclosed in this specification will be described in detail with reference to the accompanying drawings, but the same or similar components are given the same reference numerals regardless of reference numerals, and redundant description thereof will be omitted. The suffixes "module" and "unit" for components used in the following description are given or used together in consideration of ease of writing the specification, and do not have meanings or roles that are distinct from each other by themselves. In addition, in describing the embodiments disclosed in this specification, if it is determined that a detailed description of a related known technology may obscure the gist of the embodiment disclosed in this specification, the detailed description thereof will be omitted. In addition, the accompanying drawings are only for easy understanding of the embodiments disclosed in this specification, the technical idea disclosed in this specification is not limited by the accompanying drawings, and all changes included in the spirit and technical scope of this specification , it should be understood to include equivalents or substitutes.

Terms including ordinal numbers, such as first and second, may be used to describe various components, but the components are not limited by the terms. These terms are only used for the purpose of distinguishing one component from another.

It is understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, but other elements may exist in the middle. It should be. On the other hand, when an element is referred to as “directly connected” or “directly connected” to another element, it should be understood that no other element exists in the middle.

Singular expressions include plural expressions unless the context clearly dictates otherwise.

In this specification, terms such as "comprise" or "having" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, but one or more other features It should be understood that the presence or addition of numbers, steps, operations, components, parts, or combinations thereof is not precluded.

Also, the term “unit” used in the specification means a software or hardware component, and “unit” performs certain roles. However, "unit" is not meant to be limited to software or hardware. A “unit” may be configured to reside in an addressable storage medium and may be configured to reproduce on one or more processors. Thus, as an example, “unit” can refer to components such as software components, object-oriented software components, class components and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays and variables. Functionality provided within components and "parts" may be combined into fewer components and "parts" or further separated into additional components and "parts".

Also, according to one embodiment of the present specification, "unit" may be implemented as a processor and a memory. The term “processor” should be interpreted broadly to include general-purpose processors, central processing units (CPUs), microprocessors, digital signal processors (DSPs), controllers, microcontrollers, state machines, and the like. In some circumstances, “processor” may refer to an application specific integrated circuit (ASIC), programmable logic device (PLD), field programmable gate array (FPGA), or the like. The term "processor" refers to a combination of processing devices, such as, for example, a combination of a DSP and a microprocessor, a combination of a plurality of microprocessors, a combination of one or more microprocessors in conjunction with a DSP core, or any other such configuration. may also refer to

The term “memory” should be interpreted broadly to include any electronic component capable of storing electronic information. The term memory includes random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erasable-programmable read-only memory (EPROM), electrical may refer to various types of processor-readable media, such as erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, and the like. A memory is said to be in electronic communication with the processor if the processor can read information from and/or write information to the memory. Memory integrated with the processor is in electronic communication with the processor.

As used herein, a "non-executable file" is a concept opposite to an executable file or an executable file, and means a file that is not itself executed. For example, the non-executable file may be a PDF file, a Korean file, a document file such as a word file, an image file such as a JPG file, a video file, a JavaScript file, and an HTML file, but is not limited thereto.

Hereinafter, with reference to the accompanying drawings, embodiments will be described in detail so that those skilled in the art can easily carry out the embodiments. In addition, in order to clearly describe the present disclosure in the drawings, parts irrelevant to the description may be omitted.

1 is a diagram showing a server or client related to the present specification.

In this specification, a server (or cloud server) or a client may include a control unit 100 and a communication unit 130. The controller 100 may include a processor 110 and a memory 120 . The processor 110 may execute instructions stored in the memory 120 . The processor 110 may control the communication unit 130 .

The processor 110 may control the operation of the server or client based on instructions stored in the memory 120 . A server or client may include one processor or may include a plurality of processors. When the server or the client includes a plurality of processors, at least some of the plurality of processors may be located at physically separated distances. In addition, the server or client may be implemented in various known ways without being limited thereto.

The communication unit 130 may include one or more modules enabling wireless communication between a server or client and a wireless communication system, between a server or client and another server or client, or between a server or client and an external server. Also, the communication unit 110 may include one or more modules that connect a server or a client to one or more networks.

The controller 100 may control at least some of the components of the server or client in order to drive an application program stored in the memory 120 . Furthermore, the control unit 100 may combine and operate at least two or more of the components included in the server or client to drive the application program.

In this specification, the server may include a reversing engine or/and a CDR engine providing CDR services.

Reversing Engine

The reversing engine is an analysis/diagnostic engine that automates the reverse engineering (reversing) process for malicious non-executable files.

For example, the reversing engine may perform the following steps.

1. File analysis: As a step of analyzing the appearance of the non-executable file itself (eg, attribute, author, date of creation, file type), similar to general vaccine programs, maliciousness can be diagnosed only with the information of the non-executable file itself. can

2. Static analysis: This step is to extract and analyze the data in the non-executable file to determine whether it is normal or malicious. The non-executable file is not executed, and internal data is extracted according to the file structure and compared and analyzed to diagnose maliciousness. there is. This may be suitable for macros, URL extraction analysis, and the like.

3. Dynamic analysis: This step is to determine whether or not the non-executable file is malicious by reading and monitoring the non-executable file through an application program including an editor and reader, and analyzing the behavior while monitoring it. Detecting malicious behavior using normal functions such as macros, hyperlinks, and DDE easy to do

4. Debugging analysis: This step analyzes vulnerabilities and exploits by reading and debugging non-executable files. Detects vulnerabilities of applications using text, tables, fonts, pictures, etc. in documents, including macros, hyperlinks, and DDE. suitable for doing

The reversing engine may include a debugging engine that may be used for debugging analysis. The debugging engine can diagnose vulnerabilities occurring in document input, processing, and output stages by debugging the process of reading non-executable files. Vulnerability here refers to the use of errors and bugs that occur when an application program receives an unexpected value from the code (logic) developed by the application developer. Malicious actions such as remote code execution can be executed.

Content Disarm and Reconstruction (CDR)

The CDR service is a solution that disassembles non-executable files, removes malicious or unnecessary files, and creates new files by making the contents the same as the original as much as possible.

In other words, Contents Disarm and Reconstruction (CDR) means a service that disarms and reconstructs the contents in a document to create a safe document and provides it to customers. For example, Word, Excel, PowerPoint, Hangul, PDF) may be targeted, and the harmless target content may be active content (eg, macro, hyperlink, OLE object, etc.).

2 is an example of an abnormal input that can be applied to this specification.

Referring to FIG. 2, when an application program receives an abnormal value (for example, when the input value exceeds the normal range of 2) through a non-executable file, the application program is changed into an execution flow unintended by the developer and thus vulnerable. this can work. The debugging engine automatically debugs the document browsing process, sets a breakpoint at a specific point related to the vulnerability, checks a specific value related to the input value, determines whether the input value is a value that causes a vulnerability, and diagnoses whether the input value is malicious.

More specifically, the debugging engine can start debugging by identifying non-executable files and running an application to view them. If a module is loaded while viewing a non-executable file, the debugging engine checks whether the module is an analysis target module, and if it is an analysis target, it can set a breakpoint at a designated address.

For example, a malicious non-executable file may have branching points at which an application program is terminated or branched into a flow in which no malicious activity occurs unless a specific condition such as an application version or an operating system environment is satisfied. The server can set a breakpoint at a divergence point that has been previously analyzed by an analyst and has this possibility.

In addition, the server may set conditions associated with a corresponding branching point to continuously execute the application program without terminating or lead to a flow in which a malicious action may occur.

If the process stops at the corresponding breakpoint while the process of the application program is running, the server may perform a step of detecting whether or not there is a vulnerability according to the detection logic and then storing the result in an analysis report.

The automated reversing engine included in the server can analyze and diagnose malicious non-executable files through a diagnosis algorithm researched and developed by an analyst by automatically performing and analyzing the above steps.

3 illustrates a URI configuration to which this specification can be applied.

Referring to FIG. 3, a URI (Uniform Resource Identifier), which is link information to be harmless in this specification, is exemplified.

In general, URI syntax may include scheme, authority, path, query, and fragment.

Table 1 is an example of a hierarchical sequence of URI syntax to which this specification can be applied.

URI = scheme ":" hier-part ["?" query ] ["#" fragment]

hier-part="//" authority path-abempty
/path-absolute
/path-rootless
/path-empty

For example, the URI syntax may be composed of a hierarchical sequence as shown in Table 1 below. Referring to FIG. 3 and Table 1, rules related to “/” in the URI may be as follows.

(1) When authority is present, the path must either be empty or begin with a slash ("/") character.

(2) When authority is not present, the path cannot begin with two slash characters ("//").

Therefore, in the URI, the number of “/” related to the path can be determined depending on whether the authority exists. For example, the server can determine the authority through “/”.

If all URIs are removed through the harmonization process, links may disappear from office documents, and the result of harmonization may differ from the original layout. In order to prevent this problem from occurring, in the present specification, as a method of harmless link information, only a slash ("/") from a scheme may be left.

Through this, the layout of the document to be harmless can be maintained, and the user can intuitively recognize what form (eg, http, file, mailto, etc.) of the existing link information was.

Table 2 is an example of detoxification results to which the present specification can be applied.

original harmless result foo://example.com:8042/over/there?name=ferret#nose foo:// urn:example:animal:ferret:nose urn: https://seculetter.com https:// mailto:anesin@seculleter.com mailto:

4 illustrates a method of harmless a DocumentSummaryInformation stream to which this specification can be applied.

Referring to FIG. 4, a method of disarming a DocumentSummaryInformation stream of a server is exemplified.

If you unzip the CFB-type files, you can check the directory and file structure. At this time, the directory type is called storage, and the file type is called stream.

For example, DOC, PPT, and XLS formats may contain a DocumentSummaryInformation stream.

The DocumentSummaryInformation stream may include meta information about a document. Accordingly, the user may or may not check the meta information of the DocumentSummaryInformation stream. Since link information can be included in the DocumentSummaryInformation stream, harmless work is required.

The server checks the PropertySetStream record in the DocumentSummaryInformation stream (S4010). For example, if the format of the non-executable file is CFB-based, the server can check the PropertySetStream record through sequential search in the DocumentSummaryInformation stream. More specifically, the DocumentSummaryInformation stream can contain PropertySetStream records.

In relation to this, specifications that can be applied to this specification are as follows.

[MS-OLEPS]: Object Linking and Embedding (OLE) Property Set Data Structures

(https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-oleps/bf7aeae8-c47a-4939-9f45-700158dac3bc)

One. Introduction

This document specifies Object Linking and Embedding (OLE) Property Set Data Structures (OLEPS), a generic persistence format for a set of properties commonly used to link simple type metadata with files. To enable applications to retrieve metadata from other software, select a property set format, either a well-known publishing format or an application-defined format, and create a property set containing the properties specified in this format. When combined with technologies that support multiple virtual streams in a single physical file, such as the Compound File Binary File Format (see [MS-CFB] for details) or the Alternate User Data Streams feature of certain file systems, one or more property sets are associated with the file. can connect Through this, the application program can search the attributes of the file in software that does not support parsing of each application program of the file format.

2. Structures

2.19 PropertyIdentifierAndOffset

The PropertyIdentifierAndOffset packet is used to indicate the property identifier and the byte offset of the property in the PropertySet packet.

A PropertyIdentifierAndOffset packet may contain the following fields:

PropertyIdentifier (4 bytes): An unsigned integer representing the property identifier of the property in the property set. Must be a valid PropertyIdentifier value.

Offset (4 bytes): An unsigned integer representing the offset (bytes) from the beginning of the PropertySet packet to the beginning of the Property field for the indicated property. Must be a multiple of 4 bytes.

That is, in PropertyIdentifier, the identifier (PropertyIdentifier) for the next property is included. Also, Offset becomes a value based on the PropertySet start address.

2.20 PropertySets

A PropertySet packet represents a property set.

5 is an example of a PropertySet to which this specification can be applied.

Referring to FIG. 5, the PropertySet packet may include the following fields:

Size (4 bytes): This should be the total size of the PropertySet packet (in bytes).

NumProperties (4 bytes): An unsigned integer representing the number of properties in the property set.

PropertyIdentifierAndOffset 0 (variable): All PropertyIdentifierAndOffset fields MUST be sequences of PropertyIdentifierAndOffset packets. This sequence must be in increasing order of the value of the Offset field. Packets do not require any particular order with respect to the value of the PropertyIdentifier field.

Property 0 (variable): Each Property field is a sequence of property values, and each property value must be expressed in a TypePropertyValue packet or Dictionary packet if the Dictionary property is special.

2.21 PropertySetStream

The PropertySetStream packet specifies the stream format for simple property sets and the CONTENTS stream for Non-Simple Property Set Storage Format. A simple property set MUST be represented as a stream containing PropertySetStream packets.

PropertySetStream packets typically represent exactly one property set, but for historical reasons, DocumentSummaryInfo and UserDefinedProperties property sets may appear in the same stream. In this particular case, a PropertySetStream can represent two property sets.

Implementations must enforce limits on the total size of PropertySetStream packets. These limits must be at least 262,144 bytes and 2,097,152 bytes for maximum interoperability.

6 is an example of PropertySetStream to which this specification can be applied.

Referring to FIG. 6, the PropertySetStream packet may include the following fields:

ByteOrder (2 bytes): MUST be set to 0xFFFE.

Version (2 bytes): An unsigned integer representing the version number of the property set (or property sets). MUST be 0x0000 or 0x0001.

SystemIdentifier (4 bytes): implementation-specific value that should be ignored unless reporting this value to the application.

CLSID (16 bytes): Must be a packet version (GUID) indicating the CLSID associated with the property set (or property sets).

NumPropertySets (4 bytes): An unsigned integer representing the number of property sets represented by this PropertySetStream structure. Must be 0x00000001 or 0x00000002.

Table 3 is an example of NumPropertySets values.

FMTID0 (16 bytes): A GUID that should be set to the FMTID of the property set represented by the PropertySet 0 field. If the value of NumPropertySets is 0x00000002, then this GUID should be set to FMTID_DocSummaryInformation ({D5CDD502-2E9C-101B-9397-08002B2CF9AE}).

Offset0 (4 bytes): An unsigned integer that should be set as the offset in bytes from the start of this PropertySetStream structure to the start of the PropertySet 0 field.

FMTID1 (16 bytes): If the value of NumPropertySets is 0x00000002, it should be set as FMTID_UserDefinedProperties ({D5CDD505-2E9C-101B-9397-08002B2CF9AE}). otherwise, it does not exist.

Offset1 (4 bytes): If the value of NumPropertySets is 0x00000002, it must be set as an offset in bytes from the start of this PropertySetStream structure to the start of PropertySet 1 field. otherwise, it does not exist.

PropertySet0 (variable): Must be a PropertySet packet.

PropertySet1 (variable): If the value of NumPropertySets is 0x00000002, it must be a PropertySet packet. otherwise, it does not exist.

Padding (variable): Contains any additional padding added by the implementation. Padding, if present, should be zero and should be ignored.

2.23 Property Set Stream and Storage Names

A stream or storage representing a property set may be an element of storage. For example, a standard binding to a property set stream or storage in a compound file must be an element of the file's root storage, respectively. This section specifies a standard mapping between a property set's FMTID and the name of the stream or storage element representing the property set, allowing you to retrieve property sets stored in this way.

An OLEPS implementation MUST provide a mechanism for using an element with a derived name in a property set according to this standard mapping, but the implementation MAY additionally provide one or more other mechanisms that do not conform to this convention. For example, an implementation may provide a mechanism to store property sets in an arbitrary application-provided stream container or storage container.

Table 4 illustrates the designation of standard names for property set streams and storage.

PropertySetStreamOrStorageName = %x05 ("SummaryInformation" /
"DocumentSummaryInformation" / "GlobalInfo" / "ImageContents" /
"ImageInfo" / 26(ALPHA / "0" / "1" / "2" / "3" / "4" / "5") )

Table 5 is an example of special-case FMTID.

Referring back to FIG. 4, the server checks the field values of NumPropertySets of the PropertySetStream record (S4020).

Based on the field value of NumPropertySets indicating 2, the server determines whether the field values of FMTID0 and FMTID1 are valid (S4030). For example, when the field value of NumPropertySets indicates 2, the FMTID0 field value may have a value of D5CDD502-2E9C-101B-9397-08002B2CF9AE, and the FMTID1 field value may have a value of D5CDD505-2E9C-101B-9397-08002B2CF9AE. . When the FMTID0 field value is D5CDD502-2E9C-101B-9397-08002B2CF9AE and the FMTID1 field value is D5CDD505-2E9C-101B-9397-08002B2CF9AE, the server may determine that this is legitimate.

The server checks the VtHyperlinks record based on whether the field values of FMTID0 and FMTID1 are valid (S4040).

For example, the server may search for the PropertySet 1 field based on Offset1. The PropertySet 1 field may include User Defined Property Set.

User Defined Property Set is included in the "\005DocumentSummaryInformation" document stream, and includes arbitrary types of properties and values.

For example, User Defined Property Set can include the following three properties: Dictionary Property, CodePage Property, and TypedPropetyValue

7 is DocumentSummaryInformation to which this specification can be applied This is an example of a stream.

Referring to FIG. 7 , the DocumentSummaryInformation stream may include Dictionary Property ([01000000 02000000 0C000000 5F504944 5F484C49 4E4B5300]), CodePage Property ([02000000 13270000]), and TypedPropetyValue ([41000000 ...]).

For example, [5F504944 5F484C49 4E4B5300] is a Name field and may indicate “_PID_HLINKS”. Also, [13270000] may mean that the string of the DictionaryEntry packet is encoded in Korean (Mac) when it is 0x2713 (10003).

In relation to this, specifications that can be applied to this specification are as follows.

2.15 TypedPropertyValue

The TypedPropertyValue structure represents the typed value of a property in a property set.

A TypedPropertyValue can contain the following fields:

Type (2 bytes): Must be a value in the PropertyType enumeration that indicates the type of the displayed property.

Padding (2 bytes): Must be set to 0, non-zero values must be rejected.

Value (variable): It must be the value of a serialized property that is expressed according to the value of the following Type.

Table 6 is an example of Type.

2.18 Special Properties

The following sections provide additional information about properties that have special representations, uses, or restrictions.

2.18.1 Dictionary Property

If there is a dictionary property, the property identifier must be 0x000000 and cannot have a property name. Unlike other properties that are represented by the TypePropertyValue packet, the Dictionary property must be represented by the Dictionary packet.

2.18.2 CodePage Property

The CodePage property must have a property identifier of 0x00000001, no property name, and a type of VT_I2 (0x0002). Every property set must have a CodePage attribute and its value must be a valid code page identifier as specified in [MS-UCODEREF] section 2.2.1. This value is chosen in an implementation-specific way.

The CodePage property in the property set affects the presentation of CodePageString and DictionaryEntry packets. The value CP_winicode (0x04B0) indicates that the strings in these packets are encoded as arrays of 16-bit Unicode characters. Any other value indicates that the strings in these packets are encoded as arrays of 8-bit characters in the identified code page.

For example, CodePage Property structure may be the same as TypePropertyValue.

In more detail, the CodePage Property may indicate how the string of the DictionaryEntry packet is encoded through a value corresponding to the Value field of TypedPropetyValue.

2.17 Dictionary

Dictionary packets represent all mappings between property identifiers and property names in a property set. For example, every Entry field contained in a Dictionary packet must be a series of DictionaryEntry packets.

2.16 DictionaryEntry

A DictionaryEntry packet represents a mapping between property identifiers and property names. A DictionaryEntry packet contains a Name field.

For example, the Name field may include “_PID_HLINKS” as a reserved name. The specifications related to the reserved name are as follows.

[MS-OSHARED]: Office Common Data Types and Objects Structures

(https://learn.microsoft.com/en-us/openspecs/office_file_formats/ms-oshared/d93502fa-5b8f-4f47-a3fe-5574046f4b8d)

Specifies Office Common Data Types and Objects Structure, which are commonly used data types and data structures in Microsoft Office 97, Microsoft Office XP, Microsoft Office 2003, and 2007 Microsoft Office system documents.

2 Structures

2.3 Common Objects

2.3.3 Property Set Storage

OLE property set storage is a format specified in [MS-OLEPS] that specifies how to store a collection of property sets. This section specifies the property set and data format applicable to this format. The Summary Information (Section 2.3.3.2.1) attribute set should be written in Section 2.3.3. The Document Summary Information (Section 2.3.3.2.2) and User Defined (Section 2.3.3.2.3) property sets are optional.

2.3.3.2 OLE Property Sets

This section defines the format of the property set storage stream as specified in [MS-OLEPS]. This format applies to the Summary Information (Section 2.3.3.2.1) and Document Summary Information (Section 2.3.3.2.2) streams.

2.3.3.2.3 User Defined Property Set

This section defines a simple OLE property set containing arbitrary user-defined properties as specified in [MS-OLEPS]. This property set conforms to [MS-OLEPS] section 2.21 and [MS-OLEPS] section 2.23 with respect to stream name requirements and format identifier GUIDs in the FMTID_UserDefinedProperties property set. The User Defined property set is included in the document stream named "\005DocumentSummary"

2.3.3.2.3.2 Reserved Properties

The User Defined property set (Section 2.3.3.2.3) has several names reserved for specific data.

The reserved name related to hyperlinks is “_PID_HLINKS”, which must be the VtHyperlinks property (section 2.3.3.1.21), and specifies the list of hyperlinks included in the document.

Therefore, in S4040, the server can check whether the Dictionary Property includes “_PID_HLINKS” and check the VtHyperlinks record in the TypedPropertyValue. To this end, the server can check the CodePage Property and check the encoding method related to the Dictionary Property. The server can check the character string “_PID_HLINKS” based on the encoding method.

The server detoxifies the link information based on the VtHyperlinks record (S4050).

For example, the server can check the VtHyperlinkValue record through the vtValue field of the VtHyperlinks record, and check the VtHyperlink array through the rgHyperlink field of vecHyperlink of the VtHyperlinkValue record. For example, if the Dictionary Property includes “_PID_HLINKS”, the TypedPropetyValue property is VtHyperlinks, so the VtHyperlinks record can be included in the TypedPropetyValue.

After that, the server may harm link information for the hlink1 and hlink2 fields of the VtHyperlink record.

The relevant specifications are as follows.

2.3.3.1 Property Types

This section specifies the data format of property data types that require more detailed specifications than those provided by [MS-OLEPS].

2.3.3.1.21 VtHyperlinks

Specifies the format of the property representing the hyperlink set. This type conforms to the VT_BLOB TypedPropertyValue type specified in [MS-OLEPS] section 2.15, but is described in more detail here to further specify the data content of this type.

8 is an example of VtHyperlinks to which the present specification can be applied.

Referring to FIG. 8 , the VtHyperlinks record may include the following fields:

wType (2 bytes): unsigned integer which must equal VT_BLOB (0x0041)

padding (2 bytes): unsigned integer which must be 0x0000

vtValue (variable): MUST be a VtHyperlinkValue structure (Section 2.3.3.1.20).

2.3.3.1.20 VtHyperlinkValue

Specifies the data of the hyperlink property. This type conforms to the VT_BLOB TypedPropertyValue value format specified in [MS-OLEPS] section 2.15, but this section specifies additional details applicable to this type.

The VtHyperlinkValue record may include vecHyperlink (variable), which is a VecVtHyperlink structure.

2.3.3.1.19 VecVtHyperlink

Specifies the data format of the hyperlink array. Here, the rgHyperlink (variable) field contains the VtHyperlink array (section 2.3.3.1.18) and specifies a list of hyperlinks to the property.

2.3.3.1.18 VtHyperlink

Specifies the data format of hyperlinks to properties.

9 is an example of VtHyperlink to which the present specification can be applied.

Referring to FIG. 9, the VtHyperlink record may include the following fields:

dwHash (8 bytes): Must be a VT_I4 TypedPropertyValue specified in [MS-OLEPS] section 2.15. The Value field of this structure must be computed as specified in the Hyperlink Hash (Section 2.4.2) section, taking the hlink1 and hlink2 field string values as input.

dwApp (8 bytes): Must be a VT_I4 TypedPropertyValue specified in [MS-OLEPS] section 2.15.

dwOfficeArt (8 bytes): Must be a VT_I4 TypedPropertyValue specified in [MS-OLEPS] Section 2.15. The Value field of this structure must be a value of type MSOSPID ([MS-ODRAW] section 2.1.2) specifying the identifier ([MS-ODRAW] section 2.2.31) of the shape to which the hyperlink applies. If this hyperlink does not apply to a shape, the Value field of this structure should be 0x000000.

dwInfo (8 bytes): Must be a VT_I4 TypedPropertyValue specified in [MS-OLEPS] Section 2.15.

hlink1 (variable): This should be the VtString structure of hlink1 (Section 2.3.3.1.11). wType is the same as VT_LPWSTR. hlink1.stringValue specifies the hyperlink target.

hlink2 (variable): MUST be a tString structure (section 2.3.3.1.11) with hlink2. wType is the same as VT_LPWSTR. hlink2.stringValue specifies the hyperlink location.

The server can leave only the scheme in the hlink1 and hlink2 fields or, if “/” exists, only the scheme and “/”.

In addition, the server may perform harmless with a blank (0x20) instead of removing link information with a null character (\0). The reason why the null character is not used is that the MS-CFB specifications for some strings are null-terminated strings.

Additionally, the server may change the dwHash field based on the harmless link information. Since the dwHash field has a calculated hash value by taking the string values of the hlink1 and hlink2 fields as input, it should be changed to an appropriate value according to the changed hlink1 and hlink2 fields.

For example, an appropriate value is to combine two characters (Char1, Char2) of the string in hlink into an 8-byte value (dwNext = (Char2 << 16) | Char1), which is initialized to zero ( dwHash (= 0)) may be the result of sequentially accumulating XOR (dwHash ^= dwNext).

The relevant specifications are as follows.

2.4.1 Unicode String to Unsigned Integer Hash

Given a null-terminated Unicode string, the following algorithm can be performed to obtain a 4-byte unsigned integer hash value:

1. The 4-byte unsigned integer value dwHash is set to 0x00000000.

2. Cuts the input string into 255 characters plus a null-terminating character.

3. Converts the input string to lower case.

4. For each set of 2 strings from position 0 to the end of the input string (eg [0,1], [2,3], [4,5], [255, <null>), do the following steps:

Example:

for (i=0; i<wcslen(inputString); i+=2)

Char1 = inputString[i];

Char2 = inputString[i+1];

a. Set an unsigned 4-byte integer value, dwNext, equal to the bitwise OR of Char2 shifted 16 bits to the high order and Char1.

Example: dwNext = (Char2 << 16) | Char1;

b. Set dwHash equal to the exclusive OR between dwHash and dwNext.

Example: dwHash = dwHash ^ dwNext;

5. The result of the algorithm is the dwHash value.

2.4.2 Hyperlink Hash

Given two null-terminated Unicode hyperlink strings, hlink1 (hyperlink target) and hlink2 (hyperlink location), we can perform the following algorithm to obtain an unsigned 4-byte integer hash:

1. Hash hhlink1 as specified in Unicode String to Unsigned Interger (LONG) Hash (Section 2.4.1), and store the resulting unsigned 4-byte integer hash in dwHash1.

2. Hash hhlink2 as specified in Unicode String to Unsigned Interger Hash (Section 2.4.1), and store the resulting unsigned 4-byte integer hash as dwHash2.

3. The result of the algorithm is the value obtained by exclusive OR of dwHash1 and dwHash2.

Example: dwHash = dwHash1 ^ dwHash2;

The above specification can be implemented as computer readable code on a medium on which a program is recorded. A computer-readable medium includes all types of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable media include Hard Disk Drive (HDD), Solid State Disk (SSD), Silicon Disk Drive (SDD), ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc. , and also includes those implemented in the form of a carrier wave (eg, transmission over the Internet). Accordingly, the above detailed description should not be construed as limiting in all respects and should be considered illustrative. The scope of this specification should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of this specification are included in the scope of this specification.

In addition, although services and embodiments have been described above, this is only an example and does not limit the present specification, and those skilled in the art to which this specification belongs will not deviate from the essential characteristics of the present service and embodiments. It will be seen that various modifications and applications not exemplified above are possible. For example, each component specifically shown in the embodiments can be modified and implemented. And differences related to these modifications and applications should be construed as being included in the scope of the present specification as defined in the appended claims.

Claims (8)

In the method for the server to disarm the link information of the DocumentSummaryInformation stream,
Checking a PropertySetStream record in the DocumentSummaryInformation stream;
checking field values of NumPropertySets of the PropertySetStream record;
determining whether the field values of FMTID0 and FMTID1 are valid based on the fact that the field value of the NumPropertySets indicates 2;
verifying a VtHyperlinks record based on valid field values of the FMTID0 and the FMTID1; and
disarming the link information based on the VtHyperlinks record;
Including,
The step of determining whether the field values of the FMTID0 and the FMTID1 are valid
The FMTID0 field value is a D5CDD502-2E9C-101B-9397-08002B2CF9AE value,
The FMTID1 field value is based on the D5CDD505-2E9C-101B-9397-08002B2CF9AE value.
delete According to claim 1,
Checking the VtHyperlinks record
Checking encoding information related to Dictionary Property in CodePage Property; and
Based on the encoding information, checking the character string “_PID_HLINKS” in the Dictionary Property;
Including, detoxification method.
According to claim 3,
Based on the confirmation of the "_PID_HLINKS", the VtHyperlinks record is included in the TypedPropertyValue.
According to claim 4,
The step of detoxifying the link information is
checking a VtHyperlinkValue record through a vtValue field of the VtHyperlinks record;
checking an array of VtHyperlinks through an rgHyperlink field of vecHyperlink of the VtHyperlinkValue record; and
disarming the hlink1 and hlink2 fields of the VtHyperlink record;
Including, detoxification method.
According to claim 5,
The step of detoxifying the hlink1 and hlink2 fields
leaving only schemes in the hlink1 and hlink2 fields;
Including, detoxification method.
According to claim 1,
Modifying a dwHash field based on the harmless link information;
Including, detoxification method.
In a server that disarms link information of a DocumentSummaryInformation stream,
communications department;
Memory; and
A processor functionally controlling the communication unit and the memory;
The processor
The PropertySetStream record is checked in the DocumentSummaryInformation stream, the field value of NumPropertySets of the PropertySetStream record is checked, and based on the fact that the field value of the NumPropertySets indicates 2, it is determined whether the field values of FMTID0 and FMTID1 are valid, and the FMTID0 and The FMTID0 field to check the VtHyperlinks record based on whether the field value of the FMTID1 is valid, to harmonize the link information based on the VtHyperlinks record, and to determine whether the field values of the FMTID0 and the FMTID1 are valid. the value is the D5CDD502-2E9C-101B-9397-08002B2CF9AE value, and the FMTID1 field value is the D5CDD505-2E9C-101B-9397-08002B2CF9AE value.

Images