Research Collection. Systematic Testing of Tor. Master Thesis. ETH Library. Author(s): Lazzari, Marco. Publication Date: 2014

Transcription

1 Research Collection Master Thesis Systematic Testing of Tor Author(s): Lazzari, Marco Publication Date: 2014 Permanent Link: Rights / License: In Copyright - Non-Commercial Use Permitted This page was generated automatically upon download from the ETH Zurich Research Collection. For more information please consult the Terms of use. ETH Library

2 Systematic Testing of Tor Master Thesis Marco Lazzari April 17, 2014 Advisors: Prof. Dr. D. Basin, Dr. M. Torabi Dashti, P. Tsankov, M. Guarnieri Department of Computer Science, ETH Zürich

3

4 Abstract We analyze the requirements that a framework for fuzz testing distributed security protocols should fulfill. Then we devise a framework that best meets the requirements. Our framework has a centralized sniffer to observe the messages that the nodes in the network exchange. In addition, it has a centralized fuzzer to mutate the messages. The nodes in the network are monitored for errors using dynamic analysis tools. We use our framework to test Tor, which is a widely used software for anonymizing TCP based applications. The challenges in fuzz testing Tor include dealing with cryptographic operations. We also provide a set of general guidelines to design and develop distributed software that is easier to test. i

5

6 Acknowledgements I would like to thank my mentor Prof. Dr. David Basin for the invaluable opportunity he gave me to write this thesis in his group. A special thank also to my supervisors Dr. Mohammad Torabi Dashti, Petar Tsankov, and Marco Guarnieri for their constructive suggestions, encouragements and discussions during the thesis. I am also thankful to Ernst Zachow for his contribution during the early stage of the thesis. Moreover I would like to thank my friends and my family for their continuous support and help during the course of my studies. iii

7

8 Contents Contents v 1 Introduction 1 2 Background Software Testing Fuzz Testing Requirements 9 4 Fuzzing Framework Centralized sniffer Centralized fuzzer Oracles Case Study Tor Overview Introduction Connections Cells Circuit construction and cells relay Directory Authorities messages and operations Observing Tor messages Sniffing Directory Authority messages Sniffing Cells messages Tor Fuzz Operators Directory Authority Fuzz Operators Cells Fuzz Operators Tor Oracles Experiments Testing Directory Authority v

9 Contents Testing Cells Related Work Fuzz Testing Testing Tor Conclusions Guidelines for simplifying testing Future Work Bibliography 41 vi

10 Chapter 1 Introduction Fuzz testing is an effective technique for finding vulnerabilities in software. Applying fuzz testing to distributed security protocols, such as The Onion Router (Tor) [3], is important for detecting vulnerabilities. Despite that, existing techniques are limited to two party protocols. Distributed security protocols can be fuzz tested by modifying protocol messages. This is challenging because such protocols are distributed, stateful, and furthermore they use cryptographic primitives. Most of the challenging tasks are protocol independent. For example, regardless of the protocol the tester needs ways to read and inject messages. Although there are tools that solve some of the challenges, none of the existing fuzz testing frameworks integrate them into one framework. To test a network protocol, the tester has to first integrate these tools before fuzzing the system. Contribution We provide a fuzzing framework to fuzz distributed security protocols. Using our framework the tester gets for free the following features: intercepting messages, injecting messages, generic fuzz operators to modify messages, generic oracles for detecting memory errors. Our framework can be extended and tailored to a specific protocol. To do so the tester must provide a set of protocol specific fuzz operators and oracles. To demonstrate our framework we use it to test Tor. We chose Tor because it consists of several sub-protocols, it is distributed, and it uses both asymmetric and symmetric encryption for exchanging messages. Such complex 1

11 1. Introduction protocols have never been extensively fuzz tested. Our framework decreases the complexity of the testing process and simplifies the testing of such protocols. Structure The rest of the thesis is organized as follows: In Chapter 2 we present the basic concepts of software testing, with a focus in fuzz testing. In Chapter 3 we define the requirements that a fuzz testing framework should meet for fuzz testing distributed security protocols. In Chapter 4 we describe our fuzzing framework. In Chapter 5 we introduce some basic concepts about Tor used during the case study and we exercise our framework to it. In Chapter 6 we summarize some relevant works about fuzz testing and the main works in testing Tor. In Chapter 7 we summarize the main findings and insights we collected from the case study and we propose further extensions to our work. 2

12 Chapter 2 Background 2.1 Software Testing Software testing is an important step during the software development process. It is an instance of verification techniques, which evaluate the quality of a software against its requirements and specification. They include the discovering of problems in the implementation that is the category where software testing falls. Testing means executing the software under test (SUT) with some inputs and checking for failures. Failures are deviations of the system s behaviour with respect to the intended behaviour [5]. The part of the testing system that reports a failure is called testing oracle. Once a failure has been discovered, the next step consists of discovering the reason for the deviation [5], namely the fault in the software code. Faults are the results of human errors during the development of the SUT. The ultimate goal of software testing is to find faults in the SUT. The aim of software testers is to find as many faults as possible in the SUT, given a set of constraints on the testing activity (e.g., time, money). There are three categories of testing based on the availability of the SUT s source code to test. Black-box testing: The tester has no access to the source code and the SUT is considered as a black box. When generating test cases, the SUT s internal structure is unknown. The tester benefits from the SUT s specification and when he knows what the software should do derives the test cases. White-box testing: The tester has access to the source code while testing, so the structure of the SUT is known. Therefore he can leverage this knowledge to generate more thorough test cases. The tester should 3

13 2. Background remember that if a part of the source code is not executed in any test case, faults in that part cannot be exposed [13]. Gray-box testing: The tester has partial access to both the specification and the source code. This terminology usually refers to the set of testing techniques that lies between black-box and white-box testing. There is not a single meaning behind that definition and a mix of methods or non-standard testing approaches may be necessary. To get the most benefit from testing, the three approaches described above do not have to exclude each other. What black-box testing is not able to get, probably is caught by white-box testing and vice versa. For a complex software, a good tradeoff could be to use black-box testing to exercise the external interfaces and white-box testing to test more in depth some critical functions not directly visible from outside. 2.2 Fuzz Testing When building software often the final product that a developer has implemented does not meet completely the specifications. The differences between the specification and the implementation are faults of various types [18]. We depict the differences between software specifications and software implementation in Figure 2.1 [18]. Figure 2.1: Difference between specification and implementation. 4 In Figure 2.1, the inner circle boundary represents the limit between the positive requirements, that say what the software should do, and the undefined requirements. The outer circle is the limit before the negative requirements that say what the software must not do. However, the system however typically does not implement all the desired functionality. Furthermore, it may implement undesired functionality. These are often called side effect func-

