[tahoe-dev] What Tahoe-LAFS Reveal to an Attacker

[Patrick R McDonald]

> On Feb 24, 2013, at 5:26, Patrick R McDonald wrote:
>
>> All,
>>
>> Simon's post on a secure OS for Tahoe-LAFS got me thinking.  Let's
>> assume for a moment, an attacker gains root on your node.  What if
>> anything does the attacker gain from your Tahoe-LAFS install?  Does it
>> differ if this is a gateway rather than a regular node?
>>
>> We know the attacker can affect availability of the node, but Tahoe-LAFS
>> has great protections against this.  What about attacks against the
>> confidentiality or integrity parts of Tahoe-LAFS?
>
> Off the top of my head, the attacker gains the ability to:

Kevin, thanks for these.  This has given me a nice starting point.  I have
some further questions below.

> • upload new files to the grid.

So this attack could provide a possible DoS by using up existing space.
(availability)

> • obtain the IP addresses and nicknames of other members of the grid.

Wouldn't an attacker be able to gather this through other mechanisms?  For
example, simple traffic observation should let me know to whom the node is
communicating.  If I recall correctly, Tahoe-LAFS doesn't attempt to mask
with whom it connects. (confidentiality)

> • if the attacker knows a convergence secret (possibly including the empty
> string) in use by some member, determine whether a known file is in the
> grid.

So what measures do we need to take to protect a convergence secret?  Is
there a way to secure these from someone with root access on the machine?
(confidentiality)

> If the node is a storage server, then the attacker can:
>
> • observe (partial) download/upload traffic from other members of the
> grid, including identifying specific files given a known convergence
> secret.

Not to sound ignorant, but does an attacker need root access to a machine
to exploit this?  An attacker can already observe traffic going to and
from the machine without system compromise.  Does exploiting the
convergence secret required system access? (confidentiality)

> • possibly cause reversion of a mutable file's contents (including
> directories), if the attacker can ensure that all nodes having the current
> version are controlled or disabled.

What do you mean by disabled?  Do you mean unavailable for communication
with the compromised node?  Would the attacker simply placing a firewall
block to the other nodes accomplish this? (integrity)

> If the node is a gateway, then the attacker can:
>
> • read and modify the plaintext of all files uploaded or downloaded
> through that gateway. (Modification of immutable files would result in
> observably inconsistent results if the user later uses a different
> gateway.)

(confidentiality and integrity)

> • collect readcaps and writecaps which can then be used to perform normal
> access through non-compromised gateways.

(confidentiality and integrity)

> • fail to renew leases, thus eventually allowing a user's files to be
> actually deleted from the grid.

(integrity and availability)

Looking at the above, compromise of the gateway appears to be the most
severe. It appears, and please correct me if I am, that a compromised
gateway would compromise the confidentiality and integrity of all files
crossing its path.

Lastly, given the list of the above, are these issues fixable within
Tahoe-LAFS under the current scenario (compromised device) or are these
something where we need to deploy a secure OS to prevent the scenario?

Sorry for the twenty questions, this thread and Simon's has got me thinking.

Thanks,
Patrick