Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Sec18-Chen 0

Download as pdf or txt
Download as pdf or txt
You are on page 1of 19

Off-Path TCP Exploit: How Wireless Routers

Can Jeopardize Your Secrets


Weiteng Chen and Zhiyun Qian, University of California, Riverside
https://www.usenix.org/conference/usenixsecurity18/presentation/chen-weiteng

This paper is included in the Proceedings of the


27th USENIX Security Symposium.
August 15–17, 2018 • Baltimore, MD, USA
978-1-939133-04-5

Open access to the Proceedings of the


27th USENIX Security Symposium
is sponsored by USENIX.
Off-Path TCP Exploit: How Wireless Routers Can Jeopardize Your Secrets

Weiteng Chen Zhiyun Qian


University of California, Riverside University of California, Riverside
wchen130@ucr.edu zhiyunq@cs.ucr.edu

Abstract attacker and victim.


In the case of TCP, for example, a server has many
In this study, we discover a subtle yet serious timing side
kinds of shared resources implemented by operating sys-
channel that exists in all generations of half-duplex IEEE
tems such as a global IP ID counter [1, 25, 23], SYN
802.11 or Wi-Fi technology. Previous TCP injection at-
cache and RST limit [24], SYN-backlog [33], and chal-
tacks stem from software vulnerabilities which can be
lenge ACK rate limit [18]. These resources are shared on
easily eliminated via software update, but the side chan-
a host between a connection established with the attacker
nel we report is rooted in the fundamental design of IEEE
and a connection with the victim.
802.11 protocols. This design flaw means it is impos-
When the attacker sends spoofed packets to the server
sible to eliminate the side channel without substantial
that appear to come from the victim, these shared re-
changes to the specification. By studying the TCP stacks
sources are used differently, depending on the validity of
of modern operating systems and their potential interac-
the spoofed packets (e.g., in-window vs out-of-window
tions with the side channel, we can construct reliable and
sequence number). By observing the shared resources,
practical off-path TCP injection attacks against the latest
how these spoofed packets are processed are visible to
versions of all three major operating systems (macOS,
the attacker.
Windows, and Linux). Our attack only requires a device
All existing vulnerabilities related to off-path TCP ex-
connected to the Internet via a wireless router, and be
ploit essentially stem from software artifacts. The ones
reachable from an attack server (e.g., indirectly so by ac-
that can lead to serious attacks are already patched pri-
cessing to a malicious website). Among possible attacks
marily by (1) eliminating the shared resources in protocol
scenarios, such as inferring the presence of connections
implementations (or adding randomness to them) [7, 8]
and counting exchanged bytes, we demonstrate a partic-
and (2) reducing the opportunities that the shared re-
ular threat where an off-path attacker can poison the web
sources leak information, e.g., employing a more strin-
cache of an unsuspecting user within minutes (as fast as
gent acknowledge(ACK) number check [44]). As we
30 seconds) under realistic network conditions.
will discuss later in §2.3, almost all previously reported
off-path TCP attacks no longer work.
1 Introduction
Unlike yet another software side channel, we report a
Side channels in networking stacks have recently been fundamental side channel inherent in all generations of
demonstrated to precipitate serious attacks. One of the IEEE 802.11 or Wi-Fi technology, because they are half-
most noteworthy cases is CVE-2016-5696 [18] where duplex. From its definition: when there are uplink wire-
a completely blind off-path attacker can infer whether less frames being transmitted, downlink frames have to
two arbitrary hosts on the Internet are communicating wait, and vice versa. This basic and fundamental design
using a TCP connection. The attacker can even infer seems benign but it creates a timing channel sensitive to
the TCP sequence numbers in use from both sides of the contention between uplink and downlink traffic. For
the connection. In addition to this serious vulnerabil- example, a downlink packet measuring the RTT will in-
ity, other types of side channel vulnerabilities have also cur a higher latency if uplink traffic is going on. As we
been discovered in various scenarios and protocol com- will show in the paper, an attacker can leverage the tim-
ponents [39, 40, 25, 24, 27, 33, 23, 48, 13]. Fundamen- ing channel to craft clever sequences of packets, creat-
tally, like any side channel vulnerabilities, these vulner- ing primitives to infer TCP sequence number and ACK
abilities are introduced by shared resources between the number, ultimately completing a working off-path TCP

USENIX Association 27th USENIX Security Symposium 1581


C S
2 Off-Path TCP Exploits
Internet
2.1 Generic Threat Model
OR
Fig. 1 illustrates a typical off-path TCP hijacking threat
Sandboxed Un-privileged Mallory model consisting of three hosts: a victim client, a victim
script App
server and an off-path attacker. The off-path attacker,
Figure 1: Threat model Mallory, is capable of sending spoofed packets with the
IP address of the legitimate server. In contrast to Man-in-
the-middle attack, Mallory cannot eavesdrop the traffic
exploit. transferred between a client C and a server S. Depending
Through extensive experimentation, we demonstrate on the nature of the side channel, an unprivileged appli-
that the timing channel is reliable (through amplification) cation or a sandboxed script may be required to run on
and can be used even when the attacker and victim are far the client side [40, 27] to observe the results of the shared
away (with RTTs over 20ms). We implement a realistic state change and determine the outcome of the spoofed
blind off-path attack that can achieve web cache poison- packets (e.g., whether guessed sequence numbers are in-
ing within minutes. The video demo can be found on our window). In rare cases, if the state change is remotely
project website [3]. We also open sourced the attack im- observable, an off-path attacker can complete the attack
plementation at [5] to assist the reproduction and further alone without the assistance from the unprivileged ap-
research of the work. plication or script [18]. After multiple rounds of infer-
The contributions of the paper are the following: ences, starting from whether a connection is established
• We report the timing side channel inherent in all gen- (four tuple inference) to the expected sequence number
erations of IEEE 802.11 or Wi-Fi technology. We and ACK number inference, the attacker can then inject a
show the timing channel is reliable and amplifiable malicious payload that becomes acceptable to the client
and unfortunately almost impossible to eliminate with- at the TCP layer.
out substantial changes to the 802.11 specification. The side channels typically manifest themselves
• We show that the side channel affects macOS, Win- through the following control flow block:
dows, and Linux by studying the overlaps and differ- if ( in_packet . seq is in rcv_window )
ences in their TCP stack implementations. We con- // shared state change 1
else
struct the only off-path TCP exploit working at the // shared state change 2
moment based on this new side channel. The example illustrates two variables: (1) the attacker-
• We provide a thorough analysis and evaluation controlled variable in packet.seq — guessed sequence
of the proposed attack under different router/net- number in a spoofed packet and (2) the receive window
work/OS/browser combinations. We also suggest pos- deciding what in packet.seq are valid. Depending on the
sible defenses to alleviate this attack. outcome of the comparison, the shared state may change
Roadmap. The rest of the paper is organized as follows: to different values. The change also has to be observable
we begin with background introduction and the most rel- by the attacker through some side channel. Two neces-
evant work in § 2, and then present the timing side chan- sary building blocks are needed in a TCP off-path side
nel in Wi-Fi technology in § 3. § 4 describes an overview channel attack: (1) existence of vulnerable packet valida-
of the off-path TCP exploit and its goal. In § 5, we elab- tion logic; (2) the shared state has to be observable by an
orate the implementation of the attack against different attacker (i.e., the sandboxed script, unprivileged app, or
OSes. In § 6, we evaluate our attack under different con- the off-path attacker). Note that together these two build-
ditions. § 7 discusses some potential attacks that exploit ing blocks result in a violation of the non-interference
the vulnerability. We propose some mitigation schemes property [29, 50].
at different layers in § 8. We also introduce previous re- Next we give an overview of these two building blocks
search related to side channels in § 9. Finally, § 10 con- used by previous attacks and explain why those attacks
cludes the paper. no longer work. Simply put, they either rely on outdated
TCP packet validation logic or shared state that can be
easily eliminated.

1582 27th USENIX Security Symposium USENIX Association