14 2.2. Fuzz Testing tionality, which are often critical for security. Fuzz testing is a black-box testing technique for discovering side effect functionality in the software, i.e. general undesired behaviours such as memory errors and improper input validation [8, 18]. Semi-valid inputs are inputs that are not valid according to the specification but they violate only few constraints. They are more likely to not get blocked by the input parsers and therefore they are more likely to expose flaws in the SUT, which are then reported for further analysis [10]. In fuzz testing, as shown in Figure 2.2, the SUT is provided with semi-valid inputs in an automated way. Figure 2.2: A simple fuzzer architecture. Although the approach is simple, its effectiveness has been shown empirically, e.g., [21]. It is a common practice to use a simple fuzzer, i.e., one that provides random inputs to an interface, as a first step in a fuzzing procedure. Then the fuzzer can be refined to generate more structured inputs that try to test an interface thoroughly. Fuzz testing has probably been inspired by its analogue in hardware testing, i.e., fault injection. Suppose we have a cryptographic hardware module that stores a pair of public/private keys. If an I/O pin breaks, we would like that the private key will never leaks from the device through another working pin. In this setting, a fault injection test could be to break a pin voluntarily and see if the keys are leaked. In Figure 2.3 we present the phases in a fuzzing process [18, 16]. SUT and Input Identification: When a SUT is identified, the scope of the testing must be defined. The number of interfaces may be large and not all of them can be easily fuzz tested, for example internal interfaces. In contrast, the interfaces that accept user inputs must be considered because they are accessible to the tester. Inputs Generation: There are mainly two kinds of inputs generation strategies to get fuzzed inputs: Mutation: This is the simplest one because it does not require to understand the SUT s inputs format. The legitimate inputs that 5

15 2. Background Figure 2.3: The fuzzing process. come both from the network and from local archives are modified and sent to the SUT. Fuzz Operators (FOs) are functions that modify the legitimate inputs. This approach benefits from the variety of test cases that can be obtained only with minor modifications from the legitimate inputs. Generation: It is a way to generate fuzzed inputs based on a profound knowledge of the SUT. This often increases the complexity of the inputs generation procedure. The fuzzer should create inputs that conform to the format of the SUT. Therefore, the fuzzer usually has a model or a grammar that defines the format of the inputs. Besides the two main classes presented above, several fuzzers include some libraries of known inputs that have been used previously by testers to expose software flaws. Inputs Delivery: Fuzzed inputs must be delivered to the SUT. Delivering could mean to send a data packet through the network to the target, to open a file, or to run a process. SUT Monitoring: Monitoring the SUT is crucial during fuzzing. It does not matter how well we generate the inputs if we are unable to monitor appropriately the system and report the problems. There is not a single way to monitor the SUT but rather a set of guidelines that complement each other [18]. The main categories are summarized below. A SUT can be continuously asked for the service it should normally offer to the clients. If that service is no more available, it could be that the SUT has crashed or has experienced some internal errors that prevent new requests to be served. Although an unavailable service indicates a failure, the fact that the service is available does not imply that there are no failures; for instance the SUT might be available but in a wrong state. 6

16 2.2. Fuzz Testing Monitoring system resources can suggest that there may be an issue. Examples of interesting parameters include CPU usage, threads and processes creation rate and hard disk writing and reading rates. Binary simulation consists in running the SUT using a synthetic processor. This is the approach used by Valgrind [9]. The synthetic processor provided by Valgrind is a virtual CPU that executes every single instruction of the SUT. When the SUT is executed for the first time, it is passed to a set of instrumentation tools, like Memcheck [7], that add instrumentation code used to monitor, for example, memory accesses. The instrumented code is then executed by the virtual CPU and in the case of errors the tool reports them. In this way, Valgrind s Memcheck allows to keep track of all memory allocation and deallocation operations as well as all memory accesses. For instance, it can detect problems like the use of uninitialized values, double frees, and heap overflows and corruptions. Source code transformation aims to instruct the source code of the SUT in order to add additional security checks on memory allocation instructions that should signal memory problems. The transformed code is then compiled and tested. An example of such a tool is the commercial software Insure++. Results Analysis: The results are categorized following levels of severity and the next steps consist in fixing any discovered vulnerabilities. 7

17

18 Chapter 3 Requirements The goal of this thesis is to devise a framework for fuzz testing distributed security protocols. Our framework is general and is parametrized by a concrete SUT. Distributed security protocols are often complex. For example, the protocol can consist of multiple simpler protocols that interact together. Also, the protocol may be stateful. Due to the high complexity and statefulness of distributed protocols, the tester needs an in-depth knowledge of the SUT to use a generation-based strategy for generating fuzzed inputs (see Section 2.2). This might require a lot of effort from the tester. This approach might be not desirable because it is costly and time-consuming. Therefore, we focus only on the mutation-based strategy for generating fuzzed inputs (see Section 2.2). We identify three requirements that a general mutation-based fuzz testing framework should fulfill. Note that in a distributed setting the SUT may be composed of many nodes. R1: Message observation. Full observation of clear text messages that the SUT s nodes exchange with each other. Observing the messages in the network is essential because we do not use a generation-based strategy to get the inputs to be fuzzed. Note that we are only interested in observing SUT s layer messages, i.e., application layer messages. Moreover, it is important to have access to all the messages in the network. Our goal is to test a distributed system and observing only a subset of the messages would give the fuzzer less possibilities to expose failures. Indeed, the fuzzed inputs depend on the observed messages. Observing SUT s layer messages in clear text, i.e., without any lower layer encryption, is also important. Suppose that the SUT s nodes communicate using SSL. Fuzzing messages without removing the SSL 9

19 3. Requirements layer implies that we are actually fuzzing the SSL protocol implementation instead of the SUT. R2: Message mutation. Ability to modify each message collected from the SUT. This requirement is strictly related to the previous one. In fact, to modify each message, we must be able to observe all network traffic in the distributed system and this entails the possibility to fuzz each message. The fuzzer framework should provide ways to modify messages to expose failures in the SUT. R3: Oracles. Availability of testing oracles that check test results on an individual node of the SUT and on the SUT as a whole. As dicussed in Chapter 2, it is crucial in any testing framework to monitor the results of the tests. Therefore, even a fuzz testing framework has to provide ways to detect failures. A fuzz testing framework for distributed security protocols must provide mechanisms that meet these requirements. We recall that a fuzzing process consists of several steps as we shown in Chapter 2. The requirements we proposed are necessary because a fuzzing framework that meets them, implements the two main steps of the fuzzing process we have described, i.e., Inputs Generation and SUT Monitoring. The results of fuzzing strongly depend on how thoroughly a tester designs and implements these two phases in a fuzzing process, and in turn in a fuzzing framework. However, as said in [21], fuzz testing is intrinsically incomplete because it is often infeasible to test a SUT, e.g., a distributed security protocol, against all possible inputs and states. So, our requirements are not sufficient to construct a framework which exposes a fault, provided that a fault is present in the SUT. 10

