On Sat, Feb 18, 2006 at 10:47:33PM +0100, freenetwork at web.de wrote: > uhm, this isn't all too clear for me, so i'll ask some questions: > > >All we have to do to have reasonably secure plugins on Freenet: > >- Each plugin has its own client-cache. > > ack, makes sense to keep plug-ins away from each other > > >- Any request which is satisfied from this cache takes 2.0-2.5 seconds > > (randomized). > > why? > > >- Any request which is satisfied from the local datastore, or from the > > network, takes precisely 30-35 seconds (randomized). > > why? having fproxy wait another half minute for displaying something is not > all too good imho. what's the reasoning for this?
Doesn't apply to Fproxy. Only to plugins. Although it's conceivable that there might be similar attacks in future using fproxy... but I doubt it, at least not until we have inverse passive requests/2 level lookup. The point is that if plugins can time requests for different keys they can determine where the node is on the network, and the contents of the datastore. > > >- 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. > > can system.currenttimemillis() be protected from access? i don't know of > this... why anyway? I believe it is possible but it is difficult. > > >- 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. I'm sorry, this is unclear: There are two threats from knowing the time: 1. Measuring time taken by a request. See above. 2. Measuring system load at a given time of day. This can then be correlated: e.g. a backup script runs at 12:00 on weekdays. There is a third attack: classic intersection. If it is possible to say "Content of Evil is always up from precisely 1AM to 2AM on a Friday, except for the 31st", this can tell us a great deal (if we have surveillance on a number of nodes, for example, we can correlate their uptime with his uptime). Unfortunately this exists with *ALL* anonymous traffic. It's one of the big reasons why non-real-time traffic is much safer than real-time traffic. IRC for example is very vulnerable to this. So is insertion of freesites. There are ways to mitigate it but it is a powerful attack. > > i think nearly all plugins need to know what the time is, and might it be for > internal timed events or benchmarking > > >- 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. > > it's not too serious imho. If we tell the user about the risk, then it's not such a serious issue. > > end of the line is - if i allow a program to run on my computer i give very > much control to it. so the consensus is, if i allow a fred-plugin to run on > my node i must trust it just as same as an standalone program. i mean - the > plugins have to be manually installed, or not? frost > and fuqid are widely used and have many rights on the computer I'm talking about secure plugins here. Things akin to java applets. > > >- 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. > > who develops these plugins? > one should only plugins that come from a creditable source. people who don't > respect safety simply CAN'T be helped... What I am suggesting here is that we should look into the possibility of having a plugin sandbox, so that plugins can be used without having to have total trust. -- 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/20060220/df6296d9/attachment.pgp>