Connection Send • Sequence number check: This check makes sure that
identification Not exist RST
Exist No the sequence number falls in the receive window. Oth-
Set Send
erwise, according to the TCP specification RFC 793, an
Rate-
SYN?
limited? Challenge immediate duplicate ACK packet should be sent in re-
ACK
Not Set Yes ply (unless the RST bit is set, in which case the packet
Sequence Out-of-
is dropped without reply). If the sequence number is
number check window
RST?
Set
in window and RST bit is on, similar to handling SYN,
No
In-window RFC 5961 suggests the use of challenge ACKs to defend
SEQ Discard against off-path RST attacks: only if the sequence num-
RST?
Set match? ber matches the next expected sequence number, a re-
Not Set
Not Set
Yes
ceiver terminates the connection; otherwise, the receiver
Reset the must send a challenge ACK.
Ack number connection
check
Out-of-window • ACK number check: Pre-RFC 5961, the ACK num-
In-window
ber is considered valid as long as it falls in the wide range
Accept
Send Duplicate of [SND.UNA (231 1), SND.NXT]1 , which is effectively
ACK
half of the ACK number space. Thus, an attacker only
Figure 2: Incoming packet validation logic in RFC needs to guess two ACK numbers for every guessed se-
quence number to successfully inject data into a connec-
2.2 Latest TCP Incoming Packet Valida- tion, resulting in a guaranteed successful data injection
tion Logic with up to 2 ⇤ 232 /RCV.WND2 spoofed data packets. RFC
5961 proposes a much more stringent check suggest-
To understand how incoming packets are validated, we ing a valid ACK number should be within [SND.UNA -
refer to the standards of RFC 793 [4] and RFC 5961 [44]. MAX.SND.WND, SND.NXT]3 , where MAX.SND.WND is the
We focus on the latest standard only as it is helpful in maximum receive window size the receiver has ever seen
understanding why attacks against old versions now fail. from its peer. If the ACK number is out of this win-
Note that even though different operating system imple- dow, the packet is dropped and an ACK should be sent
mentations may differ in reality, they still try to keep up back [44]. If the ACK number is in window yet there is
with the standards (albeit with their own tunings) and no payload, then the packet should be silently dropped.
overall it provides a foundation for discussion. We dis- Besides, to alleviate the waste of CPU and bandwidth
cuss the specific operating system implementations in §4. resources caused by challenge ACKs, an ACK throttling
We distill the latest standard and summarize it in Fig. mechanism is also proposed. Specifically, the system ad-
2. It involves primarily three types of checks, and each ministrator can configure the maximum number of chal-
of them has some form of vulnerable logic — different lenge ACKs that can be sent out in a given interval.
actions are taken depending on the outcome of the check
(e.g., a response packet is sent vs. not). 2.3 Prior Attacks and Side Channels
• Connection (four-tuple) Identification: The first Now that we understand how the generic TCP packet val-
check tries to identify if an incoming packet belongs to idation logic is envisioned by the standard, we describe
any established connection based on the four tuples – the known shared states that lead to side channels, com-
source and destination port numbers as well as IP ad- bined with the variants in TCP packet validation logic in
dresses. If no ongoing connection matches the four tu- different operating systems (sometimes out-of-date), that
ples, an incoming packet not containing a RST causes a were leveraged by existing attacks.
RST to be sent in response. Otherwise, if the SYN bit • Global IPID counter. Until recent years, Windows
is set, irrespective of the sequence number, TCP must is the only operating system that chooses to maintain
send an ACK referred to as challenge ACK to the remote a globally incrementing IPID counter shared across all
peer to confirm the loss the previous connection. Upon connections and stamped onto the IPID field in IP header
receipt of this challenge ACK, a legitimate remote peer for every outgoing packet [23]. This creates a side chan-
who truly lost its connection, after a restart, sends a RST nel that allows an attacker to count how many outgoing
packet back with the sequence number derived from the
1 SND.UNA: the sequence number of the first byte of data that has
ACK field of the challenge ACK, which can terminate
the connection at that point. The challenge ACK is hence been sent but not yet acknowledged; SND.NXT: the sequence number
of the next byte of data to be sent
a defense against blind off-path attacks that attempt to 2 RCV.WND: size of receive window
terminate a connection forcefully through spoofed SYN 3 The window can be as small as a few thousand bytes, which makes

packets. the guess much more difficult

USENIX Association 27th USENIX Security Symposium 1583


Side channel Requirement Affected OS Patch/Mitigation
Global IPID count [1, 25] Pure off-path or Javascript Windows Global IPID counter eliminated
Direct browser page read [27] Javascript Any old OS RFC 5961
Global challenge ACK rate limit [18] Pure off-path Linux Global rate limit eliminated
Packet counter [40, 39] Malware Linux,macOS Namespace / macOS* patch [9, 10]
Wireless contention (this work) Javascript Any N/A

Table 1: Summary of Different Off-Path TCP Side Channel Attacks including the one we propose in this paper

packets have been sent during a time interval, through matches the one shown in Fig. 2. Notably, it implements
diffing the queried IPIDs of a Windows machine. This the recommended ACK throttling feature by introducing
is leveraged in several off-path TCP attacks [1, 25]. Us- a global system variable to control the maximum num-
ing IP spoofing, an off-path attacker can tell whether the ber of challenge ACKs generated per second. As this
guess is correct based on whether a response is triggered. limit is shared across all connections, the shared state
However, at the time of writing, we experimentally can be exploited as a side channel. For instance, to in-
verify that Windows 10 has finally eliminated this side fer if an ongoing connection exists, an off-path attacker
channel by adopting a safer IPID generation algorithm can initially send a spoofed packet with one guessed port
similar to that used in Linux [33], where connections number and SYN bit set; after the attacker sends another
destined for different IP addresses will no longer share 100 4 non-spoofed in-window RST packets to exhaust
the same IPID counter. the challenge ACK count, it can then observe the num-
ber of responses to tell whether its initial spoofed packet
• Browser page read. In this attack [27], the shared matches the four tuples of an ongoing connection and
state is a browser page where an attacker runs malicious hence triggers a challenge ACK.
Javascript and attempts to inject data into connections to Since the shared rate limit is a simple software artifact,
a benign website (both the benign connection and ma- shortly after the vulnerability was reported, it was elimi-
licious script run under the same page). The success- nated in a patch introduced in Linux 4.6 [8, 42] where a
ful guess of the TCP sequence number results in a di- per-socket rate limit is used instead.
rect feedback from the browser page load. There are
three main culprits of the attack: (1) older operating sys- • System-wide packet counter. Packet counters report
tems follow an earlier standard RFC 793 that consid- aggregated statistics across all connections and are re-
ers half of the ACK number space valid. An off-path liable side channels demonstrated in recent off-path at-
attacker only needs to guess two ACK values with ev- tacks [40, 39]. These attacks require a piece of unprivi-
ery guessed sequence number to inject data successfully. leged malware to run on the client machine that can ac-
Therefore, the feedback about when the injection suc- cess these packet counters and use them as feedback for
ceeds is when the malicious payload gets loaded and ren- spoofed packets sent by the off-path attacker. Due to the
dered by the browser. (2) modern browsers are tolerant fact that these counters are internal to TCP implementa-
of response data: if the HTTP response header is miss- tions, they may leak more diverse and fine-grained infor-
ing, the browser simply attaches one automatically. This mation (more than what the standard packet validation
frees the attacker from having to prepare the header at logic can leak). In the extreme case, for example, a Lin-
an exact sequence number (otherwise the browser con- ux/Android TCP packet named DelayedACKLost is in-
siders the response invalid and closes the connection). cremented only when it receives a packet with a sequence
(3) HTTP pipeline is required so that a response arrives number smaller than the expected one. This allows an
ahead of time will be deemed valid. attacker to conduct a binary search on the expected se-
This attack no longer works because the first culprit is quence number. Similar dangerous packet counters exist
eliminated by most modern operating systems (including on macOS as well [40].
Windows, Linux, Android), which adopted a more strin- These packet counters are being mitigated in a num-
gent check on ACK numbers as defined in RFC 5961 ber of ways. For Linux, it introduced the mechanism
where only a much smaller window is considered valid. of namespace so that sensitive apps and untrusted apps
In addition, from our testing, HTTP pipeline is disabled can run in separate namespaces with isolated counters.
or not implemented in all modern browsers, eliminating For macOS, the side channel vulnerability has recently
the third culprit as well. been assigned CVE-2017-13810 and patches have been
pushed out to zero the sensitive counters [9, 10].
• Global challenge ACK rate limit. The Linux kernel
4 It’s
first implemented all the features suggested in RFC 5961 the default threshold in Linux version 3.6
in version 3.6 and its TCP packet validation logic closely

1584 27th USENIX Security Symposium USENIX Association


No ACKs Triggering ACKs
Client Corresponding
Half Response
Duplex Delayed
X X
X Failed
Router Transmission

ry

ry
ry

ry
ue

ue
ue

ue
Full Gap_2

Q
Gap_1 Probe

Q
e

e
Duplex

e
ob

ob
b

b
ro

ro
Pr

Pr
-P

-P
e-

e-
st

st
Pr

Pr
Attacker
Po

Po
Not Trigger ACK Trigger ACK
RTT_1 RTT_2
Server

(a) Timing difference between two cases


Client No ACK Multiple ACKs
Corresponding
X Response
X
Half Delayed
Duplex
X X Failed
X
Router Transmission

ry
ry
ry

ry

ue
Probe
ue
ue

ue
Full Gap_2

Q
Q
Q

Q
Gap_1

be
be
e

e
Duplex
ob

ob

ro
ro
Pr

Pr

-P
-P
e-

e-

st
st
Pr

Pr
Po

Po
Attacker

Not Trigger ACK Trigger ACK


Server RTT_1 RTT_2

(b) Triggering multiple ACKs

Figure 3: Vulnerability caused by wireless contention

Summary. Overall we listed four different types of it waits for a period of time (e.g., usually random or
software-based side channels that have been exploited exponential backoff [17]) attempting to avoid collision.
to launch off-path TCP attacks. We summarize them in Although it might benefit the performance when many
Table 1 for reference. In short, only the packet counter nodes are active, it creates a significant overhead when
side channels still exist (validated on Linux and Android only one is present (plus the AP). In addition to backoffs,
8.0). In any event, this side channel requires a high bar to Request to Send/Clear to Send (RTS/CTS) [16] may op-
launch because of the malware requirement. In the next tionally be used to mediate access to the shared medium
section, we describe our newly discovered side channel to solve the hidden-terminal problem [46] where multi-
in detail. ple stations can see the Access Point but not each other.
Unfortunately, in the same scenario where there is only
3 Wi-Fi Timing Channel one node, it introduces unnecessary traffic to the net-
work, slowing everything down. Finally, it is important
Fundamentally, the half-duplex nature of Wi-Fi creates to note the latency is amplified further when more con-
a “shared resource” among uplink and downlink traffic, tention is present (e.g., more frames to be transmitted in
a prerequisite of any side channel. By sharing the same either direction).
set of frequency bands with both directions, Wi-Fi relies Exploiting the timing channel. To demonstrate the tim-
on carrier-sense multiple access (i.e., CSMA) to share/- ing channel, we create a probing strategy to measure the
divide the channel over time. This means that a node delay effects. As we can see in Fig. 3a, we simulate an
transmits only when the channel is sensed to be idle and off-path TCP attack where the attacker sends a spoofed
thus it has the exclusive right to transmit. This effectively probing packet, along with a pre-probe query and post-
creates a timing channel that delays the local transmis- probe query to measure the RTT before and after. If the
sion if the opposite direction is transmitting at the same spoofed packet does not trigger an ACK on the client,
time. e.g., because the guessed sequence number is in-window
Even worse, this timing difference becomes more vis- (left half of the figure), then the post-probe query arrives
ible due to retransmissions caused by contention (col- at the client faster and gets back sooner (smaller RTT).
lision). Specifically, the protocol starts by listening on On the other hand, if the spoofed packet triggers an ACK
the channel and immediately sends the first frame to the on the client, e.g., because the guessed sequence number
transmit queue if the channel is found to be idle; how- is out-of-window (right half of the figure), then the post-
ever, this leads to waste of transmissions if collision oc- probe query experiences contention with the ACK from
curs. If the channel is subsequently sensed to be busy,