20 Chapter 4 Fuzzing Framework In this chapter we present our fuzzing framework and its components. We designed the framework to address the requirements presented in Chapter 3. We remark that since the requirements are independent of the SUT, our framework can be adopted for testing different SUTs. In Section 4.1 we describe the component of the framework that fulfills R1 and the part of R2 regarding the injection of messages in the network. In Section 4.2 we describe the component that fulfills the part of R2 regarding the message mutation operations. In Section 4.3 we describe the component that fulfills R Centralized sniffer A distributed system exchanges messages among the nodes in the system. We are interested in fuzzing any message in the network, therefore we decided to adopt a centralized network sniffer. If every message in the network passes through the sniffer before reaching its intended destination, this solution partially fulfills R1. In [21], Tsankov et al. used a sniffer that is placed on one communication link and it allows to observe a subset of messages in the network. Although their approach can be extended to all communication links, this requires a large number of independent sniffers. Since Tsankov et al. do not provide methods for coordinating the sniffers, the tester has to address this problem, extending the proposed architecture. Since we are dealing with security protocols that involve cryptographic operations, R1 is met if the sniffer has access to the same cryptographic material, e.g., keys and random numbers, that the nodes use when processing messages. The cryptographic material depends on the SUT. This gives the sniffer the ability to observe SUT s layer messages in clear text. Note that to meet R1 the sniffer do not have to remove application layer encryption, if there 11

21 4. Fuzzing Framework is any, while this may be necessary to meet R2 (see Section 4.2). However, there is not always a unique and straightforward way to remove the cryptographic operations from a protocol to fulfill R1. Detailed examples are given in Chapter 5. The building blocks of our centralized sniffer are shown in Figure 4.1, where we sniff messages for Node 2 and Node 2 s replies. We have two nodes, Node 1 and Node 2, that run the SUT. Relay is the component that forwards the incoming messages to Node 2 and sends them to the centralized Sniffer. Figure 4.1: Building blocks of our architecture for sniffing and injecting messages. 12 Suppose that Node 1 is the machine that sends messages to Node 2. Node 2 runs on port 1000, and the nodes that connect to it know this port number. In our architecture, we run the Node 2 on a different port. For example, in Figure 4.1, Node 2 runs on port 1001 instead of port On the original port, i.e. 1000, we run our software component that we called Relay. The message flow is as follows. Relay receives incoming messages for Node 2 and relays them to the Sniffer. The Sniffer receives the messages and send them back to the Relay. Relay forwards the messages to Node 2, i.e., port 1001, and waits for a reply, if there is any. In case of a reply, the Relay sends it to the Sniffer and waits its response. Relay sends the reply message to Node 1. The case presented in Figure 4.1 is common when Node 2 is a server and Node 1 is an application, and the main goal is to sniff messages directed to the server.

22 4.2. Centralized fuzzer For some distributed systems, such as Tor, the architecture is more complex and it has multiple nodes. The architecture in Figure 4.1 can be extended to sniff the messages for multiple nodes. When we have multiple nodes, we have to run one Relay software per node in the network. In this way the message flow explained above is replicated for each connection between two nodes and this allows the Sniffer to get all messages in the network. 4.2 Centralized fuzzer The centralized Sniffer presented in 4.1 allows to observe and inject all the messages exchanged by the nodes. However, to fulfill R2, we must be able to modify messages. To do that, we use a centralized Fuzzer that extends the functionality of the Sniffer (see Figure 4.2). Firstly the Fuzzer collects the messages from the Sniffer. Then it mutates the messages before they reach their intended destination. To mutate the messages the Fuzzer uses a set of Fuzz Operators (FOs). Figure 4.2: Building blocks of our architecture extended with the Fuzzer. A fuzzer can be classified as intelligent or non intelligent [18]. An intelligent fuzzer may use the messages that passes through it to infer some information about the status of the nodes, or it may know the format of the protocol it is testing while a non intelligent does not. There is not a unique definition behind this classification, however, as said in [18], there is no strict correlation about the intelligence of the fuzzer and its ability to discover bugs. For example, a non intelligent fuzzer may just have a FO that flips a bit in the message, while an intelligent fuzzer may have a FO that modifies messages depending on the sequence of past messages. Fuzzers should implement FOs that combine both strategies because they complement each other in discovering bugs. The tester can use the intelligence of the fuzzer to define protocol specific FOs. Therefore the framework is parametrized by SUT specific FOs. So, different SUTs can be tested with our framework with their specific FOs. The Fuzzer should also provide the mechanisms that allow to inject messages without violating any integrity checks (e.g, signature, MAC). A fuzzed mes- 13

23 4. Fuzzing Framework sage violating an integrity check may get to the destination but it is very likely to get dropped. We refer to that fuzzed message as invalid, while we refer to a fuzzed message respecting integrity checks as semi-valid (see Chapter 2). Similarly to what described in Section 4.1, the ways the integrity checks are removed depend on which protocol the Fuzzer is targeting. 4.3 Oracles A fundamental part of any testing system is the oracle that determines the results of the tests [21]. Different types of oracles exist depending on the failure they try to detect. For example, local failures, such as memory errors, can be detected by monitoring the behaviour of one node using local oracles, e.g., Valgrind s Memcheck. However, there are failures that cannot be detected by solely monitoring the behaviour of a single node. In fact, while an individual node may not experience any failure if considered alone, a set of nodes may experience a failure when they cooperate to provide a service. Examples of such failures are known as partitioning or synchronization problems where a set of nodes may be in one state while another set is in another state. Although each node may behave correctly, the behaviour of several communicating nodes may be incorrect. To monitor a distributed system while fuzzing, besides the use of local oracles, the tester should provide functional oracles that can detect failures by monitoring multiple nodes. For instance, functional oracles may check if a service offered by the distributed system is available or not. As explained in Section 2.2, checking for system availability does not imply checking its correctness, but it is a way to detect failures in a distributed system that can be missed by local oracles. As occurred in Section 4.2 for SUT specific FOs, our framework is parametrized by SUT specific oracles (e.g. functional oracles). Therefore, different SUTs can be monitored by SUT specific oracles. 14

