[pmwiki-users] ZAP security vulnerability...

The Editor editor at fast.st
Wed May 2 15:44:07 CDT 2007


On 5/2/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Wed, May 02, 2007 at 05:09:04AM -0400, The Editor wrote:
> > On 5/1/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> > >On Tue, May 01, 2007 at 08:02:01PM -0400, The Editor wrote:
> > >> 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'm not sure exactly what you mean by "imposed page", but
> > >it sounds as though you mean "any page where the markup is
> > >coming from somewhere other than the current one."

Let's think in terms of the analogy of push and pull.  If I do an
include, or a PTV, etc, I'm retrieving markup from other pages onto
the page I'm editing.  That's pull. I must have edit permissions to
insert the code on a page, so it should be allowed.

If I use the query string and "impose" markup on a page I don't have
edit permissions for, that's a bit different. That's push.  And as you
demonstrated so coolly (I admit, I was impressed) it allows for
exploits. I suspect a vast number of recipes are vulnerable to this
approach--just don't know it, or only with limited damage potential
(unlike ZAP).  It's these push kinds of things I'm worried about in a
general kind of way...

I note Fox just updated its default security settings 4/21/07 to
protect against this, though it does have several other very useful
features to limit potential risk.

> > I'm not even talking about disabling markup.  Only a way to run some
> > kind of escape function. Like define a configurable str_replace (zap,
> > zaap) or whatever that is run just before the markup--perhaps only
> > when a user doesn't have write permission to the page that markup is
> > imposed on.
>
> I'm afraid I don't understand what you're saying here.  I understand
> the notion of "escape function", but I don't understand exactly
> when you're wanting it to be run.  In particular, what do you mean
> by "just before the markup" and "when a user doesn't have write
> permission to the page..."  (which user?)

You know the code much better than me, but I think there probably
should be a hook for recipes to insert an extra step for these kinds
of things. So whatever functon you call to process sections of a page
now has one extra step of doing an optional str_replace on the content
it's about to render. The main page could skip this step.

The result is I could substitute zap in the markup to zaap or whatever
which would have kept all markups from processing. So this kind of
exploit would then be impossible.

And again this is only really necessary in push kind of functions, not
pull ones like groupheaders and footers, sidebars, etc.  Of course, as
we've got another seeming fix, this may not be necessary...

> If you're just wanting a markup rule to be fired at the beginning
> of markup processing, then just use '<_begin' as the $when parameter
> to Markup().  That rule will then be executed before any other
> markup rule.

This won't work because it will then invalidate the needed markup on
the main page.  There needs to be a way to distinguish between the
main page, and anything imposed on it from another page, as you did.

> If you're wanting to have a set of pattern replacements performed
> on text coming from (:include:) or the pagelist fmt= parameter,
> then $QualifyPatterns is what you want.  For example:
>
>    $QualifyPatterns['/\\(:zap .*?)/e'] = "Keep(PSS('$0'))";
>
> will cause all (:zap ...:) directives coming from an
> include directive or pagelist template to be escaped.
> But in this last case, as I said before...
>
> > >I think that many admins and authors would find such limitations
> > >to also be confusing and overly constraining ...

Well this may be exactly what we need. What would be the problem of
just adding that line to the ZAP recipe?  Can you think of any
possible negative ramifications? Sounds like exactly what I was
thinking...

All I need to do to block ZAP from being exploited is somehow keep the
zapform directive from doing its thing...  I suspect this could handle
that nicely...

> > [...] I'm just
> > saying there should be a mechanism for this available for people
> > wanting to do anything like this (any kind of forms processing in
> > PmWiki is vulnerable to this).
>
> I disagree that "any kind of forms processing in PmWiki is vulnerable
> to this".  Only those kinds of forms processing that that rely on
> the rendering engine for authorization and seek to bypass PmWiki's
> edit permissions are vulnerable.

I understand what you are saying.  I should have clarified that I mean
any forms processing that can allow users to do anything interesting
on pages they don't have edit permissions for.  You may like all your
stuff open--that's wiki-ish.  But I don't really want any old logged
in user being able to edit and mess around with my forum pages, say.

As noted above Fox was designed to work the same way also until that
latest release. But it did have several other good security
precautions built in

> > I'm open to whatever suggestion you have, but you haven't been very
> > forthcoming with recommendations .
>
> As I've said before, I don't have a good answer or
> recommendation for this, and I've been looking at the problem
> for *months* [1].  If that's "not being very forthcoming with
> recommendations" (i.e., because I don't have any), I apologize.
> It's not from a lack of trying.

No apology needed.  The solution I finally came up with was an obvious
one--should have thought of it instantly (actually I did but goofed
the testing and ended up thinking it didn't work).  And it does seem
effective.  Maybe it's all we *need*.  Just the same, I will
definitely set up an optional target config page and by default block
all access to Site pages. That was a careless move on my part--or
probably over confidence.  A good lesson.

Probably will release next week, perhaps at the same time I overhaul
ZAP's messaging system to make it more configurable and friendly to
i18n.

> I did recommend that we need to come up with a
> better overall solution to bypassing edit permissions [2].

Personally, I'm not too keen on the idea of having to pre-insert some
markup on a target page to make it writeable.  Effective perhaps, but
very limiting. And what do you do with forums, etc., where new pages
are created all the time? I'm sure you've thought this through so I'm
not second guessing you.  But it seems yucky.  I think I'd rather
figure out ways to close remaining security vulnerabilities and go
with something more like ZAP.

> I am trying to be helpful, but you're not really answering the
> questions that would help me to come up with an answer for you.

Looking at this list you gave before, all but pagelist templates and
perhaps page actions are pull.  In other words you can only get markup
rendered for that page if you can first edit the page and put
something on it to pull in the markup.  Pagelist templates and perhaps
actions can be used to impose markup that is rendered as if on the
page via a get or post variable. So the focus to me, seems is here.
After all, if it's not triggered from within a page markup, it must be
triggered by a get/post value...  Correct?

   (:include:) templates
   pagelist templates
   page text variables
   group header, group footer
   <!--wiki: .... -->  in skin templates
   sidebars, page actions, etc.

Are there any other actions that could "impose" markup?  I don't won't
to rule out every get variable but want to make sure the net I spread
(checking for q=) is wide enough...

Cheers,
Dan



More information about the pmwiki-users mailing list