USENIX Association 27th USENIX Security Symposium 1585


the client, and therefore prolongs the measured RTT. In
addition to the RTT difference (RT T 2 > RT T 1), we
can also measure the gap between the replies of the first
query and the second, which should capture the delay ef-
fects similarly.
In Fig. 3b, we also illustrate the amplifiable nature of
the timing channel where the attacker sends two spoofed
probing packets, causing more contention which delays
(a) RTT measurement of ma- (b) RTT measurement of Linux
post-probe query even further.
cOS using 5GHz network of a using 5GHz network of a
In summary, this side channel allows an attacker to Huawei router Linksys router
determine if the spoofed probing packets have triggered
any response or not, coincidentally achieving the same
purpose as the global IPID counter on Windows (which
is no longer available). In contrast, Wi-Fi contention is
here to stay.
Empirical testing. So far we only conceptually analyzed
the side channel and its effects. We now conduct a con-
trolled local experiment to understand its real-world im-
(c) RTT measurement of ma- (d) Gap measurement of ma-
plications. Following the same topology in Fig. 7, we cOS using 2.4GHz network of a cOS using 5GHz network of a
created a total of 16 different setups to make sure that the Xiaomi router Huawei router
side channel exists in various generations of technologies
and products. We used 4 different wireless routers (from
Linksys, Huawei, Xiaomi, and Gee): all latest genera-
tions that support 802.11ac and 802.11b/g/n. We used
two different machines as clients: an early-2017 Mac-
book and a mid-2017 Dell Desktop. Finally, we varied
the frequency of the router between 2.4GHz and 5GHz
so that both 802.11n and 802.11ac were tested (802.11ac
is used for 5GHz only). (e) Gap measurement of Linux (f) Gap measurement of macOS
The measurements are conducted in a single-family using 5GHz network of a using 2.4GHz network of a Xi-
house where we have relatively little wireless interfer- Linksys router aomi router
ence (with at most 4 potential users at home). Due to
space constraint, we present 6 representative results of Figure 4: Selective measurement of wireless connections
the measurement in Fig. 4. Each plot with a box and in a local setup. X axis is the number of probing pack-
whiskers presents the data measured with 100 runs. On ets that attackers send per test. The box extends from
average, we can see that the timing difference for RTT is the lower to upper quartile values of the data. And the
about 1 to 3ms when the number of probing packets is 30 whiskers extend from the box to show the range of the
or more. Although differences exist among those setups, data at specific percentiles (i.e. [0, 90]). Beyond the
the timing side channel is clear and measurable(see §5.4). whiskers, data are considered outliers, plotted as individ-
Later in §6, we also evaluate its robustness to noise. ual points.
Half-duplex vs. Full-duplex To better understand that
the significant part of the RTT difference is due to the cores (by OS design), allowing the post-probe query to
half-duplex nature of wireless rather than the processing be processed in parallel to probes. Even if the probes
time to generate an ACK response on the client, we also trigger ACKs, they still consume resources (CPU, mem-
conducted an experiment with the setup where both the ory) that are mostly isolated from the post-probe query.
victim and attacker machine connect to a Huawei router The experiment demonstrates that contention caused by
via ethernet. As depicted in Fig. 5, the timing side chan- half-duplex is the root cause of the timing channel.
nel is no longer visible and amplifiable (note the heavily
overlapped boxes), because of two reasons: (1) Now that
downlink and uplink can transmit at the same time, there 4 Attack Overview
is simply no contention regardless of how many packets
are transmitted. (2) Packets belonging to different sock- In this section, we show how such an inherent side chan-
ets can be processed simultaneously on different CPU nel can be leveraged in our off-path TCP attack.

1586 27th USENIX Security Symposium USENIX Association


of generality, we focus on the “web cache poisoning”
attack (which is the most powerful among a few other
web attacks described in [25, 27]). Assuming a puppet-
initiated connection is targeted, the attack can choose to
poison any unencrypted target website at any time. It
relies on the basic design principle that browsers reuse
TCP connections for requests sent to the same server IP
address. This means that the puppet in the malicious
(a) RTT measurement of macOS (b) Gap measurement of macOS
website can create a single persistent connection to a
Figure 5: Measurement of wired connections in a local target domain by repeatedly including HTML elements
setup (e.g., images). The off-path attacker can then conduct the
side channel attack to infer the port number and sequence
S
numbers used in the target connection. Afterwards, the
C
puppet can embed a target web object in the page, e.g.,
Internet
<iframe src = "www.bank.com/index.html" />
Sandboxed Mallory This triggers an HTTP request over the same old TCP
script
connection; the off-path attacker can now simply inject
a fake HTTP response that will be cached for arbitrar-
Figure 6: Specific threat model targeting a wireless client
ily long, because the HTTP response header can ask the
browser not to re-check the freshness of the object, lead-
• Threat model. Obviously, since the side channel is ing to a persistent cache poisoning5 . If an attacker caches
inherent in Wi-Fi, the threat model requires either the a commonly used malicious third-party javascript (e.g.,
client or server connected through Wi-Fi. As it stands, jQuery), it can impact a large number of websites.
we do not consider servers here as most of them do not In the remainder of this section we describe the three
use Wi-Fi (see §7 for a special case of IoT devices). different attacks that progressively build on top of each
This paper therefore focuses on the threat model as de- other, and detail strategies for all three major operating
picted in Fig. 6 where a user is lured into visiting a mali- systems.
cious website first. Subsequently, a sandboxed malicious • Leveraging the TCP packet validation logic. As
script (by convention [25, 27], we call them puppets) mentioned in §2.2, the latest RFC standards specify the
initiates a connection to the attacker (who is not neces- packet validation behavior, which consists of connec-
sarily close to the victim) to circumvent the reachability tion (four-tuple) identification, sequence number check
problem caused by NAT or firewall commonly found on and ACK number check. In each check, depending on
wirelessly-connected clients. The off-path attacker can the validity of the incoming packet, a response will be
then take measurements of RTTs from outside and con- generated, or not. This is exactly what the Wi-Fi tim-
duct the side channel attack. Based on this threat model, ing channel allows an off-path attacker to observe —
we consider a number of related attack goals: whether spoofed packets have triggered responses or
(1) inferring the presence of a connection from the not. Similar to the Windows global IPID side channel
client to a server (connection inference); that provides the same feedback (but is now eliminated),
(2) counting the number of bytes exchanged on the prior attacks also take advantage of the TCP packet val-
connection, or forcefully terminating the connection (se- idation logic [1, 25]. However, there are two issues to
quence/ACK number inference); consider. First, clients connected through Wi-Fi are al-
(3) injecting malicious payload into a connection most always behind NAT and/or firewall (the wireless
(ACK number inference). router itself often acts as NAT). Therefore, the packet
For attack goal (1) and (2), the attack can be targeted at validation logic may change slightly. Second, it is un-
any connection from the client, not necessarily just those clear whether the operating systems will follow the stan-
that are puppet-initiated. For (3), although not strictly dard faithfully.
required, it is generally assumed that a puppet-initiated For the first problem, NAT and firewall primarily
connection is targeted (as shown in prior side channel change the behavior of connection identification. If an
attacks [25, 27]) because the attacker controls the timing incoming packet does not match any ongoing connec-
of the connection/request, greatly simplifying the attack.
5 HTTP response header can specify a “max-age”, indicating that
Overall procedure. Attack goal (1) and (2) are gener-
ally straightforward. For (3), in this paper, without loss the response is to be considered stale after X seconds where X can be
as large as 231 or 68 years (see RFC7234)

USENIX Association 27th USENIX Security Symposium 1587


No Active
tion, NAT and firewall will simply drop the packet, pre- connection connection
venting the client from even observing it; if an incom- Mallory Router Client Router Mallory Server

ing packet matches an ongoing connection, the packet is Query &


N Corresponding
let through and handled as usual. This actually simpli-


probes Response
fies the connection inference, as the attacker can simply Probe

choose to send spoofed packets that always trigger re- RTT


Dup ACK

sponses (e.g., incoming SYN packets); if there is no re- RTT


sponse, it must be the case that no connection exists and
packet is dropped by a NAT.
For the second problem of real operating system im-
plementations, we survey the latest Linux, macOS, and (a) Connection (four-tuple) test
In-window Out-of-
Windows in terms of their packet validation logic. Our seq window seq
methodology is to inspect the kernel source code of Mallory Router Client Router Mallory Server

Linux and macOS [11] as they are readily available. We


N
then experimentally verify our understanding of them.


probes
Finally, we apply the same test program to measure the
behavior of Windows. We summarize our findings in Ta- RTT
ble 2. RTT


