On 5/1/07, Patrick R. Michaud <[EMAIL PROTECTED]> 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 _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users