24 Chapter 5 Case Study We use our framework to test Tor. For each requirement defined in Chapter 3: we propose a number of approaches that fulfill the requirement and we apply them to our case study (Tor). we explain the main difficulties that we have found during the implementation phase and we describe how we have overcomed that issues. In the next sections, the Tor case study refers to two different subsets of Tor protocols. Both of them are important components of Tor. They are necessary to Tor to work properly. The first is described in Section The second is presented in Section These protocols are prone to be used by an attacker because he can run the Tor software in user mode and manage to cause a failure in that protocols. 5.1 Tor Overview Introduction The Onion Router (Tor) [3] is a widely used distributed overlay network that aims to protect the privacy of users. It consists of a set of nodes, called Onion Routers (ORs), which run the Tor software in user mode. Tor can be used to anonymize any application, such as instant messaging software and web browsers, that uses TCP as transport layer protocol. Each user, which can either be the Tor embedded browser or another application, that wants to communicate through Tor has to use Tor local software called Onion Proxy (OP). A circuit is a communication path that connects an OP with a sequence of ORs. To create a circuit, an OP chooses a set of ORs from a publicly available 15

25 5. Case Study Figure 5.1: An example of a circuit in the Tor network. list of ORs and connects all of them to form the path. The list of available ORs is provided by the Directory Authorities (DAs), which are described in details in Section Once the circuit is created, the OP can send data, which come from the application, through it. Data flows in the network in fixed-size messages called cells. For example, in Figure 5.1 we have a web browser that uses Tor and it wants to get a web page. First, OP creates the circuit OP - OR1 - OR2 - OR3. After that, OP sends the HTTP GET request to the first hop (OR1) of the circuit just opened. The ORs in a circuit receive the data and pass it to the next OR of the circuit. After receiving the request, OR3 sends it to the web server, it waits for the reply and it sends back the web page to the client using the same circuit. OP builds circuits telescopically, one hop at a time, and each time it negotiates a symmetric key with each OR it decides to add to the circuit. Before sending a cell, OP encrypts it one time for each OR in the circuit (like the layers of an onion) using the symmetric keys shared with the ORs. Each OR in the circuit has to perform a symmetric decryption operation on each cell and relays it to the next hop. In this way, only the last OR receives the decrypted content. Moreover, an OR along a circuit only knows its direct neighbours and it does not know the remaining ORs in the circuit. For example, in Figure 5.1 OR3 does not know that the first hop of the circuit is OR1. The rest of this section is organized as follows. In Section we explain how two Tor nodes connect to each other prior to sending cells. In Section we explain the various types of cells and their format. In Section we explain how an OP creates a circuit and relays cells. In Sec- 16

26 5.1. Tor Overview tion we explain the role of the Directory Authorities in Tor Connections ORs communicate using the TLS/SSLv3 protocol [17]. TLS/SSLv3 is a session layer protocol in the Internet protocol suite. Its purpose is to provide secrecy and integrity between two applications. So, both the data the user wants to anonymize, namely the data that the OP inputs to the Tor network, and the control data of the Tor protocols are encrypted when traversing the Tor network. Each OR has several public/private key pairs: A long term Identity Key, which is created when the machine joins the Tor network for the first time. This key is used to sign documents that are needed to execute the Tor protocols, e.g., the Router Descriptor message that each OR generates when it boots up, as well as to establish the OR s identity when it connects to other ORs. An Onion Key, which is used during each negotiation of symmetric key pairs mentioned above. More in detail, it is used by the OR to decrypt the incoming requests from other ORs or OPs when they want to build a new hop of a circuit through it. A short term Connection Key that is rotated periodically and is used during the TLS/SSLv3 handshake between two ORs. The TLS/SSLv3 handshake may involve two ORs, where each of them can initiate the connection. Also it may involve an OP and an OR, where only the OP initiates the connection, because it is the entrance point in the Tor network. There are different TLS/SSLv3 handshake variants currently supported by Tor ORs and OPs. Their main purpose, besides the creation of a secure channel, is to authenticate the ORs. As a part of the handshake, the ORs exchanges a self-signed certificate containing its Identity Key Cells ORs communicate with each other using cells. The format of a cell is shown in Figure 5.2. Figure 5.2: The format of a Tor cell. 17

27 5. Case Study Each cell has three fields: Circuit ID: A nonzero integer 1 of length 2 2 or 4 bytes. It uniquely identifies a hop in a circuit, namely a connection between an OP and an OR or an OR and another OR. This means that a Tor circuit is identified by a sequence of Circuit IDs, one for each hop. Command: A 1 byte integer that describes what the cell is used for. We discuss the different commands shortly. Data: It is the 509 bytes payload 3 of the cell. Its content varies depending on the Command and it is possibly padded with 0 bytes. We summarize below the main cell types and their purposes. Create, Command=1: The Data field contains the first half of the handshake data used to create one hop of a circuit. Created, Command=2: The Data field contains the second half of the handshake data used to create one hop of a circuit. Destroy, Command=4: It instructs an OR to close the circuit and delete all the information associated with it. The OR then propagates the Destroy cell along the circuit. Relay, Command=3: It carries data between two nodes of the Tor network. When this cell is used the first 11 bytes of the Data field, called relay header, are reserved. The rest of the payload contains the actual data. The Data field of a Relay cell is the portion of data that the OP encrypts with the symmetric keys (using AES-128 in counter mode) shared with each OR. In the example in Figure 5.1, the HTTP GET request is carried in the Data field of a Relay cell. The OP encrypts the Data field with the symmetric keys of OR3, OR2 and OR1. Only the last hop of the circuit, i.e., OR3, is able to get the Data field in clear text, since each OR removes one layer of encryption. We now describe the fields of the relay header (Figure 5.3). Figure 5.3: The Data field of a Relay cell Except for specific cells that can be used during the connection set up phase. 2 Depending on the Tor software version. 3 Except for variable length cells where Data is prepended with a 2 bytes field that indicates its length.

28 5.1. Tor Overview Relay Command: It indicates the purpose of the Relay cell. For instance, a) RELAY BEGIN indicates to the last OR of a circuit to open a new TCP connection to the intended recipient of the TCP connection; b) RELAY DATA indicates that the Relay data field of the current cell contains data that need to be forwarded on a TCP stream opened by a RELAY BEGIN; c) RELAY EXTEND says to the OR to extend the current circuit (the one in the Circuit ID field) with a new hop. The OR can then send a Create cell to the new hop of the circuit. Recognized: This field is set to 0 when the Relay cell is sent by the OP. If the receiver verifies that this field is indeed 0, then it knows that it has properly decrypted the Data field of the Relay cell, otherwise the cell is corrupted. StreamID: it is a unique identifier for the current circuit for a TCP connection that we want to anonymize. Digest: It is an end-to-end integrity checksum between an OP and the last OR in the circuit. It prevents that arbitrary cells can be accepted and processed by an OR if the OP has not sent them. The receiver considers a cell valid, for the purpose of processing it, if both the Digest is correct and the Recognized field is set to 0. Length: The length in bytes of the Relay data field that is not padded. Relay Early, command=9: The structure of this cell is the same as that of a Relay cell. However, this cell limits the length of a circuit because a node that receives more than 8 Relay Early cells on the same outbound Circuit ID has to close the circuit. In the most recent versions of Tor the circuit extension operation is processed only if it comes with a Relay Early. Create Fast, Command=5 - Created Fast, Command=6: They are optionally used to create the first hop of a circuit. The handshake data is different from Create and Created Circuit construction and cells relay We explain here the circuit construction protocol using the example in Figure 5.4. There is an OP, that accepts requests from applications, two ORs and one web server that is outside the Tor network. The OP creates the first hop of the circuit to OR1. After that, it instructs OP1 to extend the circuit to OP2. The circuit is then created and OP can send data to the web server 19