The result is, for the most part, consistent with the
standard (except Windows which we talk about later).
Linux is the one that most closely follows the standard
(also observed previously in [18]). It has implemented (b) Sequence number test
the challenge ACKs and the rate limit as suggested by
Figure 7: Infer port and sequence number by exploit-
RFC 5961. MacOS is similar to Linux except that it does
ing the timing side channel. Note that these diagrams
not implement rate limit and is in general weaker in its
are simplified for clearness. In reality, packets belong-
validation logic. For instance, even if an incoming packet
ing to different sockets can be processed simultaneously,
has no flag bit set, it still checks the sequence number of
and uplink and downlink should have equal access to the
the packet instead of dropping it without any processing.
wireless channel rather than uplink waiting for downlink.
Based on the concrete testing results, we conclude that
all three operating systems have packet validation logic
that can be exploited via the Wi-Fi timing channel. We path attacker now needs to guess a valid sequence num-
describe how to leverage their specifics to conduct the ber. By continuously tracking how the sequence number
attack: progresses, the attacker can effectively count the num-
Connection (Port Number) Inference. This attack ber of bytes received by the client (and the reverse di-
breaches the user privacy because knowing the websites rection can be monitored similarly through ACK number
a user visits often reveals a user’s medical condition and inference). We label the sequence number inference op-
sexual orientation [36]. As with previous off-path TCP portunities in Table 2 by combining two rows with dif-
exploits [25, 18], the first step is to infer whether an on- ferent outcomes (w/ or w/o responses) when the same se-
going connection with a particular target (server IP and quence of packets are processed. For Linux, if 10 incom-
server port are given) exists. We know that NAT drops ing ACK packets with just one-byte payload are received,
incoming packets that do not match any ongoing con- depending on their sequence numbers, 10 responses are
nections. All we need to make sure is that all operating triggered (out-of-window), or at most 1 (in-window) due
systems do generate outgoing ACKs otherwise. Indeed, to rate limiting (row no. 1, 2, and 3). For macOS, if an
from the table, an incoming ACK matching an ongoing incoming packet with no flags is received, a response is
connection with an out-of-window sequence number is triggered for the out-of-window case; otherwise no re-
guaranteed to trigger an ACK on all operating systems sponse is triggered (row no. 10 and 11). Interestingly,
(row no. 1, 10, and 17)). Fig. 7a depicts the sequence of if the ACK flag is on, macOS only generates ACKs half
packets that an off-path attacker can send to differentiate of the time (row no. 12 and 13). Windows is similar
between the cases of (i) the presence or (ii) the absence and requires only the regular ACK packets (row no. 17
of an ongoing connection. In both cases, the attacker and 18); SYN packets can do the trick as well (row no.
sends the same sequence of packets, leveraging the prob- 17 and 19). Fig. 7b demonstrates the sequence of packets
ing strategy described in §3 to measure the delay effects. that an attacker can send to distinguish between the cases
Sequence Number Inference Assuming the attacker of in-window and out-of-window sequence number.
has already identified the four-tuple connection, the off- ACK Number Inference Finally, knowing the four

1588 27th USENIX Security Symposium USENIX Association


No. OS FLAG SEQ ACK PAYLOAD #Responses Operation
1 Linux ACK|SY N|RST Out-of-window Any 1 10
< SND.UNA -
2 Linux ACK|SY N|RST + In-window Any 1⇤ SEQ inference
MAX.SND.WND
3 Linux ACK|SY N|RST + In-window > SND.MAX a Any 0
4 Linux ACK|SY N|RST Out-of-window Any 0 1⇤
5 Linux ACK In-window In-window 1 10
6 Linux ACK In-window In-window 0 0
a < SND.UNA -
7 Linux ACK RCV.NXT 1 1 1⇤
MAX.SND.WND
8 Linux ACK RCV.NXT-1 > SND.MAX 1 0 ACK inference
9 Linux ACK RCV.NXT-1 In-window 1 10
10 MacOS None|ACK Out-of-window Any Any 10
11 MacOS None In-window Out-of-window Any 0 SEQ inference
12 MacOS ACK In-window < SND.UNA 0 0
ACK inference
13 MacOS ACK In-window > SND.MAX Any 10
14 MacOS RST != RCV.NXT Any Any 0
15 MacOS SY N|FIN Any Any Any 10
16 MacOS ACK In-window < SND.UNA 1 10
17 Windows ACK|FIN|SY N Out-of-window Any Any 10
18 Windows ACK|FIN In-window Out-of-window Any 0 SEQ inference
19 Windows SY N|RST In-window Out-of-window Any 1
20 Windows RST Out-of-window Out-of-window Any 0
21 Windows ACK RCV.NXT-1 Any 1 10
22 Windows ACK In-window SND.NXT† 1 10
Idle connection
23 Windows ACK In-window != SND.NXT† Any 0
24 Windows ACK In-window In-window 1 10
Busy connection
25 Windows ACK In-window In-window 0 0
⇤ : Due to rate limit in Linux, we can get at most 1 response per half a second.
+ : The sequence number should be in window but not equal to the next expected number, otherwise the connection is reset.

: Although the client replies to such packets, it would also cause de-synchronization leading to the victim connection
to be closed during the keep-alive procedure, if the SACK option enables.
† : Typically, ACK number window refers to the range [SND.UNA-MAX.SND.WND, SND.NXT], but Windows deploys

a more stringent check if the connection is idle, requiring a valid ACK to equal SND.NXT.
a : RCV.NXT = next sequence number expected on an incoming segments, and is the left or lower edge of the receive

window; SND.MAX = latest unacknowledged sequence number

Table 2: Behaviors on different OSes when processing 10 identical packets

tuples and the expected sequence number, the attacker versus zero cannot create significant enough of a timing
now needs to learn the correct ACK number to success- channel. In addition, if a packet with in-window ACK
fully inject malicious payload. According to the standard number has no payload, Linux also ignores the packet
behavior earlier in §2.2, an attacker can infer whether a with no response (row no. 6), which leaves no oppor-
guessed ACK number is in-window or not by sending a tunity to differentiate the in-window and out-of-window
pure ACK (no payload) assuming its sequence number is cases (result similar to row no. 2 and 3). However, it
already in-window. If its ACK number is out-of-window, does correctly handle packets with payload; a response
a response is triggered and otherwise no response. Sur- is triggered only when the ACK number is in window
prisingly, from our analysis and experiments, we con- (row no. 5). The issue is that when an ACK number is
clude that no operating system is fully compliant with inferred, the client buffers the payload in its receive win-
the standard. Their own variants have often allowed sim- dow, which is undesirable for two reasons: (1) it may
pler strategies to conduct the ACK number inference. cause future server’s responses to be corrupted; (2) if
Linux. As shown in Table 2, instead of always trigger- selective ACK (SACK) is enabled, the client selectively
ing an ACK packet for out-of-window ACK numbers, acknowledges the data which has not actually been sent
when the ACK number is too old (smaller than SND.UNA by the server, causing the server to ignore future packets
- MAX.SND.WND), Linux responds with an ACK (with from the client, effectively de-synchronizing the client
rate limit); when the ACK number is too new (larger and server. Interestingly, Linux has a special edge case
than SND.NXT), Linux incorrectly drops the packet with- that allows us to infer ACK number without the hassle.
out any reply (row no. 2 and 3). Had there been no rate According to the specification, if the sequence number of
limit, an attacker can infer the correct ACK number via an incoming packet is equal to RCV.NXT-1 (indicating a
binary search. With rate limit, however, one response keep-alive message), it should trigger an ACK. Interest-

USENIX Association 27th USENIX Security Symposium 1589


ingly, the specification has an ambiguity. RFC 1122 [43] behavior of Windows still allows ACK number inference
specifies only the valid sequence number of a keep-alive when it has outstanding data during the inference. This
packet, but not the ACK number. Based on the source makes our attack in §5.3 more complicated but still pos-
code, Linux does not actually handle keep-alive explic- sible by taking advantage of the behaviors in row no. 18
itly. Instead, it simply treats such a packet (with one-byte and 24.
payload and end seq = RCV.NXT) as in-window, and
decides how to respond based on its standard ACK num-
5 Implementation
ber check. Therefore, in-window ACK numbers with the
specific sequence number (i.e., RCV.NXT-1) still trigger Now that we know the Wi-Fi timing side channel applies
responses (row no. 9) and yet no actual data are buffered universally to all operating systems, we want to test them
at the client, while out-of-window ACK numbers can in real-world attack scenarios.
trigger at most one reply (line 7 and 8 in Table 2).
MacOS. Based on the source code and experiments, ma-
cOS explicitly handles keep-alive packets and always 5.1 Connection (Four-tuple) Inference
responds with an ACK regardless of the ACK number General method. The general probing strategy is al-
so the strategy against Linux does not apply to macOS. ready discussed in §4. In our implementation, we con-
On the other hand, macOS has its own implementation servatively test one port every round with 30 repeated
of ACK number validation which correctly responds to packets, followed by a post-probe query to measure RTT.
packets with ACK numbers that are too new (row no. When a guessed port number is correct, we see a sub-
13). Interestingly, it chooses not to reply to packets with stantial increase in the measured RTT. If the goal is to
ACK numbers that are too old when there is no payload infer the presence of any arbitrary connection initiated
(row no. 12). The implementation of macOS is likely by the client, then a bruteforce strategy is all that can be
to be misled by the old statement in RFC 793 that states done. However, if the attacker is attempting to conduct
packets with ACK numbers smaller than SND.UNA can web cache poisoning attack later on, it is possible to tar-
be ignored, which is reinterpreted in RFC 5961 (quote): get a connection initiated by the puppet itself [25], which
“All incoming segments whose ACK value doesn’t sat- opens up an additional optimization below taking advan-
isfy the above condition MUST be discarded and an ACK tage of the ephemeral port selection algorithm employed
sent back”, where the “above condition” is the acceptable by different OSes.
window of [SND.UNA - MAX.SND.WND, SND.NXT]. In
Windows and macOS. They use a global and sequential
summary, this non-compliant behavior of macOS allows
port allocation strategy to select ephemeral port number
an attacker to infer if a guessed ACK number is too large
for their TCP connections. This means that the attacker
or too small, resulting in a binary search.
can deduce the next port number to be used once it ob-
Windows. Windows is for the most part similar to Linux
serves the initial connection to the malicious web server.
on the ACK number validation, except that it has made
This eliminates the need of port number inference com-
one subtle customization. Initially, we were surprised
pletely.
to find that an incoming data packet with an in-window
sequence number is always silently dropped unless the Linux. It uses the Simple Hash-Based Port Selection
ACK number is equal to SND.UNA or SND.NXT (the con- (SHPS) [27] where there is an independent local port
nection is idle during our initial experiments so the two number space for each remote IP and port pair. This
numbers are equal). This implementation is not con- means that the local port number observed from the con-
formant to the standard at all. Recall the standard says nection to the malicious web server can no longer predict
that the acceptable ACK number range is defined to be the next local port number for the connection to a differ-
[SND.UNA - MAX.SND.WND, SND.NXT] in RFC 5961 ent target server which the attacker does not control. To
and both Linux and macOS follow the standard. In fact, avoid bruteforcing all possible port numbers, we develop
we thought the implementation was completely wrong an optimized strategy based on the observation that local
because it may drop legitimate data packets in cases like port numbers allocated for the same remote server and
out-of-order packet arrivals. We then realize that it ap- port pair are sequential; therefore, the puppet can poten-
pears to be a reasonable decision, especially when the tially create n connections to the target server and only
connection is idle. Indeed, if there are no outstanding needs to test the port number every n increments.
data to send, it is safe to require the peer to acknowledge At this point, we can conduct the side channel attack
one and only one ACK number. However, as soon as on the connection of which we guessed the correct port
there are outstanding data, it should enlarge the accept- number. Also, by carefully scheduling those n requests
able ACK number range. We experimentally confirmed we are guaranteed that a future request will use the con-
that this is exactly what Windows does. In summary, the nection with the smallest port number as opposed to the

