[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 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."  If that's
> correct, then essentially you're saying that recipes should be
> able to disable certain markups if they're coming from an
> included page or section, a pagelist template, GroupHeader,
> GroupFooter, page text variable, SideBar, or any other feature
> where we're doing any sort of "templating".

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. This would not have any effect except when deliberately
used by a recipe author, and there, it would be used specifically to
block just these kind of attacks.

> I think that many admins and authors would find such limitations
> to also be confusing and overly constraining -- i.e., I can't
> generate a page containing a ZAP form and then just (:include:)
> it on multiple other pages?  Or certain directives aren't
> allowed to be used in pagelist templates?  Or I can't use
> form processing directives in a SideBar?

It would only be implemented by a recipe author if needed. 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). And of course I'm not saying these
other features cannot be used. It's just PmWiki should offer at least
some kind mechanism to block these kinds of malicious attacks!
Currently it's about impossible...

> So, while this might be a fix, I think it comes with its own
> set of negative issues and confusion for authors/admins that
> are probably best avoided.

How would that be a problem when nothing is changed by default.
You're just providing an opportunity for admins to escape certain
markup to preven this kind of exploit. Nothing else would change...

> All of this is just a way of saying that I think we need
> a different overall solution to the problem here -- i.e.,
> being able to bypass edit to write to *any* page is too
> blunt an instrument for what we're trying to achieve.

I'm open to whatever suggestion you have, but you haven't been very
forthcoming with recommendations . ZAP has many useful features and
PmWiki should make it possible for something like it to be available.
It seems your current position is, there's no way to do what you
want--so forget about it. I'll be happy to pull the recipe--there are
other engines it might work more safely with (Personally I use it on
edit protected sites for all user interaction so it's not a problem
for me). But I think finding a solution for PmWiki users is the better
approach.


In short, as far as I can see, since wiki markup can be imposed on
page authors don't have edit permissions with 1) no way to escape it,
2) no way to flag it, 3) not even a POST or GET value to indicate it's
imposed (these seem to somehow be cleared by PmWiki), unless PmWiki
makes some kind of core change to allow recipe authors to block these
kinds of attacks, it's impossible. Apart from manually having to set
target pages in config files for evey single ZAP form. But Pm that's
unacceptable.

Looking forward to your suggestions...

Cheers,
Dan