id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
489	reconsider update-write-enabler plan, allows an attack	warner		"I've been planning to allow clients to respond to a {{{BadWriteEnablerError}}} by assuming the share they're dealing with was migrated from one server to another, and then use the new update_write_enabler() method to fix the write-enabler.

But thinking about it further, this allows a malicious server to use the client as an oracle that will tell it all the write-enablers it wants. It just needs to emit a bogus {{{BadWriteEnablerError}}} with the serverid of its choosing. The client will then attempt to update it by sending both old-enabler and new-enabler. This tells the server what the old-enabler was, i.e. what the write-enabler for the other server is. By repeating this several times, the server can obtain the write-enabler for everything.

This suggests a fix: the update_write_enabler method should accept the hash of the old-enabler, rather than the old-enabler itself.

This needs some more thought.. I don't *think* this gives the malicious server any new authority. Specifically, will server2 accept an update request with the string that server1 was just given? Could the malicious server use this to get enough authority (i.e. hashes of write-enablers) to allow it to convince other servers to update their write-enablers? It might also require a check that prevents update-write-enabler from replacing a write-enabler that is for the current serverid.
"	defect	closed	major	undecided	code-mutable	1.1.0	invalid	newcaps security