describe the effects of the debian SSL bug on Tahoe
[Imported from Trac: page TahoeVsDebianBuggyOpenSsl, version 1]
parent
161fee0949
commit
da99220f25
175
TahoeVsDebianBuggyOpenSsl.md
Normal file
175
TahoeVsDebianBuggyOpenSsl.md
Normal file
|
@ -0,0 +1,175 @@
|
|||
The Debian OpenSSL bug that was announced last week has some effects on
|
||||
Foolscap security, detailed by the Foolscap trac page:
|
||||
|
||||
<http://foolscap.lothar.com/trac/wiki/DebianOpenSslBug>
|
||||
|
||||
Now, what are the consequences for Tahoe?
|
||||
|
||||
In summary: not very severe. Once you've upgraded to the fixed openssl
|
||||
library, the lingering effects of weak keys are (starting with the most
|
||||
severe):
|
||||
|
||||
1. a successful Man-in-the-middle attack could allow the attacker to delete
|
||||
(or roll back) mutable file shares for which they do not have the
|
||||
write-cap.
|
||||
2. clients who were not given the introducer.furl could use a MitM attack to
|
||||
connect to the introducer anyway, and from there get access to storage
|
||||
servers
|
||||
3. clients who were not given a helper.furl could use a MitM attack to
|
||||
connect to (and use) a helper process
|
||||
4. clients who were not given a key-generator.furl could use a MitM attack
|
||||
to connect to (and drain the keys out of) a key generator. This is a DoS
|
||||
attack only.
|
||||
5. attackers could mount a MitM attack between a node and its log-gatherer,
|
||||
allowing the attacker to view the node's logs (which contain no secrets,
|
||||
but which would assist a traffic-analysis attack)
|
||||
|
||||
The only vulnerable component of Tahoe is the Foolscap TubID. All other
|
||||
random numbers are either generated by Crypto++ or by calling os.urandom()
|
||||
(which uses the kernel's /dev/urandom RNG): this includes the AES and RSA
|
||||
keys used for write-caps, and the unguessable swissnums used to grant access
|
||||
to Referenceables.
|
||||
|
||||
Tahoe benefits immensely from its conservative "trust nobody" design: none of
|
||||
the important secrets leave the user's computer. We were somewhat lucky that
|
||||
openssl was not used to generate any of thse important secrets. The remaining
|
||||
problems are described below.
|
||||
|
||||
## Mutable File Share write-secrets
|
||||
|
||||
The authority to modify a mutable file is expressed in its "write-cap", which
|
||||
includes enough information to obtain an RSA private (signing) key. Anyone
|
||||
who can sign shares with the right key will be able to modify the file any
|
||||
way they please.
|
||||
|
||||
These shares are stored on untrusted servers, who could damage or delete them
|
||||
(since there are extensive cryptographic hashes checked on each share,
|
||||
culminating in the RSA signature, damaging a share is equivalent to deleting
|
||||
it). The servers could also "roll back" the share to an earlier state. If
|
||||
enough servers do this, a client could see the file revert back to an earlier
|
||||
version. Rollback is the one way in which the servers can extert a form of
|
||||
"write authority" over a mutable file. Other parties are not supposed to have
|
||||
any such power.
|
||||
|
||||
To reduce storage server workload, and to reduce version dependencies, the
|
||||
servers do not actually check this signature at upload/modify time (clients
|
||||
who are downloading the mutable file are the only ones who check it).
|
||||
Instead, when the mutable file's shares are created for the first time, the
|
||||
original uploader creates a set of "write secrets", one for each server,
|
||||
which are derived from the hash of the write-cap and the server's peerid. The
|
||||
server will accept an update from anyone who can provide the same secret.
|
||||
These secrets are different for each server, so serverA has no authority over
|
||||
a different share of the same file on serverB.
|
||||
|
||||
Since these shared secrets are sent over the Foolscap connection with no
|
||||
further encryption, a successful MitM attack (accomplished against a storage
|
||||
server that uses a Tub certificate generated by the buggy version of OpenSSL)
|
||||
could reveal these secrets to the attacker. This attacker would then get the
|
||||
authority to make changes to those shares. They would be unable to forge
|
||||
valid signatures, so they would be limited to the same deletion-or-rollback
|
||||
attacks that the server could perform. They could only perform these attacks
|
||||
on the servers that had weak Tub certificates.
|
||||
|
||||
## Unauthorized Access To introducer/helper/key-generator
|
||||
|
||||
Several configuration controls use FURLs to provide/limit access to certain
|
||||
grid services. The main one is the introducer.furl : clients use this to
|
||||
contact the Introducer, from which they get access to all storage servers. In
|
||||
the current release, access to the storage servers can be withheld by not
|
||||
publishing the introducer.furl . (we plan to change this: once Accounting is
|
||||
in place, the introducer will be more public, and access to storage servers
|
||||
will be controlled by a signed and authorized private key).
|
||||
|
||||
If the Introducer was created with the buggy version of openssl, its TubID
|
||||
will be guessable. This enables a man-in-the-middle attack between an
|
||||
authorized client and the Introducer, from which the attacker can learn the
|
||||
unguessable swissnum that protects access to the Introducer. A successful
|
||||
attack would thus allow an unauthorized party to connect to the Introducer
|
||||
and therefore use storage services.
|
||||
|
||||
Similarly, access to the Helper and the Key-Generator is enabled/protected by
|
||||
distributing FURLs, and when these FURLs use guessable Tub certificates, an
|
||||
attacker will be able to perform a successful MitM attack against a user of
|
||||
the service. From this, the attacker can learn the swissnum, and thus gain
|
||||
access to the service.
|
||||
|
||||
Unauthorized access to the Helper means the attacker gets to upload files and
|
||||
consume the Helper's CPU time (which may have been intended to be reserved
|
||||
for paying customers).
|
||||
|
||||
The "key generator" is a small process that creates RSA keypairs, intended to
|
||||
offload mutable file creation work from a webapi server. (the RSA key
|
||||
generation process involves 0.5s to 3.0s of blocking CPU time, so the webapi
|
||||
machine's responsiveness to other requests is improved by passing the work to
|
||||
a separate process). It pre-generates a small pool of keys to respond faster.
|
||||
An attacker who uses an MitM attack to gain access to the key generator could
|
||||
request a lot of keys, causing extra CPU load and draining this pool, which
|
||||
would slow down legitimate requests.
|
||||
|
||||
## Log Gatherer
|
||||
|
||||
Tahoe nodes can be configured with a log-gatherer.furl, which directs the
|
||||
node to connect to the given gatherer and offer its "log port". The log port
|
||||
can be used to retrieve stored log messages, and to subscribe to new ones.
|
||||
Grid managers can use this to record verbose information about uploads and
|
||||
downloads.
|
||||
|
||||
If the log-gatherer is using a weak Tub certificate, an attacker could mount
|
||||
a successfuly MitM attack between the node and the gatherer, revealing the
|
||||
swissnum of the node's logport. This would allow the attacker to see the same
|
||||
log messages that the gatherer sees.
|
||||
|
||||
By design, Tahoe nodes do not log secrets. Instead, most upload/download
|
||||
operations refer to the Storage Index of the file being processed, which is
|
||||
public information (storage servers and several diagnostic web pages show the
|
||||
SI values). However, the logs do contain file sizes, and the information
|
||||
therein would be useful to an attacker interested in performing a
|
||||
traffic-analysis attack: it could help them learn who is interested in the
|
||||
same file, or who is downloading a file that someone else uploaded. So, while
|
||||
it does not threaten data confidentiality or integrity, you still wouldn't
|
||||
want to publish logs to the world, which is why the log-gatherer.furl is
|
||||
meant to control how this gets published.
|
||||
|
||||
## Fixing The Problems
|
||||
|
||||
To fix these problems, server operators need to regenerate any Tub
|
||||
certificates that were created while the buggy version of openssl was
|
||||
installed. However, there are several operational problems that may make this
|
||||
more difficult than it sounds.
|
||||
|
||||
* introducer.furl: All clients need to be updated with the new FURL, which may
|
||||
require touching hundreds of client machines. Since the Introducer FURL is
|
||||
the primary entry point, Tahoe does not have a mechanism to automatically
|
||||
update it from some other server.
|
||||
* helper.furl: same problem. Eventually, Helpers will be accessed through the
|
||||
Introducer, but in the current release, the helper is configured by writing
|
||||
to the helper.furl file, so it must be updated as well
|
||||
* storage servers: Storage Server FURLs are distributed through the
|
||||
Introducer, so it would seem straightforward to delete the server's
|
||||
"node.pem" file, restart it, and allow it to generate a new one: the server
|
||||
would connect to the introducer and appear as a brand new server (that
|
||||
happens to have the same shares as it did before).
|
||||
* However, there are two problems that will result if this is done with the
|
||||
current release. The most significant is that clients use shared secrets
|
||||
derived partially from the storage server's TubID. The most important one
|
||||
is the mutable-share write-secret, which allows clients to modify mutable
|
||||
files (including modifying directories). If the storage server's TubID no
|
||||
longer matches the secret that was stored in the share, then clients will
|
||||
get errors when they attempt to modify those shares. In many cases, this
|
||||
will prevent users from modifying their directories.
|
||||
* There are plans to fix this: the error message includes the TubID that was
|
||||
used to generate the secret, so the plan is to add a storage API that
|
||||
allows the client to change the shared secret (by providing both the old
|
||||
one and the new one). This will allow clients to tolerate shares being
|
||||
moved from one server to another, which would be the effect of
|
||||
regenerating the Tub certificate for those storage servers.
|
||||
* The second problem is that the peer selection algorithm would now see
|
||||
shares in non-optimal places. This would look a lot like large-scale
|
||||
churn: shares being moved to random servers, not necessarily the same
|
||||
servers that the node would expect to find them on. The peer selection
|
||||
algorithm is designed to tolerate this, but the effect will be a
|
||||
slowdown: nodes will be looking for their shares in the wrong place, so
|
||||
they'll have to search further than usual, and this will take additional
|
||||
round trips. So changing the server's TubIDs will also affect client
|
||||
download performance. To address this, a file-repair step that moves
|
||||
shares to their ideal locations needs to be written.
|
Loading…
Reference in a new issue