29 5. Case Study through it. Usually, there are 3 ORs in a circuit but we show the example with 2 for simplicity. Figure 5.4: The circuit construction steps. 20 To create a new circuit, the OP selects a sequence of ORs OR 1,..., OR n, where n N, that will compose the circuit. As we said before, the OP shares a pair of symmetric keys with each OR in the circuit. Since the circuit is built telescopically, the OP shares a key pair with the first hop (OR1). We say that a Circuit ID is fresh if it has not yet been chosen on the current connection. OP sends a Create cell to the first hop with a fresh Circuit ID. The payload of the Create cell is the so called TAP Onion Skin that is the first half of a Diffie-Hellman handshake (g x 1) encrypted with the public Onion Key of the OR1. Then OP waits the response from OR1. OR1 sends a Created cell that contains the plain text of the second half of the Diffie-Hellman handshake (g y 1) and 20 bytes of key derivative material (key-mat1 in Figure 5.4), which OR1 calculates using the shared key (g x 1y 1 ). The OP calculates the shared key (g x 1y 1 ), derives the 20 bytes of key derivative material, and compares it to the one received. If they are the same then OP and OR1 have shared the correct key. OP and OR1 are able to derive the set of shared symmetric keys that are used for the communication between them. They derive four keys from the shared key. K f1 and K b1 which are used for the forward and backward symmetric encryption of Relay cells between the OP and OR1. D f1 and D b1 which are used to seed the forward and backward running digest functions on all the data sent to or received by OP and OR1. The value of these functions is put into the Digest field of a Relay cell. The first hop of the circuit is built. Suppose now that the OP wants to extend the existing circuit OP - OR1

30 5.1. Tor Overview to OR2. OP instructs OR1 to create a new hop. It sends to OR1 a Relay Early cell with the Circuit ID of the first Create cell, Relay Command equal to RELAY EXTEND in the relay header, the IP address and the port of OR2 and a TAP Onion Skin encrypted with the public Onion Key of OR2. The payload of this Relay Early is encrypted one time with K f1, the symmetric key that OP shares with OR1. OP adds in this way one layer of encryption. The payload 4 is depicted in Figure 5.5. Figure 5.5: The payload of a Relay Early cell. OR1 receives the cell and recognizes that it belongs to a previously created circuit. Since the cell Command is Relay Early, it fetches the correct symmetric key and removes one layer of encryption. It checks that the Recognized field is set to 0 and the Digest is computed correctly. OR1 processes the cell accordingly to the command in the relay header. It extracts the data from the payload and creates a new Create cell with the received TAP Onion Skin and a fresh Circuit ID. OP1 sends this cell to OR2. When OR1 receives the Created cell from OR2, it cannot learn the set of keys shared between OP and OR2 (namely K f2, K b2, D f2 and D b2 ) because it knows only the second half of the Diffie-Hellman handshake (g y 2) and does not know the private key of OR2 (x 2 ). The content of the Created is packed back to OP in a Relay cell with Relay Command equal to RELAY EXTENDED. The payload is encrypted with K b1. The OP receives the Relay cell that allows to complete the circuit extension operation to OR2. The circuit that is now active (OP - OR1 - OR2) can either be extended again to another OR or it can be used to anonymize TCP connections. In the second case, Relay cells with Relay Command RELAY DATA will be sent through it. The symmetric encryption procedure is the same as before: the OP will encrypt the payload of a Relay cell first with K f2 and then with K f1. OR1 will remove the first layer of encryption but since the Data field is still encrypted, it does not consider itself as a receiver, so it passes it to the next hop. OR2 removes the second layer and since at this point the cell is fully decrypted it will process its content. When a cell is sent back from OR2 to OP, each OR in the circuit adds one layer of encryption with K bor. Only the OP is able to get that cell in clear text because is the only node that knows all the symmetric keys K bn. The circuit can be torn down either because the OP does not want to use it 4 Actually one more field is present: the Identity Fingerprint of OR2. See [20]. 21

31 5. Case Study 22 anymore or because an error in one of the circuit s link has occurred. For example, the OP can send a Destroy cell to OR1. If the Circuit ID of that cell is known to OR1, the first hop is torn down. Therefore other cells with that Circuit ID are discarded. The Destroy message is then propagated along the circuit Directory Authorities messages and operations The glue of the Tor network, namely the mechanism that allows the OPs to select the ORs when they build circuits, is represented by the Directory Authorities (DAs) [20]. Directory Authorities are a small set of servers (5 to 10) that provide a signed list of ORs in the Tor network. Intuitively, when an OP wants to create a circuit, it needs up-to-date information about the ORs in the network (e.g., their status, their addresses, their Onion keys). The purpose of the Directory Authorities is to collect this information and provide it to the other nodes in the network. A DA is also an OR. In addition to OR s keys, a Directory Authority has the following public/private keys: A long-term and sensitive Authority Identity Key, which is stored offline and identifies uniquely a Directory Authority. It is used periodically to sign a new Key Certificate that is a document that contains an Authority Signing Key. A medium-term Authority Signing Key, which is used by the Authority to sign all the documents and the data that it sends to the network in the daily operations. Directory Authorities accept Router Descriptors from the Onion Routers in the network. A Router Descriptor summarizes the status of a certain Onion Router and provides information about the Tor version that the OR is running as well as its public Onion Key. Multiple Router Descriptors can be published by the same Onion Router and each indicates a change in the router status. The document is signed by the OR with its Identity key. The aim of the Directory Authorities is to generate a Network Status Consensus document that contains a description of the Tor network status. Since all the Authorities have to agree on a common view of the network, they run a consensus protocol that uses as input the Router Descriptors and produces as output the Network Status Consensus. A consensus algorithm, given the same set of inputs documents, allows to compute the same output document to all the parties that execute the consensus. For several reasons, e.g., network latency and broken links, at the same point in time two Directory Authorities may have a different view of the network, i.e., different sets of Router Descriptors. Before computing the content of the

