[pmwiki-users] ZAP homework assignment...

The Editor editor at fast.st
Fri May 4 12:39:39 CDT 2007


Sorry about the delay in posting a fix to the ZAP security problem's
Pm has exploited, but I decided to revamp several things at the same
time and I have not been in the best situation in some regards while
traveling.

However, I have just about completed my revisions to ZAP's code and
will be posting it momentarily--as a beta-beta on ZAPsite.  I'm giving
it this status because I have not had time to fully debug it, and I
was hoping others might assist with that by testing it out on their
systems. Several complex changes were made and I haven't had time to
debug as thoroughly as I would like so there may be a typo or two
somewhere though it seems to be working well.  (Normally I go through
every snippet on ZAPsite, but don't have time for that just now...)


Homework Assignment

1) First as to the cause of the security vulnerability Pm was exactly
right in his assessment that the cause was ZAP and PmWiki have two
different paradigms for security.  To over simplify it perhaps, ZAP
relied on the security of the page where the ZAP form resided, where
PmWiki relied on the permissions system of the page being written to
being appropriate.

ZAP's first mistake was not realizing just how powerful PmWiki is. In
particular you can impose (display) markup on a page via a template
(fmt) using the search query method in PmWiki--even if the user does
not have edit permissions to that page. I'm not particularly keen on
this feature--and it has been the major obstacle to Pm's development
of a form's processing engine--but it does allow some cool things, and
it's Pm's right to setup PmWiki however he wishes. ZAP needs to adapt,
not PmWiki. And I should have known (somehow) PmWiki could do this.

Using this technique Pm was able to impose a ZAP form on a page (I
assumed was safe) from another page where ZAP was not enabled. It was
an easy hole to fix, and it was certainly unintentional, but ZAP
should have been aware of this vulnerability and protected users
against it--esp as ZAP has chosen to use it's own security paradigm.

2) My initial fix was very rushed and inadequate, as there are
multiple methods within ZAP to accomplish similar purposes. There are
in fact 4 avenues for form submissions in ZAP. When I blocked one, Pm
simply switched to method 2. (using a ZAP input field to set the
ZAPform security variable. Brilliant.). Method four was also probably
vulnerable (link submit forms) but it is blocked now, as well as the
auto submit markup--just to be safe. I suppose I would have caught it
if I hadn't been rushing out the door--but I didn't.  So the initial
fix was a knee jerk temporary fix (announced as such).  The current
release is a bit more deliberate, and the result of a closer
examination of the code, and some time to think about it a bit more.

3) While ZAP should now be impervious to these kinds of attacks (both
exploits were essentially the same), other issues have come to my
mind. First, in the interest of flexibility, ZAP took almost no
precautions to help minimize damage in the events of such an attack.
Perhaps it was just a naive or worse a cocky over-confidence. Fox by
contrast, while conceivably vulnerable to a similar kind of attack had
various default protections set which would have prevented access to
the Site group, and perhaps others. A kind of backup level of
protection, which wouldn't have stopped an exploit--but would have
kept if from giving a malicious attacker the kind of control Pm was
able to get with relative ease in ZAP.

To address this issue, ZAP is now setting a default ban on any access
to Site pages unless explicitly allowed by a config setting. So should
another exploit be found (they are always possible in any software,
even Pm had a tables glitch once months ago), a malicious user can not
do near the kinds of things ZAP was wide open to once it's initial
security armor was pierced.  This should be fixed now in ZAP.

4) Though the specific security hole appears plugged, just to be safe,
another level of ZAP security seemed advisable--especially for sites
mixing ZAP enabled pages with non-ZAP editable pages. That is, as long
as ZAP bypasses PmWiki's security system of verifying edit permissions
before target pages can be written to, something comparable really
should be in place--or the underlying paradigm problem has still not
been addressed. This alone would have pretty much stopped Pm's
exploits cold in its tracks as well.

The system I will be releasing sets up a Site.ZAPCommands (was
ZAPConfig) page and a Site.ZAPTargets page. On the first you can put
lines like:

  edit: Snippets,Test.Main
  insert: Comments,Test.Log

This effectively blocks every significant command in ZAP unless
specifically unlocked for a page or group. To help those learning the
system a special warning message is given pointing out the problem.

On the second page you will find something like the following:

  Snippets_Array: Snippets.Array
  Forum_Comments: Comments

This will allow a form on the Snippets.Array page to write to itself
(regardless of the command used), but no where else.  Likewise the
Forum.Comments page can write to any page in the Comments group, but
nowhere else.  Where not set properly a warning message is given so
the admin can unlock the target location for the intended action.

It may still need some tweaking however to allow things like groups to
write to themselves or perhaps other groups. Or patterns. Or
pageshortcuts...  Maybe other options. I'm open to suggestions for
code that would make it more versatile. Also to feedback from other
users on how much this hinders them. It seems a bit onerous--and
maybe, a bit of overkill. But it does a lot to solve the security
problem. Or more accurately, the paradigm problem.

NOTE:  as ZAP is still reasonably secure on closed systems where all
editing and form interaction is done through ZAP rather than PmWiki,
these precautions only go into effect when the corresponding Site page
exists. So if your system is closed (or using a closed farm field for
ZAP stuff), don't create either page and you have wide open access to
ZAP's power. If your system is open to editing, create these two pages
(blank) and your entire site is instantly locked down. You would
probably even be reasonably safe enabling ZAP on editable pages in
this kind of setup (not recommended) as there would only trivial
commands available to the editor.

5. The final issue I want to mention is the problem of ZAP's
documentation. ZAP has taken security seriously from the beginning and
taken a number of good measures. It also made no boast that was not
true to the best of my knowledge at any time. Just the same--it would
have been wiser to acknowledge security holes are always possible and
with something as powerful as ZAP special precautions should be taken
(such as closing edits to potentially included pages). I can't point
to specific problems in the documentation but I do intend to
re-examine ZAP's documentation/security tutorials and where
appropriate rewrite the content to convey a more pragmatic tone. I
think one of Pm's big concerns was the documentation not accurately
warning against potential risks.  The risks are fewer now, but the
warnings will be increased!

I'll be releasing the new version of ZAP hopefully within the next
hour--pending feedback to this post.

Cheers,
Dan



More information about the pmwiki-users mailing list