tl;dr: This vulnerability is quite serious, but it doesn’t affect
the Tor network any more than it affects the rest of the internet.
In particular, the Tor-specific attacks mentioned in the paper will
not work as described.
Recently,
an excellent paper,
entitled “Off-Path TCP Exploits: Global Rate Limit Considered
Dangerous,” was published by Yue Cao, Zhiyun Qian, Zhongjie Wang, Tuan
Dao, Srikanth V. Krishnamurthy, and Lisa M. Marvel at USENIX Security
2016.
When a TCP packet is sent, the sender and receiver both know a number,
called the sequence number, that this packet should have. If the
sequence number is not correct, various (complicated, boring) things
may happen, but the important part is that neither the sender nor the
receiver actually believes that this is a valid packet. Instead, they
assume something went wrong somehow, or that an active attacker is
attempting to inject packets into their communication stream. The
term blind simply means that an attacker is unable to directly
observe the packets going between the sender and receiver, but is
usually instead trying to use some side-channel to determine this
information. There’s another part of the TCP specification which
describes windowing — which simply means (did I mention that TCP is
very complicated and boring…) that the sequence number was “correct
enough” — that is, that the sequence number was within the right
range. Specification nerds have long argued over what “correct
enough” means, because apparently they find this topic absolutely
riveting.
The fix to the TCP blind in-window attack was to specify that, under
certain conditions, if the TCP sequence number doesn’t match what was
expected, the receiver of this messed up packet should send a
“challenge” ACK to the sender. Depending on the type of
messed-up-ness, the sender and receiver do one of a number of little
dances with each other, in the special way that TCP is so fond of
doing. When one party sends a challenge ACK, they increment a counter
stored in a global variable which is shared across all TCP
connections. This global variable is reset to 0 once per second, and
it has a maximum value of 100, i.e. no more than 100 challenge ACKs
will be sent per second (for all connections combined). If it wasn’t
obvious from the title of the paper, global variables (across
programming languages, frameworks, and contexts) are commonly known to
be a very bad, no good, horrible idea.
The attack described in the paper is elegant. In terms of its impact,
96.6% of the Alexa top one million
are running Linux kernels, and hence are likely vulnerable. The
previously described global ACK counter enables various side-channels
acrossTCP connections, meaning that a blind attacker can determine …
Previously, Matthew Garrett and I came up with an
new idea for a method of local attestation. Local attestation here means:
authenticating the computer that the user possesses a valid hardware token
and authenticating to the user that the computer is executing the intended
code, and that said code has not been tampered with. The idea is to use some
NFC-enabled “smart” wearable device, something trivially hideable on (or
inside¹) one’s person in order to authenticate to the TPM, which then
validates that the next stage of code to be executed, e.g. usually the kernel
(ring 0) or the hypervisor (ring “-1”), has verifiable integrity. Matthew has
a great 32c3 talk on
TPM-based local attestation, and even breifly, towards the end of the video,
mentions the NFC ideas.
As an example use case, this would allow journalists² greater safety when
crossing borders. Your laptop got taken away by the TLA at a border? Not
such a problem; it simply doesn’t boot without you present. The TLA took your
laptop into the back room to try to install some malware on it? No worries,
because your laptop will refuse to boot the next time you try to do so (or it
could signal in some other way that the system was compromised… however,
refusing to decrypt the user’s harddrive is probably a bare minimum safety
requirement, and refusing to boot at all is probably the safest).
However, all of this places a great deal of trust in both the TPM device and
its manufacturer…
Despite Joanna Rutkowska’s
concerns over untrusted user input/output,
it would be interesting to see a system, built upon the above local
attestation method, which uses an
Intel SGX enclave
(see the
Intel Instruction Set Extensions Programming Reference
for architectural details) to execute code whose integrity has been previously
verified through two-factor authenticated TPM local attestation. This doesn’t
require user I/O, and it doesn’t require anything to be displayed to the user.
What it would provide, however, is a way for the code whose integrity is
verified by the TPM to remain safely isolated from:
the BIOS, or tampering thereof,
System Management Mode (SMM), and,
(possibly) Intel Active Management Technology (AMT) — modulo Intel’s SGX
implementation (and how much you trust said implementation to protect you from
their AMT backdoor).
This protects against tampering of the BIOS itself, which, otherwise, could
possibly subvert the initialisation of the TPM hardware and cause the
integrity verification checks to falsely pass. Without SGX, SMM (ring “-2”)
would have the capability to emulate and/or forward calls to and from the TPM
device, and as such any SMM-based attack would completely subvert the local attestation.
Additionally, in my and Matthew’s NFC-TPM-based local attestation method, the
cryptographic code for verification would need to be partially executed on the
“smart” device. In
Matthew’s 32c3 talk,
the laptop uses a pre-shared key, stored in the TPM, to generate …