32 5.2. Observing Tor messages Network Status Consensus document, each DA communicates to the others its view of the network using a signed document called Status Vote. The Authorities can now run the consensus algorithm using these documents. We present an example of Network Status Consensus document in Figure 5.6. The document contains a preamble with the information about its publication, its validity and the directory authorities that generated it. The document also contains a list of the active routers in the network with various data. Besides the router s name, we can find the hash of the router s identity key, the hash of the router s most recent descriptor and the router s address where it is available. The document is signed by the Authorities with their Authority Signing Key. The OPs can download the Network Status Consensus from the Directory Authorities and they can use it to decide which ORs to choose when building circuits. The document is also used to keep the Router Descriptors up to date. As shown above, the Network Status Consensus document lists for each router a digest of its most recent Router Descriptor. The client can then compare that hash with the hash of the descriptor it stores locally and possibly downloads the most recent version from the Directory Authority. To reduce the communication overhead introduced by the download of the descriptors from Directory Authorities, there exists an additional layer of servers called Directory Caches. They are normal ORs that are able to give a Router Descriptor to the client directly upon requests. All Directory messages are uploaded and downloaded using HTTP. 5.2 Observing Tor messages Sniffing Directory Authority messages When an OR wants to join the Tor network, it sends to the Directory Authorities its Router Descriptor, advertising its current status, and requests the most recent version of the Network Status Consensus document. Our goal here is to observe the Directory Authorities that accept the messages that the OR sends. To allow the Sniffer to have access to these messages we used the sniffing architecture presented in Section 4.1. The network setup is shown in Figure 5.7. OR connects to the port where our Relay software is running. This was done by modifying the OR s configuration file (torrc). In this way, when the OR advertises itself to a DA, it sends the messages to our Sniffer. It does not send the messages to the DA directly. In Figure 5.8, we give an example of the HTTP POST message that has the Router Descriptor document as its message body. Relevant information in 23

33 5. Case Study network-status-version 3 vote-status consensus consensus-method 17 valid-after :35:00 fresh-until :40:00 valid-until :50:00 voting-delay client-versions server-versions known-flags Authority Exit Fast Guard HSDir Running Stable V2Dir Valid dir-source DirectoryServer1 A5F879A7C6F8244FD DBC C4A contact mlazzari@student.ethz.ch vote-digest 0B57BC9476E4C1DCA00BA7DF7130AB969EE9EA47 r Relay2 Bf1vCualkdU0tBQOo2it7APND/c BeCe12BTd3AyPfe6l4Zb4+bjm3M :29: s Exit Fast Guard Running Stable Valid v Tor alpha-dev w Bandwidth=53 Unmeasured=1 p reject 25,119, ,445,563,1214, , ,6699, r DirectoryServer1 FizAOmnzywpoJ2/Yk/Xmz/zVntk 3u+3PAsAjcYeP5XrZysF2sQYCik :23: s Authority Exit Fast Guard HSDir Running Stable V2Dir Valid v Tor alpha-dev w Bandwidth=90 Unmeasured=1 p reject 25,119, ,445,563,1214, , ,6699, r Relay1 MpUdoVDJx2yxXUUjVjU5lcJqJLI fptvp3o/bfhhxaa/9tfd2rtcdbi :30: s Exit Fast Guard Running Valid v Tor alpha-dev w Bandwidth=33 Unmeasured=1 p reject 25,119, ,445,563,1214, , ,6699, r Relay3 1QyJk6vXTusYfqBs3saIJ3ikjFY m6xvuwfcljjoa2qj7vmcejfmi3s :27: s Exit Fast Running Stable Valid v Tor alpha-dev w Bandwidth=81 Unmeasured=1 p reject 25,119, ,445,563,1214, , ,6699, directory-footer directory-signature A5F879A7C6F8244FD DBC C4A 7C57351FB009BC2F0E84E16FEDEA091C5C0940B BEGIN SIGNATURE----- H72GQPOd2fzuUKZpOq8dn6aK+5SJhc9p9MNMbMQNZngBzTOSXdzz5yfh/+GxxQ/G xx29gs0qlbocb1zdaxhw1bfguejiw2evm/t64z+l3ttylwqfrllu1l9q2d61mmhs XIz6sZrP6buRLPHMsfjLukH4vm4UKREcbuteWFlVAto= -----END SIGNATURE----- Figure 5.6: A Network Status Consensus document. 24 the message body are the name, the IP address and the port of the OR. The public Onion Key and the public Identity Key are also sent to the DAs. The router-signature sections are generated with the OR s private Identity Key.

34 5.2. Observing Tor messages Figure 5.7: Network setup for Directory messages sniffing. The bottom section, called extra-info, contains optional information such as the OR s bandwidth usage in the past (write-history and read-history fields). In Figure 5.9, we give an example of the HTTP GET request for the Network Status Consensus document that the OR sends to a DA Sniffing Cells messages The basic units of communication in Tor are the cells. Observing Tor cells in a live network is more difficult than in because multiple nodes are involved. So, we need to extend the sniffing architecture to all the machine in the Tor network. We explain below the three main challenges we have found and how we have addressed them. Links encryption: ORs communicate over TLS. To allow the Sniffer to observe the cells in the network, we first have to remove the TLS layer, which provides encryption and integrity. However, we cannot completely remove TLS between two ORs, because to boot up correctly the two ORs use a TLS handshake to exchange their Identity Keys. Therefore, to be less intrusive as possible, we only changed the TLS cipher suite to the one with no encryption 5. With this change the cells appear to the Sniffer in clear text. Network topology: We want to capture all the cells in the network, therefore all the nodes need to know the ports where the other nodes are available. An OR acquires information about the status of the network from the Network Status Consensus document sent by the DA. Note that this document contains the information on the ports where the other ORs are available. Since the Network Status Consensus document is generated by the DAs from a set of Router Descriptors, we use 5 SSL3 TXT RSA NULL SHA provided by OpenSSL library. 25