1590 27th USENIX Security Symposium USENIX Association


others closed later. to control the timing and predict what fake response to
NAT. In our experience with Wi-Fi routers, we find that inject.
they typically are port preserving. So we do not have Since all three systems do not comply with the specifi-
to worry about the external port being translated and be- cations in terms of ACK validation, we have to cope with
come unpredictable. This is based on our testing of 4 each variant differently:
different home routers and the university network. How- MacOS incorrectly interpreted the standard, allowing us
ever, if non-port-preserving NAT are indeed used for Wi- to perform a binary search (see §4). Once the expected
Fi, then the attacker can either fall back to the brute- ACK number is inferred, we perform a desynchroniza-
force approach, or apply the optimized solutions pro- tion attack [18] to avoid a race condition where the re-
posed in [27] (which has its own benefits and caveats). sponse is sent back by the server first. Then, as soon as
Multiple IP addresses from a domain. This essentially the puppet requests for the target object, it informs the
requires the attacker to double or triple the effort of port attacker to send a spoofed response, which is accepted.
number inference. For Windows and macOS, this is not Linux It’s feasible to exploit the timing side channel to
much more effort. However, for Linux it does require infer ACK number, though the valid ACK window size
some more time. is much smaller compared to the receive window size,
resulting in longer inference time. One alternative ap-
5.2 Sequence Number Inference proach is to conduct blind data injection without know-
ing the exact value of the expected ACK number. Our
General method As shown in table 2, we’re able to observation is that by now we’ve known the exact se-
distinguish in-window sequence number from out-of- quence number and the size of any object that the client
window one by leveraging timing side channel to tell retrieves (see §5.4), we are capable of predicting a fu-
whether there are corresponding responses. As soon as ture expected sequence number after N objects are re-
we get an in-window sequence number, we further nar- trieved. The attack then goes as follows: (1) Desynchro-
row down the sequence number space to a single value nization. The puppet keeps requesting an object, while
RCV.NXT by conducting a binary search. This is similar the attacker sends a number of spoofed packets with the
to prior work [39, 18]. Similar to connection inference, if same in-window sequence number that matches a fu-
the attacker is attempting to conduct web cache poison- ture RCV.NXT, bruteforcing the ACK numbers (which is
ing attack against a connection initiated by the puppet much faster than side channel attack as there is no wait
itself [25], an additional optimization is possible. for any feedback). When the last valid response comes
Optimization: Increase window size. To substan- back advancing the sequence number to the value we an-
tially decrease the number of iterations of guesses, one ticipate, suddenly the attacker-injected response will be
straightforward approach is to drastically enlarge the appended and forwarded together to the browser (and
client’s receive window. To this end, the puppet can re- yet the browser always has only one pending request).
quest excessive amounts of large objects. Upon the re- Chrome will close the connection, stopping the attack;
ceipt of enough full segments, the receiver would sig- in contrast, Firefox will simply accept the first response,
nificantly increase its receive window size according to ignoring the second one, resulting in desynchronization
TCP flow control. In our experiments, we found that between the client and server (i.e., the client believes it
the window size could be typically scaled up to around has received more data than the server has actually sent).
x = 500, 000, in striking contrast to the original size (e.g., (2) Blind data injection. Now the puppet will switch
65, 535). It’s worth noting that the window size can never the target web object to the one we want to attack (i.e.,
be shrunk once it is enlarged, according to RFC793 [4]. homepage of a banking website). The attacker now has
Similarly, by uploading data, the ACK window (i.e., the enough time to send a valid response. Since the attacker
peer’s sequence window) can be extended, though it’s knows the next expected sequence number, it only needs
usually much smaller than the maximum sequence win- to again bruteforce all possible ACK numbers. Note that
dow size that we can achieve. this strategy requires two rounds of bruteforcing of ev-
ery possible ACK number, and each round takes only a
couple of seconds as there is no waiting. In contrast, a
5.3 TCP Hijacking side channel attack would take much longer (minutes)
We assume in this section that the attacker is attempting because every guessed ACK number takes 30 packets,
to poison the web cache through hijacking the puppet- and the timing measurement needs to be collected before
initiated connection, which enables the attack to be more the next guess can be made.
efficient. In principle, the attacker can hijack any con- Windows As we mentioned in §4, to prevent the valid
nection initiated by the client; it is simply more difficult ACK window size being one-byte only, the client has to

USENIX Association 27th USENIX Security Symposium 1591


Predicted
keep sending requests to make sure there are always out- Sequence
standing data, which complicates our attacks because the Number + Spoofed responses
Initial Offset .
attacker has to synchronize the next expected sequence Sequence offset . (sent in advance)
. with all guessed
number. Besides, a large amount of traffic also intro- Number
ACK numbers
(Known)
duces noise to the timing side channel. Moreover, the Packet with acceptable
blind data injection we utilize on Linux does not apply …
ACK number
to the same version of Firefox on Windows according
Old data overruns
to our tests; it immediately drops the connection when new data
it receives two responses for only one pending request. X Responses
Overwritten
Response
We therefore devise a new strategy that exploits the TCP
behavior of handling overlapping data and the browser Figure 8: HTTP injection by exploit tolerant browsers
behavior of handling corrupted HTTP responses. If a
new incoming TCP data packet has an overlapping se-
quence number range with some previously buffered dictable (i.e., HTTP), instead of corrupting the real re-
data, we find that old data are always preferred in Win- sponse, one overwrite the header and the body to form
dows whereas new data are preferred in Linux (this ob- a legitimate but malicious response. A browser in this
servation is consistent with prior studies [38]). In other case will be completely oblivious to the existence of in-
words, attacker-injected data buffered on a Windows host jection. This demonstrates that once sequence number
can corrupt a real HTTP response from the server. Given is leaked, there exist various ways to inject data into
the insight, we present the exploit in two steps which browsers efficiently, without conducting the much slower
are illustrated in Fig. 8: (1) Inject. The puppet continu- timing-channel-based ACK number inference.
ously requests scripts from the server, while the attacker
232
sends |wnd| spoofed packets with a deliberate in-window 5.4 Other Challenges
sequence number that matches a future RCV.NXT plus a
small offset, where wnd denotes the size of the accept- Dealing with noise by setting a proper threshold. La-
able ACK window. The ith packet has a guessed ACK tency may vary under different network conditions, thus
number i·|wnd|, and contains payload as: it is a bad idea to manually set a threshold to differenti-
ate a quiet probe round (without triggering ACKs) ver-
websocket.send(i · |wnd|)
sus a responsive probe round (triggering ACKs). In our
Hence, exactly one of these packets contains a valid implementation, we devise a simple procedure that auto-
ACK number and will be buffered. We intentionally matically sets a threshold based on a preliminary round
construct the overlap such that the HTTP header of the of test probes prior to launching the actual attack. Since
real response will become corrupted. Interestingly, the we have full control of the connection established be-
browser would still try to interpret the corrupted response tween the client and attacker, we can send non-spoofed
where it simply ignores corrupted header and accepts the packets to measure RTTs for quiet probe rounds and re-
next header (injected by the attacker) along with the re- sponsive probe rounds. After we collect data for both
maining attack payload. When the browser executes the cases, we sort the data and set a threshold such that 80%
injected script, it will send the guessed ACK number of the responsive round measurements will be above the
via websocket, providing a valid in-window ACK num- threshold. The threshold is a trade-off between efficiency
ber. (2) Exploit. Since the client has accepted the extra and effectiveness. Since most of the rounds we’re testing
spoofed payload, advancing its expected sequence num- do trigger ACKs (so larger RTTs should be observed),
ber, the client and server are effectively already desyn- setting a lower threshold will ensure that we correctly
chronized. The attacker can now simply send a spoofed classify such cases to avoid double checking the results.
response (knowing both the expected sequence number However, a threshold too low runs the risk of misclas-
and a valid ACK number). Alternatively, if we only sifying a quiet round into a responsive round, missing
want to perform a one-time injection, simply replacing the correct guess altogether; this forces us to repeat the
the payload in the first step with a malicious script is suf- whole search process. Finally, we ignore cases where
ficient. Note that the attack strategy against Windows is abnormally large RTT values are perceived (e.g., from
even more efficient than the one for Linux because only network noise), if it is out of the range of three times the
one round of bruteforcing of ACK numbers is needed. standard deviations.
Furthermore, there exists an even more general alter- Dealing with noise by error recovery. Even with a
native strategy to the inject step against Windows that properly selected threshold, we may still end up with in-
does not depend on browser behaviors at all. Specifi- correct inferences. We cope with this challenge by em-
cally, as the first few bytes of HTTP responses are pre- bedding extensive error recovery mechanisms into the in-

