90 lines
4.6 KiB
Markdown
90 lines
4.6 KiB
Markdown
# Known Vulnerabilities
|
|
|
|
## Low-probability Man-In-The-Middle Attacks
|
|
|
|
By default, wormhole codes contain 16 bits of entropy. If an attacker
|
|
can intercept your network connection (either by owning your network, or
|
|
owning the rendezvous server), they can attempt an attack. They will
|
|
have a one-in-65536 chance of successfully guessing your code, allowing
|
|
them to pose as your intended partner. If they succeed, they can turn
|
|
around and immediately start a new wormhole (using the same code),
|
|
allowing your partner to connect to them instead of you. By passing,
|
|
observing, and possibly modifying messages between these two
|
|
connections, they could perform an MitM (Man In The Middle) attack.
|
|
|
|
If the server refused to re-use the same channel id (aka "nameplate")
|
|
right away (issue #31), a network attacker would be unable to set up the
|
|
second connection, cutting this attack in half. An attacker who controls
|
|
the server would not be affected.
|
|
|
|
Basic probability tells us that peers will see a large number of
|
|
WrongPasswordErrors before the attacker has a useful chance of
|
|
successfully guessing any wormhole code. You should expect to see about
|
|
32000 failures before they have a 50% chance of being successful. If you
|
|
see many failures, and think someone is trying to guess your codes, you
|
|
can use e.g. `wormhole send --code-length=4` to make a longer code
|
|
(reducing their chances significantly).
|
|
|
|
Of course, an attacker who learns your secret wormhole code directly
|
|
(because you delivered it over an insecure channel) can perform this
|
|
attack with 100% reliability.
|
|
|
|
|
|
## DoS Attack on the Rendezvous Server
|
|
|
|
Wormhole codes can be so short because they implicitly contain a common
|
|
rendezvous server URL (any two applications that use magic-wormhole
|
|
should be configured to use the same server). As a result, successful
|
|
operation depends upon both clients being able to contact that server,
|
|
making it a SPOF (single point of failure).
|
|
|
|
In particular, grumpy people could disrupt service for everyone by
|
|
writing a program that just keeps connecting to the rendezvous server,
|
|
pretending to be real clients, and claiming messages meant for
|
|
legitimate users.
|
|
|
|
I do not have any good mitigations for this attack, and functionality
|
|
may depend upon the continued goodwill of potential vandals. The weak
|
|
ones that I've considered (but haven't implemented yet) include:
|
|
|
|
* hashcash challenges when the server is under attack
|
|
* per-IP rate-limiting (although I'd want to be careful about protecting
|
|
the privacy of the IP addresses, so it'd need a rotating hash seed)
|
|
* require users to go through some external service (maybe ReCAPTCHA?)
|
|
and get a rate-limiting ticket before claiming a channel
|
|
* shipping an attack tool (flooding the first million channels), as part
|
|
of the distribution, in a subcommand named `wormhole
|
|
break-this-useful-service-for-everybody-because-i-am-a-horrible-person`,
|
|
in the hopes that pointing out how easy it is might dissuade a few
|
|
would-be vandals from feeling a sense of accomplishment at writing
|
|
their own :). Not sure it would help much, but I vaguely remember
|
|
hearing about something similar in the early multi-user unix systems
|
|
(a publicly-executable /bin/crash or something, which new users
|
|
tended to only run once before learning some responsibility).
|
|
|
|
Using the secret words as part of the "channel id" isn't safe, since it
|
|
would allow a network attacker, or the rendezvous server, to deduce what
|
|
the secret words are: since they only have 16 bits of entropy, the
|
|
attacker just makes a table of hash(words) -> channel-id, then reverses
|
|
it. To make that safer we'd need to increase the codes to maybe 80 bits
|
|
(ten words), plus do some significant key-stretching (like 5-10 seconds
|
|
of scrypt or argon2), which would increase latency and CPU demands, and
|
|
still be less secure overall.
|
|
|
|
The core problem is that, because things are so easy for the legitimate
|
|
participants, they're really easy for the attacker too. Short wormhole
|
|
codes are the easiest to use, but they make it for a trivially
|
|
predictable channel-id target.
|
|
|
|
I don't have a good answer for this one. I'm hoping that it isn't
|
|
sufficiently interesting to attack that it'll be an issue, but I can't
|
|
think of any simple answers. If the API is sufficiently compelling for
|
|
other applications to incorporate Wormhole "technology" into their apps,
|
|
I'm expecting that they'll run their own rendezvous server, and of
|
|
course those apps can incorporate whatever sort of DoS protection seems
|
|
appropriate. For the built-in/upstream send-text/file/directory tools,
|
|
using the public relay that I run, it may just have to be a best-effort
|
|
service, and if someone decides to kill it, it fails.
|
|
|
|
See #107 for more discussion.
|