All we have to do to have reasonably secure plugins on Freenet:
- Each plugin has its own client-cache.
- Any request which is satisfied from this cache takes 2.0-2.5 seconds
(randomized).
- Any request which is satisfied from the local datastore, or from the
network, takes precisely 30-35 seconds (randomized).
- The above may be subject to load issues. Presumably we can allow each
plugin a request every X seconds... We may need to up them to deal
with load.
- The plugins are allowed to access the clock, and even to persist a
certain amount of data.
- The plugins cannot figure out which node they are on by timing
requests. The delays above are implemented at the level of
client.async; we do not add in delays after the fetch (as this might
introduce vulnerabilities via updatable keys).
- The plugin CAN identify the time of day when it is used. This is
obviously a serious vulnerability, but there are some relatively easy
mitigations, and it exists even in e.g. Freemail or posting freesites;
it is not unique to plugins. All we can do is warn people about
intersection attacks and recommend they run their nodes 24x7.
- The plugin can maybe identify fluctuations in the system load
depending on time of day, but this is difficult due to the above
randomizations. It may well still be possible, but would probably
require correlation over a long period.
- If the plugin has any access to the time of day - and it will, because
of updatable keys, even if we disable the clock - and if it has either
threading or asynchronous requests - then it will be able to count up to
a big number while waiting for the time to change. This will allow it
to estimate the CPU speed and the system load, over time. The counter
to this is to not allow the plugin to access the clock at all (with
a custom loader which always returns the startup time). This will
limit functionality a bit but should be ok for web plugins. If we then
don't allow the client threading, but in order to maximize
functionality we do allow it to do a fetch of a whole batch of keys at
once, (with no callbacks until the request is completed!), then it
should be possible to prevent this attack too. Except in its most
gross form, of counting up to a REALLY big number and then doing a
request to determine the time. That remains possible in theory, but
not very practical for a web plugin without threads, as it has to
return a value to the user at some point!
- Users can do a good deal to avoid this; they can for example run the
plugin on a separate machine from the one which does the daily backup
job. And plugins which block forever should be suspect, but in any
case users are unlikely to use them enough for them to gather useful
data.
- We warn users about the remaining security issues. Obviously the only
way to be totally sure a plugin is safe is to have a large community
of people inspect its source code, but I suspect we can produce
something which gives a reasonable level of confidence.
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20060218/d969c3c2/attachment.pgp>