1592 27th USENIX Security Symposium USENIX Association


ference process, such as relative comparisons and double 4.14.0, and Windows 10 Pro version 1709 (they are also
checking. We assume that network jitter/noise does not the same versions used to study the behaviors of TCP
vary much during the short time interval of testing a few stacks shown in Table 2). We empirically evaluated dif-
rounds (a common assumption in the networking liter- ferent techniques with Chrome 64.0 and Firefox 58.0.1.
ature [26]). In the case of sequence number inference When we evaluated the attack for the ‘Remote Attacker’
as an example, once a sequence number is believed in- scenario, the experiments were performed in the same
window, we further try to narrow down the space to a house as mentioned in §3 with at most 4 users, and RTTs
single value RCV.NXT by binary search. During the pro- between the client and attacker were over 20ms. The
cedure, we also simultaneously measure additional RTTs bandwidth we utilized in the remote and local experi-
(using out-of-window sequence numbers) and their rela- ments are approximately 1000pkts/s and 4000pkts/s re-
tive difference to the RTTs (using in-window sequence spectively (or ⇠ 0.5Mbps and ⇠ 2Mbps), which we be-
numbers). If the comparison results are not consistent, lieve are moderate and comparable to prior work [18].
we can deduce that we made a mistake earlier and will Noise Resilience of Timing Side Channel Using the
rollback. As for false negatives where an in-window same experimental setups as in §3, we introduce two
number is believed out-of-window, there is no simple different types of noise to evaluate the resilience of the
way to detect them but repeating the whole process till Wi-Fi timing side channel. First, for the 5GHz network,
the program finally finds out the correct number or fails the malicious webpage contains a Youtube video, which
due to timeout. would be automatically played while timing measure-
Pipeline In order to significantly reduce the time the at- ments are performed. Second, as 2.4GHz networks tend
tack costs, instead of simply probing a single SEQ/ACK to influence each other, we have also conducted the mea-
number at a time, we also use a pipelined process aiming surement in the lab where there were 43 accessible Wi-Fi
at maximizing network utilization by scheduling probing in total, 22 of which were 2.4GHz network and 6 used
packets for multiple targets at appropriate times. How- the same channel that our test router used; there were
ever, due to the fact that packet loss may happen from also more than 10 students actively using the network.
time to time, we suspend the procedure every few tests As depicted in Fig. 9, the timing channel does encounter
to wait until we get all the results or restart in a fixed additional noise but RTTs are still visibly different.
time interval. Evaluation of Local Attacks Our victim webpage can
be any page transmitted over HTTP. Although Google
Moving SEQ/ACK window and unknown window
Chrome marks some non-HTTPS sites as “not se-
size Since the victim connection is controlled by the pup-
cure”, we still found some sensitive bank websites (e.g.,
pet, it’s idle most of the time unless the puppet triggers
www.icbc.com.cn) that haven’t deployed HTTPS on all
a request. Therefore, the attacker can be fully aware of
of its pages, rendering them vulnerable to our attack.
when the SEQ/ACK window is moving. Besides, regard-
Typically, while allowing seemingly non-sensitive pages
ing the unknown window size to an off-path attacker, our
(e.g., homepage) transmitted over HTTP, websites would
strategy is to initially choose a relatively large window
restrict sensitive pages (e.g., login pages) to HTTPS,
size q and then half it afterwards. So 2iq 1 will be the
presumably because of their concern of both perfor-
window size we use in ith iteration. Note that we do not mance and security. Consequently, an adversary who
test an exact number that has been tested in previous it- successfully hijacked the homepage could have injected
erations to avoid redundancy. a phishing login component already. Furthermore, even
Detecting the size of any object So far, we have as- if HTTPS is deployed on all pages, attackers could still
sumed that we are aware of the size of the response sent mount the attack, as long as HTTP Strict Transport Secu-
from the server to the client so that we can predict where rity (HSTS) is absent; this is because the initial request
to insert the forged payload. This is in fact not difficult to the website will still use HTTP and it is the server
to achieve because once we know the next expected se- that subsequently redirects the browser to its HTTPS
quence number, we can ask the puppet to request the ob- site. One representative example is the news website
ject and then infer the new expected sequence number; ‘www.cnn.com’ which uses HTTPS but unfortunately
the increment is exactly the size of the response. not HSTS. When a user tries to access its homepage, an
initial request is submitted via HTTP for which an ad-
6 Evaluations versary can inject a fake reply, preventing the legitimate
response from redirecting to HTTPS.
Experimental Setup Our network topology is the same Next we report the attack success rate and the average
as in §3. The attack machine is an Ubuntu 14.04 host time to succeed. Depending on our target OS, we lever-
in our lab. We tested those attacks against three differ- age different strategies described in §5.3 along with the
ent operating systems, including macOS 10.13, Linux timing side channel, and present the results in table 3. As

USENIX Association 27th USENIX Security Symposium 1593


OS Browser Success Avg time Technique(s)
Rate cost(s)
Linux Chrome 10/10 188.80 Timing Side Channel
Time(us)

Time(us)
Firefox
MacOS Chrome 10/10 48.91 Timing Side Channel
Firefox
Windows Chrome 10/10 43.42 Timing Side Channel
Firefox & Direct Page Read
Number of Packets Number of Packets Linux Firefox 9/10 103.53 Timing Side Channel
& Blind Data Injection
(a) RTT measurement for 5GHz (b) Gap measurement for 5GHz
of a Huawei router of a Huawei router Table 3: Summary of attacks in a local setup

distinguished with modest false negatives (i.e., missing


Time(us)
Time(us)

in-window numbers) and false positives (i.e., misclassi-


fying an out-of-window number), both of which could
be further reduced by increasing the number of probing
Number of Packets Number of Packets packets per test and more rounds of double-checking.
Next, to complete a realistic attack, we implemented
(c) RTT measurement for (d) Gap measurement for
the web cache poisoning attack against MacOS with
2.4GHz of a Linksys router 2.4GHz of a Linksys router
aforementioned optimizations. Table 4 enumerates the
10 test results along with the number of false negatives
produced during each experiment. It’s worth noting that
Time(us)

we never encountered the case where the attack proce-


dure mistakenly reports a success due to error recovery
and double checking. Besides longer RTTs compared
to that of a local setup, the significant time cost is at-
Number of Packets tributed to the following factors: (1) Regarding sequence
(e) RTT measurement for (f) RTT measurement for number inference upon MacOS, though an attacker can
2.4GHz of a Linksys router 2.4GHz of a Huawei router send probing packets without any flags as shown in ta-
The upper four figures are measured while playing a youtube video, ble 2, we found those packets are likely to be discarded
and the lower two are under wireless interference. in a real-world network environment. To cope with it,
Figure 9: Measurement of MacOS with additional inter- we send probing packets with ACK bit set and guess
ference in a local setup two acknowledgement numbers (e.g., 0 and 2G) for ev-
ery guessed sequence number, effectively doubling the
number of packets sent. (2) Traversing through the entire
it illustrates, three most popular operating systems are all sequence number space already takes roughly 5 minutes,
vulnerable to the attack if they connect to the Internet via if we happen to miss the correct sequence number (false
a wireless router. With respect to the random-increment negative) even once, we need to repeat the search pro-
port selection strategy utilized by Linux, attacks against cess6 . Nevertheless, since there is only one ‘critical’ test
Linux take around 1 more minute on average to infer (i.e., one correct sequence number) in each iteration, the
the port number. Some optimizations discussed in [28] chance of missing it is quite small. We can further re-
could be applied to significantly reduce the time of port duce this chance by tuning the RTT threshold parameter,
inference. We demo some of these attacks on our project which we leave as a future exercise. (3) The time cost
website [3]. varies substantially due to the large search space of the
Evaluation of Remote Attacks To further demonstrate sequence number. Specifically, while the attack attempts
the practicality of the attack, we report results under a to explore every possible sequence number from 0 to 232
“remote attacker” scenario described earlier (the RTT per window, the procedure stops earlier if a correct se-
between the outside attacker and victim is over 20ms). quence number happens to be small.
First, we conducted the same measurements as in §3 to 6 In practice, we consider attacks over 10 minutes to be impractical,
ascertain the timing side channel is not eliminated due to thus attacks halt after two iterations of failure
network jitter. Fig. 10 presents the results of measure-
ments at two different locations in the same city. Though
there is more overlap between the two boxes compared to
the local setup, the signal is clearly present. They can be

1594 27th USENIX Security Symposium USENIX Association


Time(ms) described in [18]).

