[pmwiki-devel] PITS/01030

[DaveG]

Petco,

The way I read this is that you'd need to have authform active, and 
allow people login access, or access to the login form -- which your 
test site doesn't appear to do. From there, we can apparently call the 
login routine and append bogus php command:
   &login_vars..., is_admin()

which will get executed. This page has a info on a similar issue for WP 
http://www.matasano.com/log/1019/funny/. Not exactly the same, but 
should be enough to get started.

In terms of XSS, what could be done is rather than simply executing php 
as above you could force an execution of any remotely hosted cgi script 
on the pmwiki server. Refer: 
http://forum.joomla.org/viewtopic.php?f=267&t=76578&start=150

If you're disputing the 'serious' rating, then I'd probably agree with you.

For a few more similar, but not the same, exploits: 
http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2006-03/msg00093.html

  ~ ~ Dave

Petko Yotov wrote:
> On Wednesday 25 June 2008 16:12:35 Greg T. Grimes wrote:
>> I am fairly new to PmWiki development and bug tracking.  Can someone
>> explain the process of getting this bug fixed?  I see someone "voted" a 5
>> for it, does this mean the person agrees?  Again, I'm new and just
>> wondering.  Thank you.
> 
> Hello,
> 
> I am copying my question to the list:
> 
> How could possibly the current $_SERVER['REQUEST_URI'] variable be a serious 
> cross-site scripting vulnerability for anyone else than the browser which is 
> calling the login form with an invalid url (non-stripped tags...)? What 
> exactly client-side code could be executed?
> 
> Feel free to demonstrate the vulnerability on my wiki which is located at 
> http://galleries.accent.bg/Cookbook .
> 
> Thanks a lot.
> Petko
> 
> _______________________________________________
> pmwiki-devel mailing list
> pmwiki-devel at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
>