[pmwiki-users] ZAP security vulnerability...

[The Editor]

On 5/1/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Tue, May 01, 2007 at 06:26:37PM -0400, The Editor wrote:
> > Pm has been kind enough to study the ZAP code and found a serious
> > security vulnerability.  We are still looking for a solution.
> >
> > Basically the problem is in PmWiki's ability to impose page content
> > from an editable page onto a page that is not editable and load that
> > page as if it were in the source code. You could argue this is a
> > PmWiki vulnerability, (which allow users to insert a ZAPform onto a
> > page they cannot edit) but regardless it will need to be fixed.
>
> Yes, you could argue this is a PmWiki vulnerability.... but
> you'd be wrong.  :-)
>
> Here PmWiki is functioning exactly as it has been designed to
> function, and the features that the ZAP exploit uses do not, on their
> own, impose any security risks to sites not running ZAP.  It's only
> when coupled with a recipe that allows page modifications >>outside
> of PmWiki's normal edit authorizations<< that the potential for
> problems occurs.
>
> Indeed, the features that the exploit is using are arguably
> some of the most popular features in PmWiki at the moment:
>
>    (:include:) templates
>    pagelist templates
>    page text variables
>    group header, group footer
>    <!--wiki: .... -->  in skin templates
>    sidebars, page actions, etc.
>
> So, unless we want to try to "fix" all of these features, I don't
> think we can consider the problem a PmWiki vulnerability.  Instead,
> it appears to be a mistaken assumption on ZAP's part about being
> able to rely on rendered markup (which can come from many sources)
> to authenticate write access outside of the normal page permission
> structure.

I won't argue with you on this as PmWiki is your program and you can
of course decide what is a feature and what is a problem.
Still--making it possible for a user to impose wiki markup on a page
(via a template) for which he has no write permissions seems a glaring
vulnerability to any recipe trying to do anything significant with a
form.  Especially when there's no mechanism for a recipe writer to
escape markup, or modify in any way how that imposed markup is
processed.

I take responsibility for not realizing how flexible PmWiki was and
that it could do this kind of thing. It's a cool feature--but without
a back door for recipe writers it seems a good many recipes could be
exploited exactly the same way--though admittedly, not many to the
extent ZAP could be.

There are several obvious solutions, but all of them in my opinion
seem onerous to the end user.  And I definitely DO want write access
to pages users cannot edit...

1) Set up a custom ZAPwrite permissions (in addition to its ZAPform permissions)
and then require every write function in ZAP to check this permission.
This means an admin would have to manually open the lock on every
potential target page...

2) Set up a ZAPtarget config page (like the current ZAP config page
limiting commands)--and manually identify allowed target pages for
various commands or pages.

3) Simply limit the groups that can be written to in a config
file--like I believe Fox does--which does not really solve the
problem, only minimizes the potential damage. That is, a malicious
user could perhaps create a Fox form very different from that intended
by the admin even if it doesn't have site wide repercussions.

All of these require extreme care and sophistication on the part of
the admin to avoid the possibilities of some strange conbination doing
damage.  Imposing some markup on a page with some zap command enabled,
then using it to paste malicious content to yet another page that has
zap write permissions, then embedding that dangerous script on yet a
third page via a page variable or whatever. Few admins will be able to
sort out all the possible permutations this PmWiki flexibility
allows--no matter how carefully a recipe writer tries to lock its code
up.

I suggested one possible (probably easy) fix off-list that could
provide that back door. Allowing a simple string replacement array to
be processed before doing markup processing on an imposed page.  I
hope you'll consider it...  Or there may be a way to set some kind of
flag or something automatically when markup has been imposed on a
page. Even a config variable that simply allows/disallows forms to be
imposed on another page. I know we're only talking a line or two if
the strategic places could be found in the PmWiki code.  It need also
break no existing wikis.

ZAP can and will be tightened down dramatically as soon as I get some
time, but I believe the only way to have any kind of reasonably
elegant soluton, would be for PmWiki to offer a safety hook for recipe
writers who want to do things with forms. Otherwise the best any of us
could do would reqire significant overhead on the admin, be complex,
and still potentially risky.

Thanks again Pm. Only the highest respect intended by this post in
terms of your wonderful wiki, and your grasp of how it works. Just
reasons why I really think we need a better solution at the core
level.

Cheers,
Dan