Time(ms)
8 Defenses
After we discovered the time side channel issue, we have
disclosed it to the working group in February 2018. They
Number of Packets Number of Packets have quickly acknowledged this weakness and became
highly engaged in discussion of the matter. However, due
Figure 10: RTT measurement of macOS using 5GHz net- to the expected challenges in changing the half-duplex
work of a Xiaomi router at two different locations with design, we are yet to see an appropriate solution at the
RTTs over 20ms 802.11 level. Therefore, the immediate mitigations are
expected to be at higher levels. We’ve also disclosed it to
Result Time cost (s) #FN Result Time cost (s) #FN vendors of the routers that we tested, among whom only
success 25.66 0 success 23.08 0
one replied and actively discussed it with us. Though the
success 286.31 0 success 580.32 1
success 549.15 1 success 195.03 0 company employees acknowledged this weakness, they
success 335.10 0 success 227.43 0 decided to submit this security issue to Wi-Fi Alliance,
failure 634.03 2 success 185.74 0 hoping that this would be fixed in the protocol standard.
FN: False Negative (i.e., Missing correct SEQ number)
In the reminder of this section, mitigations/patches at dif-
Table 4: 10 trials of remote attacks against macOS ferent layers are offered and thoroughly discussed.
Defenses in Wi-Fi technology. Unlike the previous
software-induced side channels, the timing channel in-
7 Discussion troduced by Wi-Fi is inherently difficult to eliminate or
mitigate (just as the recent meltdown and spectre vulner-
As discussed in §3, the timing side channel results from ability in CPUs [35, 34]). One straightforward defense
the half-duplex nature of wireless networks. It is further would be to make the Wi-Fi channel full-duplex. For in-
magnified due to the collision and backoff inherent in stance, with frequency-division duplexing, different fre-
wireless protocols. As we demonstrated, a full-duplex quency sub-bands can be used for uplink and downlink
system does not exhibit any timing channel (see §3) as traffic. However, this can potentially introduce low band-
no collision will occur when uplink and downlink traffic width utilization as separate dedicated sub-bands have to
happen at the same time. Finally, as confirmed in our test be pre-allocated (and real-world Internet traffic volume
routers, modern wireless routers all support CSMA/CA is not symmetric). Even though IEEE 802.11ax work-
and RTS/CTS as it is part of the 802.11 standards [31], ing group has been considering the possibility of sup-
and the principle is unlikely to change any time soon. porting in-band full-duplex communication [2], research
Although we only discuss the threat model where con- still needs to be done to make sure the real-world chal-
nections originated from a victim client are targeted, lenges such as backward compatibility are carefully con-
the attack actually also applies to connections originated sidered and addressed [12, 30]. At this point though, it is
from other clients connected through the same wireless unclear when the technology will be widely deployed in
router. This is because all these clients (e.g., behind the practice, according to our conversation with the 802.11
same NAT) share the same collision domain and there- working group.
fore suffer from the same timing channel. Responses Defenses in the TCP stacks. As described in §2.2,
triggered on any client by probing packets will effec- the packet validation logic of the latest TCP specification
tively delay the post-probe query. In this case, the victim inherently treats valid and invalid incoming packets dif-
connection (opened through puppet) simply opens up op- ferently, in terms of whether a response should be gener-
portunities for an off-path attacker to measure collision. ated. One solution is to revisit the specification and look
In addition, we can expand the threat model to consider for alternatives. A good hint is that all three modern op-
servers that are wirelessly connected, e.g., IoT devices. erating systems implement the ACK number validation
It has been shown that millions of IoT devices are reach- differently, yet they have co-existed without any major
able through public IP addresses and open ports [14]. In issues for a long time now. This leaves some flexibility
such cases, a completely off-path attack can be launched in the ACK number validation logic. Ideally, no matter
against a connection on such IoT devices, e.g., counting what ACK number an incoming packet has, it should ei-
bytes exchanged on the connection, terminating its con- ther consistently respond or never respond. Assuming an
nection with another host, injecting malicious command incoming packet already has a valid sequence number,
on an ongoing telnet connection (similar to the capability the only constraints we have here are:

USENIX Association 27th USENIX Security Symposium 1595


(1) if it is a data packet and its ACK number is also in- garding Windows, although it also defeats our first strat-
window, a correct TCP receiver should always respond egy to infer ACK number by creating a malformed re-
with an ACK (or delayed ACK); (2) when a pure ACK sponse, our alternative strategy is unaffected. MacOS’s
with sequence number in-window and ACK number in- TCP stack implementation is so vulnerable that we will
window arrives, there should be no response (otherwise, always favor the binary search on the ACK number to
an ACK war [6] may be triggered). exploiting any browser-specific weakness. Finally, con-
In the remaining cases: (3) a data packet with out- nection inference (privacy breach) and sequence number
of-window ACK number; (4) a pure ACK with out-of- inference (byte counting and reset) attacks remain potent
window ACK number, their responses appear to be flex- as they only rely on the TCP stack.
ible in practice — see row no. 2, 3, 13, 16, and 18 in For the purpose of supporting further research to re-
Table 2) for the data packet case and row no. 2, 3, 12, produce and mitigate the attack, we open sourced our
13, and 18 for the pure ACK case. Therefore, assum- implementation of the attack against different OSes, now
ing an incoming packet already has an in-window se- publicly available at [5].
quence number, we can always force a response for a
data packet, and no response for pure an ACK packet re-
9 Related Work
gardless of their ACK numbers. We plan to validate this
idea by formally model checking the proposed changes We have described the most relevant work of various off-
together with legacy behaviors for the absence of ACK path TCP attacks in §2.3. In this section, we discuss a
war. different set of related works.
With regards to sequence number validation, we hy- Other off-path side channels. Besides the TCP se-
pothesize that the responses of receiving packets with quence number, it has been shown that other types of in-
valid and invalid sequence numbers can also be consis- formation can be inferred by a blind off-path attacker.
tent. However its implications must be evaluated more [24, 33, 23, 48, 13, 49, 26, 41, 37]. Most of these
carefully. A good strategy to consider is to rate limit side channels do not in themselves allow serious attacks.
ACK responses generated for various types of incoming However, much of the research translates to measure-
packets. Even if inconsistent, this would allow the dif- ment tools that can be useful. For example, Knockel et
ferences in responses (e.g., one response vs. zero) to be al. [33] demonstrate the use of a new per-destination
small enough and impossible to measure. The same rate IPID side channel that can leak the number of packets
limiting idea applies to connection identification, where sent between two arbitrary hosts on several major operat-
packets are likely dropped by NAT or firewall if no con- ing systems. Alexander et al. [13] can infer the RTT be-
nection is present and some response will be triggered if tween two arbitrary hosts through the shared SYN back-
there is an active connection. log. Qian et al. [41] used global IPID side channel to
Defenses in Application layer Clearly, HSTS and measure directional port blocking. More recently, the
HTTPS will help ward off most serious web attacks Augur system [37] used the same IPID side channel to
such as the web cache poisoning attack. Other TCP- measure Internet censorship and connectivity disruption.
level attacks (e.g., inferring presence of connection [18], The same side channel has also been used to count how
byte counting [20], connection reset [18]) could still many hosts are behind a NAT [15] and other applica-
be mounted by exploiting the vulnerability. HSTS and tions [21].
HTTPS can prevent only web cache poisoning attack Side channel discovery and defenses. Typically,
(application-layer attacks) but not the TCP-level attacks. when a specific type of vulnerability becomes known,
Some versions of our attack also exploit features of there are many strategies to discover more concrete in-
browser implementations, and thus we believe some mit- stances of them. For instance, static taint analysis has
igations can be made in the browser (i.e., make parsing been applied to look for TCP packet counter side chan-
of responses stricter) to complicate the ACK number in- nels [19]. The problem is modeled as an information
ference step. The idea is that whenever the browser ob- flow problem where the secret is the current sequence
serves anything abnormal regarding the responses, e.g., number, and the sink is the set of packet counters that re-
malformed or longer than expected, it should immedi- port aggregated statistics to user space programs. If the
ately drop the connection and restart. A small tradeoff secret sequence number can leak to the sink, then it is
is that this may break some backward compatibility with flagged as a potential side channel. There may be false
non-standard-conforming web servers. In terms of its ef- positives (due to the over-approximation of the static
fectiveness in stopping web cache poisoning attacks, it analysis) but should not have false negatives by design.
really only helps Linux as the attack now needs to fall- In the case of CPU cache side channels, symbolic execu-
back to a much slower version of the ACK number infer- tion has been applied to track the precise cache state over
ence (likely tripling the time for a complete attack). Re- execution traces [47]. If the cache states can be different

1596 27th USENIX Security Symposium USENIX Association