35 5. Case Study POST /tor/ HTTP/1.0 Host: :9030 X-Desc-Gen-Reason: dns resolvers back Content-Length: 1787 router OR platform Tor alpha-dev on Linux protocols Link 1 2 Circuit 1 published :04:42 fingerprint 7E79 E808 1AEF D859 E201 1A C990 3BEC 9202 uptime 0 bandwidth extra-info-digest 1EC6A2A1AFE4DC916939A2D12D5C34AA86864E53 onion-key -----BEGIN RSA PUBLIC KEY----- MIGJAoGBALf+gvGozgo5iDo+Y/HPfz3jxezrgrpCLt1Mic8aVbU1gAHdeYEQQU3z GOj/a9LOWG1vE305TK6C6yusHOfuShuYZRPqdEYLDSSx9kDbOJ8uNQ8u142oG9oU 0cnC5GzXXZ0FZ0OzgX6cHd5vWkKO7WEwU8L5hNj8/OJHPkWzUwrXAgMBAAE= -----END RSA PUBLIC KEY----- signing-key -----BEGIN RSA PUBLIC KEY----- MIGJAoGBAMgdK0sR54wQd6AWaoYg5BzWMrhtzjhYyJLkUC+7uANptjh3E7wLEd/1 LT/qeo45ucLuGPNRRALpGYcjwNTQzWWlZ59xLr2+0rq5u7lO6Xm2r7mQxkBqJQde 9fSw3+L7FQdS8oMCe7rm6qA/N2/ZKkOiOOuACZEaqyyWkTXafZuvAgMBAAE= -----END RSA PUBLIC KEY----- hidden-service-dir contact mlazzari@student.ethz.ch ntor-onion-key W/NmDV56DfApFnKD5sf57Ozxh3yKLFE+Hqyxq7qJbWY= reject *:25 reject *:119 reject *: reject *:445 reject *:563 reject *:1214 reject *: reject *: reject *:6699 reject *: accept *:* router-signature -----BEGIN SIGNATURE----- m6tznmnxlpjcyx9jhpoq9waesfgicizn3oqudzay4gng7bwvyzputjjuuroptcvr n/l+wymmc2kgbsqpvua9owsj9szqa/xtwvi7rs2+s7w5kggktapub1ax16tdked8 o6t7onvlkaimqglzcj2yuvz4aqsdnww7eczgjjrvmvg= -----END SIGNATURE----- extra-info Relay3 7E79E8081AEFD859E2011A371221C9903BEC9202 published :04:42 write-history :42:35 (900s) 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,460800,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 read-history :38:01 (900 s) ,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 geoip-db-digest A28267CED18A1D80B E9FE42EC755420C0 geoip6-db-digest 7F82A502C248B0CFBCCF6FE370919E34E04A21FA router-signature -----BEGIN SIGNATURE----- W6fwuMad/Px1nijF/TnaPBXEMUq24WXRhg7UshQKhhqLX1o8di74uqUpfSRNXQ6r uuuqqizck2mtcnssc+auowvnfmriapiat7ookhf8fsrppj9ydjdwxzmn3mnugu5e Tn8Arfao1r5vTa4Gxc3n5CpnjGtPgDcI8iW3DNUq3oo= -----END SIGNATURE----- Figure 5.8: Example of POST message containing a Router Descriptor. 26 the architecture in Figure 5.10 to modify the view of the network status that the ORs have.

36 5.2. Observing Tor messages GET /tor/status-vote/current/consensus/703ddd.z HTTP/1.0 Host: :9030 If-Modified-Since: Wed, 11 Mar :38:00 GMT Figure 5.9: Example of HTTP GET request for the Network Status Consensus. Figure 5.10: Network setup for sniffing cells. The setup is as follows: the Relay software is running on port 9002 on all the nodes and the instances of Tor are running on port For example, when OR2 wants to communicate to other ORs, it needs to know that they are available on port After receiving a message, the Relay component forwards it to the Sniffer following the steps described in Section 4.1. When the Sniffer receives a Router Descriptor message from an OR, it sets the value of the port attribute in the message to the port of the Relay component. The Sniffer, which has access to all cryptographic material, signs the Router Descriptor with the Identity Key of the OR. Then, it forwards the modified message to the DA that updates the OR s status accordingly. Figure 5.11 shows an example of the modified Router Descriptor that OR3 sends to the DA. The Sniffer changes the port advertised by the OR, i.e., 9001, to 9002 where our framework is running. The mechanism that we have described is replicated for all the ORs in the network. With this framework in place, the DA is now able to compute the new Network Status Consensus that will contain the associations between the ORs in the network and the ports where the Relay components are running. 27

37 5. Case Study... router OR platform Tor alpha-dev on Linux protocols Link 1 2 Circuit 1 published :04:42 fingerprint 7E79 E808 1AEF D859 E201 1A C990 3BEC Figure 5.11: Example of Router Descriptor modified by the Sniffer. 28 System statefulness: In Tor, different types of cells are exchanged among the nodes depending on their state. For example, after a circuit has been created, e.g., when the OP uses that circuit to send and receive data to a web server, the data are exchanged on the circuit using Relay cells. Furthermore, some specific cell types like Version [20] are exchanged only after the TLS handshake. The examples above suggest that the types of cells that the Sniffer observes depend on the state of the system. So, what the Sniffer observes, depends on which messages the nodes exchange during time. When the tester uses our framework, he has to ensure that the messages to fuzz are actually in the network. In practice, to allow the Sniffer to observe certain types of cells, we have to exercise the Tor network accordingly. For example if we want to sniff a Version cell in a live network, an OR has to perform the TLS handshake with another OR so that the Sniffer can observe that cell. 5.3 Tor Fuzz Operators Directory Authority Fuzz Operators The documents generated by the DAs (e.g., Router Descriptor, Network Status Consensus) obey to the following format [20]. A document consists of several items. Each item is a pair that consists of a keyword and a tuple of fields (see Figure 5.8). Keywords and fields are strings. To fuzz the DA messages, the Fuzzer considers every message it receives as an input for the SUT and randomly selects a FO to use. The Fuzzer randomly chooses either an item, a keyword, a tuple or a field and applies the selected FO. Some FOs that we have implemented manipulate that objects as generic ASCII strings. Others are more specific and target numeric fields (e.g., port numbers, dates) with a precise semantics. There are dependencies between fields in the messages and the fuzzing can break these dependencies. For example, in the Router Descriptor message, if we fuzz the extra-info section the field extra-info-digest, which contains the hash, must be updated accordingly. The Fuzzer takes care of these

38 5.3. Tor Fuzz Operators dependencies by updating the fields accordingly. provides the SUT with semi-valid inputs. In this way, the Fuzzer The Fuzzer signs 6, using the private Identity Key of the OR, the modified Router Descriptor message and updates the signature field. Since the DA messages are exchanged using HTTP, we have also fuzzed the HTTP headers of these messages. This is important since the HTTP headers are processed by the DAs and may reveal bugs. In the following we describe our FOs. Generic FOs for strings of ASCII characters (s 1,..., s n ). FO1: It repeats a character in a random position in a string n times, e.g., with n [1,..., ]. FO2: It selects a value v at random in 1,..., n; it generates at random a byte b; it replaces s 1,..., s n with s 1,..., s v 1, b, s v+1,..., s n. FO3: It selects a value v at random in 1,..., n; it replaces s 1,..., s n with s 1,..., s v 1, s v+1,..., s n. FO4: It selects a value v at random in 1,..., n; it replaces s 1,..., s n with s 1,..., s v 1, 0x00, s v+1,..., s n. FO5: It replaces a whitespace character (e.g. newline, tabulation character) with a random ASCII control character. FO6: It adds a newline character at the end of the string. FO7: It duplicates a string. FO8: It removes a string. FO9: It inserts a random string in a random position in a string. FO10: It replaces the entire string with a random string. Operators for specific fields. FO11, IP address: It replaces an IP address with either a reserved address (e.g., multicast), an invalid address (e.g., ) or an ill formatted address (e.g., ). 6 Using SHA1 hash, encrypted with PKCS#1 (RFC 2437). 29

