[pmwiki-devel] ZAP farms: a modest proposal for security

Patrick R. Michaud pmichaud at pobox.com
Thu May 3 12:05:50 CDT 2007


On Thu, May 03, 2007 at 11:02:26AM -0500, Ben Stallings wrote:
> I got to thinking yesterday about the ZAP vulnerability, both the 
> exploit Pm has demonstrated fully and the one he's alluded mysteriously 
> to as a homework assignment for Dan.  ;-)

Dan and I have since corresponded off-list on the 'homework assignment'.
I'll post the answer in a followup thread.

> [...]
> Pm is coming from the assumption that the wiki's edit function is open 
> to anyone, at least somewhere on the site (e.g. the WikiSandbox), and 
> that all page edits, without exception, pass through that function and 
> its accompanying safeguards.  

I think this overstates my assumption a bit, at least the part about
"open to anyone".  To me, "open to anyone" has the connotation of
being a public wiki where anyone can edit, such that a wiki administrator
might think "oh, all of my pages have edit passwords on them, so I'm
safe."

But the problem isn't strictly one of "do all of the pages have edit
passwords on them", but rather "can you trust everyone who has 
permission to edit somewhere on the site"?

There are some contexts (I come from an educational context),
where all of the pages are protected from editing by the general
public, but we give edit authorization to other people such as 
students or faculty.  But just because we trust those people to 
be able to edit select group of (password-protected) pages
doesn't necessarily mean we want to trust them with access to
every page on the site.

So, to try to put this succinctly, I think the main difficulty I see
with ZAP's current design is that it effectively collapses the 
distinction between PmWiki's "edit" and "admin" permissions.
Anyone that is authorized to edit a ZAP-enabled page, or
something that is being accessed from a ZAP-enabled page, can
thereby use ZAP to affect _any_ page on the site.  

More directly:  Everyone that has the ability to affect a
ZAP-enabled page has to be treated as though they have a
site admin password.

To give a real-world example, suppose I have a wiki where
each student is given his/her own (protected) wikigroup, in
which they can create and edit pages.  Students are also given
the ability to embed a ZAP comment form so that visitors can
add comments on the pages they write.  Because of ZAP's current 
design, the student authors can exploit ZAP to modify pages 
in other students' groups, or anywhere on the site.  

Speaking as an author, if I put a read password on a page that
I write, I generally expect that it will be protected from
other authors on the site who don't know the password.

So, in many places we're not just trying to protect the site from
the untrusted public, we're also wanting to protect one group
of authorized editors from another.  ZAP currently doesn't
seem to allow that sort of distinction.  

> ... Apologies if I've misstated either philosophy.

No apology needed ... I totally agree that this is a difficult
issue to discuss with precision.  :-)

> So here's my question: would any of these exploits -- including the ones 
> only mysteriously alluded to -- be possible if ZAP were only installed 
> on a wiki farm field, separate from the publicly-editable part of the 
> wiki?  If not, it seems like a wiki could safely use both editing 
> philosophies by isolating each from the other in its own farm field. 
> Part of the site would use the wiki's edit function exclusively, and the 
> other part would use ZAP exclusively as its public face, and they could 
> share a skin and otherwise be unobtrusively integrated with each other.

As far as I know, the ZAP exploits are limited only to the wiki (field)
in which ZAP is enabled -- it doesn't spread to other wikis in a farm.

But, I think that for the situation I described above, where we want
authors to be able to use ZAP features but still have a need to
protect them from each other, the outcome of this suggestion would
be that each author (or each partition of authors that can trust
each other) would therefore need its own field.  That's probably
workable to some extent, but I don't think it's what most people
expect.

Lastly, to hopefully avoid some confusion... I'm not at all 
intending to claim that "ZAP is bad and therefore nobody 
should be using ZAP."  I'm simply saying that as it's
currently implemented, one has to be extremely careful
about who is allowed to edit pages and who is not.  And
one can not rely solely on PmWiki's security features, 
because it's intimately tied to how/where ZAP is enabled
on the site.

Hope this helps,

Pm



More information about the pmwiki-devel mailing list