at any point in the trace with different secret inputs, the [3] Off-path tcp exploit: Demos of web cache poisoning at-
program is flagged to have leakage. Since the analysis is tacks. https://sites.google.com/view/tcp-off-path-e
xploits/.
applied over concrete execution traces, the approach has
[4] RFC 793 - Transmission Control Protocol. http://tools.iet
no false positives (but may have false negatives). Unfor-
f.org/html/rfc793.
tunately, the Wi-Fi side channel is not a software artifact
[5] TCP Exploit. https://github.com/seclab-ucr/tcp explo
and therefore cannot be discovered unless it is explicitly it.
modeled and analyzed. [6] [tcpm] mitigating TCP ACK loop (“ACK storm”) DoS at-
In terms of side channel defenses, there are various tacks. https://www.ietf.org/mail-archive/web/tcpm/
standard strategies such as perturbing the channel by in- current/msg09450.html.
jecting noise [7, 22, 45], and isolating the resources al- [7] [patch net] linux tcp flaw lets ’anyone’ hijack internet traffic,
together [8, 32]. Unfortunately for Wi-Fi, these stan- 2016.
dard techniques would mean introducing wireless la- [8] [patch net] tcp: enable per-socket rate limiting of all ’challenge
tency (which hurts performance), or making the channel acks’, 2016.
full-duplex which we discussed earlier to be challenging [9] About the security content of macos high sierra 10.13, 2017.
as well. [10] About the security content of macos high sierra 10.13.1, security
update 2017-001 sierra, and security update 2017-004 el capitan,
2017.
10 Conclusions
[11] The darwin kernel. https://github.com/apple/darwin-x
To conclude, we have discovered a subtle yet fundamen- nu, 2017.
tal side channel inherent in all generations of Wi-Fi or [12] A IJAZ , A., AND K ULKARNI , P. Protocol design for enabling
IEEE 802.11 technology because they are half-duplex. full-duplex operation in next-generation ieee 802.11 wlans. IEEE
Furthermore, we show the timing channel is reliable and Systems Journal PP, 99 (2017), 1–12.
amplifiable, and also implement a real off-path TCP ex- [13] A LEXANDER , G., AND C RANDALL , J. R. Off-Path Round Trip
ploit in practice, allowing the attackers to inject data into Time Measurement via TCP/IP Side Channels. In INFOCOM
(2015).
a TCP connection and force the browser to cache mali-
[14] A NTONAKAKIS , M., A PRIL , T., BAILEY, M., B ERNHARD , M.,
cious objects. Our study reveals that this novel attack B URSZTEIN , E., C OCHRAN , J., D URUMERIC , Z., H ALDER -
affects all three most popular operating systems: ma- MAN , J. A., I NVERNIZZI , L., K ALLITSIS , M., K UMAR , D.,
cOS, Windows, and Linux. We provide a thorough anal- L EVER , C., M A , Z., M ASON , J., M ENSCHER , D., S EAMAN ,
ysis and evaluation of the proposed attack under different C., S ULLIVAN , N., T HOMAS , K., AND Z HOU , Y. Under-
standing the mirai botnet. In 26th USENIX Security Symposium
router/network/OS/browser combinations. Finally, we (USENIX Security 17) (Vancouver, BC, 2017), USENIX Associ-
propose possible defenses against this attack. ation, pp. 1093–1110.
[15] B ELLOVIN , S. M. A Technique for Counting Natted Hosts. In
Proceedings of the 2Nd ACM SIGCOMM Workshop on Internet
Acknowledgement Measurment (2002).
[16] B ENSAOU , B., WANG , Y., AND KO , C. C. Fair medium access
We wish to thank Zakir Durumeric (our shepherd) and in 802.11 based wireless ad-hoc networks. In Proceedings of the
the anonymous reviewers for their valuable comments 1st ACM international symposium on Mobile ad hoc networking
and suggestions. Many thanks to Prof. Srikanth V. Kr- & computing (2000), IEEE Press, pp. 99–106.
ishnamurthy, Mart Molle, and Zhuo Lv who educated us [17] C ALI , F., C ONTI , M., AND G REGORI , E. Ieee 802.11 protocol:
on the fundamentals of wireless networks. We are also design and performance evaluation of an adaptive backoff mech-
anism. IEEE journal on selected areas in communications 18, 9
fortunate to work with the IEEE 802.11 working group, (2000), 1774–1786.
specifically Dorothy Stanley, Daniel Harkins, Jouni Ma- [18] C AO , Y., Q IAN , Z., WANG , Z., DAO , T., K RISHNAMURTHY,
linen, to discuss the side channel and are grateful for their S. V., AND M ARVEL , L. M. Off-path TCP exploits: Global rate
insights. This work was supported by the National Sci- limit considered dangerous. In 25th USENIX Security Symposium
ence Foundation under Grant No.1464410, 1652954, and (USENIX Security 16) (2016).
1646641. [19] C HEN , Q. A., Q IAN , Z., J IA , Y. J., S HAO , Y., AND M AO ,
Z. M. Static detection of packet injection vulnerabilities: A case
for identifying attacker-controlled implicit information leaks. In
References CCS (2015).
[20] C HEN , S., WANG , R., WANG , X., AND Z HANG , K. Side-
[1] Blind TCP/IP Hijacking is Still Alive. http://phrack.org/i
channel Leaks in Web Applications: A Reality Today, a Chal-
ssues/64/13.html.
lenge Tomorrow. In IEEE Symposium on Security and Privacy
[2] In-band Full Duplex Radios and System Performance. https: (2010).
//mentor.ieee.org/802.11/dcn/15/11-15-0043-01-00a [21] C HEN , W., H UANG , Y., R IBEIRO , B. F., S UH , K., Z HANG , H.,
x-in-band-full-duplex-radios-and-system-perform DE S OUZA E S ILVA , E., K UROSE , J., AND T OWSLEY, D. Ex-
ance.pdf. ploiting the ipid field to infer network path and end-system char-
acteristics. In Proceedings of the 6th International Conference on
Passive and Active Network Measurement (PAM) (2005).

USENIX Association 27th USENIX Security Symposium 1597


[22] C RANE , S., H OMESCU , A., B RUNTHALER , S., L ARSEN , P., [41] Q IAN , Z., M AO , Z. M., X IE , Y., AND Y U , F. Investigation of
AND F RANZ , M. Thwarting cache side-channel attacks through Triangular Spamming: A Stealthy and Efficient Spamming Tech-
dynamic software diversity. In Proceedings of the 15th Annual nique. In Proc. of IEEE Security and Privacy (2010).
Network and Distributed System Security Symposium (NDSS) [42] Q UACH , A., WANG , Z., AND Q IAN , Z. Investigation of the 2016
(2015). linux tcp stack vulnerability at scale. In Proc. ACM SIGMETRICS
[23] E NSAFI , R., K NOCKEL , J., A LEXANDER , G., AND C RAN - (2017).
DALL , J. R. Detecting Intentional Packet Drops on the Internet
[43] R. B RADEN , E D . Requirements for Internet Hosts - Communi-
via TCP/IP Side Channels. In PAM (2014).
cation Layers. rfc 1122, 1989.
[24] E NSAFI , R., PARK , J. C., K APUR , D., AND C RANDALL , J. R.
[44] R AMAIAH , A NANTHA AND S TEWART, R AND DALAL ,
Idle Port Scanning and Non-interference Analysis of Network
M ITESH. Improving TCP’s Robustness to Blind In-Window At-
Protocol Stacks using Model Checking. In USENIX Security
tacks. rfc5961, 2010.
(2010).
[45] S HAN , Z., N EAMTIU , I., Q IAN , Z., AND T ORRIERI , D. Proac-
[25] G ILAD , Y., AND H ERZBERG , A. Off-Path Attacking the Web.
tive restart as cyber maneuver for android. In MILCOM 2015 -
In USENIX WOOT (2012).
2015 IEEE Military Communications Conference (2015).
[26] G ILAD , Y., AND H ERZBERG , A. Spying in the Dark: TCP and
[46] T OBAGI , F., AND K LEINROCK , L. Packet switching in radio
Tor Traffic Analysis. In PETS (2012).
channels: part ii–the hidden terminal problem in carrier sense
[27] G ILAD , Y., AND H ERZBERG , A. When tolerance causes weak- multiple-access and the busy-tone solution. IEEE Transactions
ness: the case of injection-friendly browsers. In WWW (2013). on communications 23, 12 (1975), 1417–1433.
[28] G ILAD , Y., AND H ERZBERG , A. Off-path tcp injection attacks. [47] WANG , S., WANG , P., L IU , X., Z HANG , D., AND W U , D.
ACM Transactions on Information and System Security (TISSEC) Cached: Identifying cache-based timing channels in production
16, 4 (2014), 13. software. In 26th USENIX Security Symposium (USENIX Secu-
[29] G OGUEN , J. A., AND M ESEGUER , J. Security Policies and rity 17) (Vancouver, BC, 2017), USENIX Association, pp. 235–
Security Models. In IEEE Symposium on Security and Privacy 252.
(1982). [48] Z HANG , X., K NOCKEL , J., AND C RANDALL , J. R. Original
[30] IEEE 802.11-13/1421 R 1. STR radios and STR media access. SYN: Finding Machines Hidden Behind Firewalls. In INFOCOM
(2015).
[31] IEEE 802.11 W ORKING G ROUP OF THE LAN/MAN S TAN -
DARDS C OMMITTEE OF THE IEEE C OMPUTER S OCIETY .
[49] Z HANG , X., K NOCKEL , J., AND C RANDALL , J. R. High fi-
802.11-2016 - IEEE Standard for Information technology– delity off-path round-trip time measurement via tcp/ip side chan-
Telecommunications and information exchange between systems nels with duplicate syns. In 2016 IEEE Global Communications
Local and metropolitan area networks–Specific requirements - Conference (GLOBECOM) (Dec 2016), pp. 1–6.
Part 11: Wireless LAN Medium Access Control (MAC) and [50] Z HOU , Z., Q IAN , Z., R EITER , M. K., AND Z HANG , Y. Static
Physical Layer (PHY) Specifications. evaluation of noninterference using approximate model counting.
[32] K IM , T., P EINADO , M., AND M AINAR -RUIZ , G. STEALTH- In Proc. of IEEE Security and Privacy (2018).
MEM: System-level protection against cache-based side channel
attacks in the cloud. In Presented as part of the 21st USENIX
Security Symposium (USENIX Security 12) (2012).
[33] K NOCKEL , J., AND C RANDALL , J. R. Counting Packets Sent
Between Arbitrary Internet Hosts. In FOCI (2014).
[34] KOCHER , P., G ENKIN , D., G RUSS , D., H AAS , W., H AMBURG ,
M., L IPP, M., M ANGARD , S., P RESCHER , T., S CHWARZ , M.,
AND YAROM , Y. Spectre attacks: Exploiting speculative execu-
tion. ArXiv e-prints (January 2018).
[35] L IPP, M., S CHWARZ , M., G RUSS , D., P RESCHER , T., H AAS ,
W., M ANGARD , S., KOCHER , P., G ENKIN , D., YAROM , Y.,
AND H AMBURG , M. Meltdown. ArXiv e-prints (January 2018).

[36] M ILLER , B., H UANG , L., J OSEPH , A. D., AND T YGAR , J. D.


I know why you went to the clinic: Risks and realization of https
traffic analysis. In Privacy Enhancing Technologies (2014).
[37] P EARCE , P., E NSAFI , R., L I , F., F EAMSTER , N., AND PAXSON ,
V. Augur: Internet-wide detection of connectivity disruptions. In
2017 IEEE Symposium on Security and Privacy (SP) (May 2017),
pp. 427–443.
[38] P TACEK , T. H., AND N EWSHAM , T. N. Insertion, Envasion, and
Denial of Service: Eluding Network Intrusion Detection. Tech.
rep., 1998.
[39] Q IAN , Z., AND M AO , Z. M. Off-Path TCP Sequence Number
Inference Attack – How Firewall Middleboxes Reduce Security.
In IEEE Symposium on Security and Privacy (2012).
[40] Q IAN , Z., M AO , Z. M., AND X IE , Y. Collaborative TCP se-
quence number inference attack: how to crack sequence number
under a second. In CCS (2012).

1598 27th USENIX Security Symposium USENIX Association

You might also like