39 5. Case Study FO12, Port number: It replaces a port number with either a non existing port (e.g., 70000), a registered port (e.g., 21) or an ill formatted port (e.g., ). FO13, Date: It replaces a date with either an old date, an invalid well formatted date (e.g. yyyy-dd-mm, ) or an ill formatted date (e.g ). The choice of random strings (in FO9 and FO10) and random numbers (depending on the field) is complemented using some preloaded fuzzing libraries that contains strings that have been used in discovering bugs in the past 7. We list them according to the problem they are likely to cause. Integer Overflow: These values try to produce an overflow in the variable where the value is stored. Examples are 0xffffffff and -1. Format String: These values are used to check if the SUT filters format strings that can lead to crashes. Examples are %%20n, %d%d%d, repetitions of whitespace characters (e.g. tab, space, newline) and binary strings. Buffer Overflow: These values try to overflow the memory area of the SUT that should store them. Examples are strings with different length (e.g. from 5 to bytes) and long strings containing a termination character in the middle of it. Directory Traversal: These values check if the SUT filters bad URLs in HTTP header. Examples are../../ and..%5c..%5c Cells Fuzz Operators The fuzzing strategy that we have chosen to use here is slightly different from the one in in Section Fuzzing every cells would actually prevent the fuzzer to see most of the cells in the network. For instance, if we want to test data transmission from an entry OR to an exit OR, we first need to set up the circuit between these two nodes. We cannot, in this case, fuzz the messages associated with the circuit creation because this would prevent the circuit creation. The fuzzing strategy is as follows. The Fuzzer selects at random an index v in 1,..., n, where n is the maximum number of cells chosen by the tester, that the fuzzer can forward back without fuzzing. 7 Some of them come from the OWASP Testing Guide [11] or from the Sulley framework [15]. 30

40 5.3. Tor Fuzz Operators c 1,..., c n is an incoming sequence of cells to the fuzzer. The Fuzzer does not fuzz the cells c 1, c 2,..., c v and fuzzes the cell c v+1. A new random index v is chosen and the procedure is repeated. Large values of n, allow more circuits to be created correctly and cells to be relayed along that circuits. The choice of a random index v allows also the fuzzer to observe different types of cells (e.g., Create, Relay), and to fuzz these cells at different points in time, i.e., with the SUT in different states. In this way we can fuzz the network more thoroughly. To allow the Fuzzer to inject cells in a live TLS connection, we disabled the TLS integrity mechanism (HMAC) used by Tor. In the following, we present the FOs that we have used. FO1: Depending on the cell type, it substitutes the content of a random cell s field with a) 0xff bytes, or b) 0x00 bytes, or c) random bytes. It can also removes a cell s field. FO2: It duplicates a cell. FO3: It removes a cell. FO4: It truncates a sequence of bytes of random length from the Data field of the current cell. FO5: It removes the Data field of the current cell. FO6: It replaces a byte in a random position in cell with a random byte. FO7: It appends or prepends to the current cell a sequence of random length composed by: a) 0xff bytes, or b) 0x00 bytes, or c) random bytes. FO8: It appends or prepends to the current cell a sequence of length equal to the size of the cell composed by: a) 0xff bytes, or b) 0x00 bytes, or c) random bytes. FO9: It appends or prepends to the current cell a Destroy cell with the same Circuit ID of the current cell. With this FO we aim to reveal race conditions that can appear when two subsequent cells with the same Circuit ID have different Command values. Race conditions are a major problem because operations that are executed in a wrong order can lead to unexpected software behaviours. FO10: It appends or prepends to the current cell a Relay cell with the same Circuit ID of the current cell and a random Data field (The purpose is the same as the previous one). 31

41 5. Case Study FO11: A cell from a library is appended or prepended to the current cell. The current cell can also be replaced with the preloaded cell. We have created a library that contains two sets of cells that have the purpose of leading the SUT in an error state. The first set contains cells that are well formatted and do not have conflicts in their dependencies (e.g. Create, Created, Create Fast, Version with random Data field as necessary). Their aim is to violate assumptions about the order of the cells the SUT expects. The second set targets specifically the problem of cell s fields dependencies violating assumptions about the format of a cell. For example, Figure 5.12 shows an example of a fuzzed Version cell. It is a variable length cell and FO11 modifies the value of the Length field to 3 while the content of the Data field has actually length 2 bytes. Figure 5.12: Example of a fuzzed Version cell. FO12: It swaps the Circuit ID of the current cell with one of the Circuit ID that the fuzzer has observed on the same connection. The fuzzer keeps track of the recently used Circuit IDs. As we have said in Chapter 5.1, Circuit IDs are connection-specific. When the fuzzer receives a cell, it adds the Circuit ID of that cell, if it is not already present, to the buffers BUFF src and BUFF dst where src and dst are the Tor nodes that send and receive the cell respectively. Given a cell c for the node node, FO12 randomly chooses a Circuit ID in BUFF node and replaces it in c. This FO aims to route a cell on another circuit. For example, in Figure 5.13 there is a cell c for OR1 that has a Circuit ID 12. The fuzzer applies FO12 that chooses at random a Circuit ID from BUFF OR1 = [2, 13, 17, 18]. Supposed that it chooses 17, the modified cell c has a new Circuit ID 17. Note that 17 is an ID for a circuit that has been created previously. The swap causes the cell to be routed by OR1 to OR4 instead of OR2. 32

42 5.4. Tor Oracles Figure 5.13: Example of usage of FO12: Circuit ID swap. The path in red is the original path, while the path in black is the modified path. 5.4 Tor Oracles When testing the Directory Authority protocol we used Valgrind s Memcheck as local oracle on the Tor instance running on the DA node. In this way the DA node is monitored for memory errors as we described in Chapter 2.1. When testing the Cells protocol we used both a local and a functional oracle. As a local oracle we used again Valgrind s Memcheck. In this case the SUT is composed by several nodes as shown in Figure So we deployed the local oracle on all the nodes of our Tor network. For detecting functional failures, we considered the circuit creation procedure that is a key element in Tor protocols. It is important that the ORs can provide this functionality because only after a circuit is created, an OP can start sending data through it. Our functional oracle tests if the ORs in the Tor network can provide this service and monitors when the service becomes unavailable. Our functional oracle complement the monitoring of local oracles. The functional oracle that we have implemented uses the Tor Control Protocol [20]. The Tor Control Protocol is a message-based protocol that allows software different from Tor to communicate with a locally running Tor instance. Several commands can be sent to a Tor instance, for example to get information about its status and the status of the Tor network. Among the 33