[wp-hackers] [Fwd: Re: Wordpress 1.2.2 is still vulnerable] && Bugs In WordPress

[Brian Puccio]

First off, I am not a real php programmer, I know just enough to get
done what I need done on software packages I use internally, and I just
toy with stuff for fun.  I am no way shape or form bashing WordPress,
its developers, etc.

On Tue, 2004-12-21 at 20:10 -0700, Kitty wrote:
> Was this brought up with the devs before hitting Bugtraq?

> -----Forwarded Message-----
> From: Thomas Waldegger <bugtraq at morph3us.org>
> To: bugtraq at securityfocus.com
> Subject: Re: Wordpress 1.2.2 is still vulnerable
> Date: Tue, 21 Dec 2004 21:56:51 +0000
> 
> In-Reply-To: <20041216062119.9218.qmail at www.securityfocus.com>
> 
> Sry, but it's getting ridiculous.
> 
> The new releases of wordpress - 1.2.2 stable and 
> 
> 1.3-alpha-5 unstable - are still vulnerable for
> 
> some bugs I mentioned in my last message.
> 
> 
> 
> XSS:
> 
> /wp-login.php?action=login&redirect_to=[XSS]
> 
> /wp-admin/templates.php?file=[XSS]
> 
> /wp-admin/post.php?content=[XSS]
> 
> *snip* See parent message for the rest of the issues*
> 
> /wp-admin/post.php?action=edit&post=2890000000000

I've seen this guy's name a few times before with respect to WordPress
insecurities, the first I remember (and have bookmarked) is:

http://www.securityfocus.com/archive/1/376766

That's from way back in September (also, he said he emailed Matt, but
didn't get a response, in Matt's defense, I believe that's when he was
moving to take on his new job.)

Next is:

http://seclists.org/lists/bugtraq/2004/Dec/0193.html

The "if someone moved wordpress, lets detect it" portion was brought up
here:

http://wordpress.org/support/6/17950

Thomas noted that 1.2.2 was released to fix the problems.

Thomas later noted that 1.2.2 didn't fix all of the problems:

http://seclists.org/lists/bugtraq/2004/Dec/0297.html

It seems to me that this guy has quite a knack for finding exploits.
Any of the higher ups (not sure of the hierarchy of WordPress, not sure
who runs what, who has CVS access, etc) ever think of sending him an
email and asking him for some help?

Another note, I've been looking at the bug tracking the past few days,
and I was wondering if people could clarify some things for me.

First, to me, a bug is something that is broke and needs to be fixed
ASAP as it impedes intended functionality of a program.  A feature
request is something WordPress doesn't do now, but someone wants to see
it done.  Clutter up everything with 500 requests for 500 things that
aren't true to WordPress with no one willing to sit down and come up
with a diff to get it done and you've got software going in 500
different directions with no speed.  For instance, all of these:

http://mosquito.wordpress.org/view.php?id=243
http://mosquito.wordpress.org/view.php?id=432
http://mosquito.wordpress.org/view.php?id=450

The first is marked as a minor bug.  To me, this is a feature they want.
WordPress isn't doing anything wrong.  He clearly states WordPress
doesn't let you do it.  That's not a bug, that's a lack of a feature.

The second is a feature request, he wants DST.  Sounds like a good idea,
millions around the world observe it, why not let WordPress handle DST?

The third is marked as a bug, and the author has come across something
WordPress did that wasn't what he expected.  Either the documentation
needs to clarify, or WordPress needs to do what is expected.

But all 3 could be combined into one big fat feature request called
"More Precise Time" where each user on a blog (and hell, each visitor
too, lets store it in a cookie, but leave it as an option for each site)
can set what timezone they are in for their posts to appear in and
whether or not other posts should appear in their native timezone, or in
the readers.  They should also have an option to set if they observe DST
or not, and if they do, the starting and ending dates and times.  That
should cover any issues anyone has with WordPress and time.  (Anyone who
would like to add more could do so to the feature request.  Again, tons
of feature requests and no one submitting patches for the features just
fills a big tracker.)

Second, don't things break in CVS?

http://mosquito.wordpress.org/view.php?id=583

If CVS worked 100% it would be released.  What is the WordPress policy
on filing bugs on versions known to be buggy?  How does the development
community differentiate between a bug in a "stable" version and a bug in
an "unstable" version?

Third, if a bug is set correctly to "feedback" and none is received in 1
month, can the bug be automagically closed?  If someone didn't care
enough to follow up to whomever decided to try to fix the alleged bug,
how is it supposed to be fixed?  (This falls within the link that Matt
posted to the bug tracker on bug submitting netiquette.)  Case in point:

http://mosquito.wordpress.org/view.php?id=197

Fourth, is the bug tracker to be used for plugins as well, if so, can
each plugin be given their own project so we can easily see what
problems are affecting WordPress and what is affecting someone else's
code?  Example:

http://mosquito.wordpress.org/view.php?id=326

A plugin that is incompatible with a CVS version doesn't sound too
surprising to me.

Fifth, if someone posts a solution, than the status should be set to
patch so those with CVS commit privs can submit it.  If the person
doesn't know how to submit a patch, they can learn (that's how I
learned).  (See the previous example bug.)

Sixth, over-exaggerated severity.  Everyone thinks the one bug they've
found is of the utmost importance.  But when a link in the documentation
is deemed major, what would one consider the bugs that Thomas Waldegger
finds?  Majorly Major?  (Maybe we should have a yellow alert, orange
alert sort of system, eh?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : /pipermail/hackers_wordpress.org/attachments/20041221/e40e2704/attachment.bin