wordpress can be subject of delayed attacks via cookies

Debian Bug report logs - #504771
wordpress can be subject of delayed attacks via cookies

Toggle useless messages

Message #3 received at submit@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <atomo64@gmail.com>

To: submit@bugs.debian.org

Subject: wordpress can be subject of delayed attacks via cookies

Date: Thu, 6 Nov 2008 20:36:59 -0600

[Message part 1 (text/plain, inline)]

Package: wordpress
Version: 2.0.7-1
Severity: grave
Tags: security

Hi,

Due to the completely incorrect usage of $_REQUEST almost all over the place 
wordpress is subject to delayed attacks via cookies.

The attack can be performed as long as there is some way to inject a cookie 
which is sent by the browser to the server. Note that this means that some 
XSS vulnerability in wordpress or in any other service, or even by visiting a 
malicious site under the same domain could lead to any of the following (and 
even lots more) attacks.

Attack: Denial Of Service
Required cookies: GLOBALS=<anything>
Triggering file: index.php (just an example, basically any file including the 
affected file)
Affected file: wp-settings.php
Effect: no request is processed as it aborts because of the presence of 
GLOBALS in $_REQUEST

Attack: Deletion of users
Required cookies: action=dodelete, delete_option=delete, users[]=n (where n is 
an integer)
Triggering file: wp-admin/users.php
Affected file: wp-admin/users.php
Note: this doesn't affect etch's version as it correctly uses $_POST

Attack: Denial Of Service
Required cookies: action=logout
Triggering file: wp-login.php
Affected file: wp-login.php
Effect: redirection loop, preventing the user from logging in

etc

Cheers,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 504771@bugs.debian.org (full text, mbox, reply):

From: Thijs Kinkhorst <thijs@debian.org>

To: 504771@bugs.debian.org

Cc: Raphael Geissert <atomo64@gmail.com>

Subject: not a critical issue

Date: Fri, 7 Nov 2008 09:31:44 +0100

[Message part 1 (text/plain, inline)]

Hi,

I don't think this is a grave security issue. It is only a DoS for one client 
application, which requires another vulnerability to be present, can be 
easily resolved by deleting the relevant cookies, and does no other harm. As 
there are many ways to DoS (web)applications and the impact is small I 
suggest to downgrade the severity to normal.

It would be good to fix the bug of course.


Thijs

[Message part 2 (application/pgp-signature, inline)]

Message #13 received at 504771@bugs.debian.org (full text, mbox, reply):

From: Andrea De Iacovo <andrea.de.iacovo@gmail.com>

To: Raphael Geissert <atomo64@gmail.com>, 504771@bugs.debian.org

Subject: Re: Bug#504771: wordpress can be subject of delayed attacks via cookies

Date: Fri, 07 Nov 2008 09:36:10 +0100

[Message part 1 (text/plain, inline)]

> Package: wordpress
> Version: 2.0.7-1
> Severity: grave
> Tags: security
> 
> Hi,
> 
> Due to the completely incorrect usage of $_REQUEST almost all over the place 
> wordpress is subject to delayed attacks via cookies.
> 
> The attack can be performed as long as there is some way to inject a cookie 
> which is sent by the browser to the server. Note that this means that some 
> XSS vulnerability in wordpress or in any other service, or even by visiting a 
> malicious site under the same domain could lead to any of the following (and 
> even lots more) attacks.
I agree that the problem exists but I don't think it's a grave one. 
As you said, before exploiting wordpress we need to inject a maliciuos
cookie and if we can do such things I really don't think the problem is
going to be wordpress.

At the moment there are no known XSS isues for wordpress (in lenny/sid
and experimental) so I think the problem really applies to etch only
(for which we still have CVE-2008-2068 and CVE-2007-4483).

At the moment the entire wordpress structure is base on the use of
$_REQUEST and this is obviously one of the worst errors developers could
do; the changes to apply to get rid of this bad use of $_REQUEST are
really important so I don't think I should do something without the help
of upstream developers.

As soon as the CVE gets confirmed I'll file a bug upstream asking to
modify wordpress to use $_GET $_POST and $_COOKIES.

Thank you very much for reporting this.

Cheers.

Andrea De Iacovo

[signature.asc (application/pgp-signature, inline)]

Message #18 received at 504771@bugs.debian.org (full text, mbox, reply):

From: "Raphael Geissert" <atomo64@gmail.com>

To: "Thijs Kinkhorst" <thijs@debian.org>

Cc: 504771@bugs.debian.org

Subject: Re: not a critical issue

Date: Fri, 7 Nov 2008 13:34:43 -0600

Hi,

2008/11/7 Thijs Kinkhorst <thijs@debian.org>:
> Hi,
>
> I don't think this is a grave security issue. It is only a DoS for one client
> application, which requires another vulnerability to be present, can be

It is not just about the DoS (because as I demonstrated, there are
other possible attacks).
The whole point is that wordpress' (ab)use of $_REQUEST is leading to
more and more possible attacks (as I also demonstrated by showing how
etch's version is less worst than lenny's).

> easily resolved by deleting the relevant cookies, and does no other harm. As

Yes, but it only applies to some cases. The users deletion attack can
only be noticed a) if you are paranoid and check the cookies before
you log in, b) when you wonder why wordpress says it deleted some
users without even asking you when all you did was take a look at the
users administration page!

> there are many ways to DoS (web)applications and the impact is small I
> suggest to downgrade the severity to normal.

I do really believe it deservers to be considered as critical;
although if you (or anyone else from the team) really insists I would
not accept anything below important. Think about web hosting services
where they share the same domain but use a different subdomain, it is
possible for one site to inject cookies that will affect the others.

There are many other possible attacks via cookies, I only reported the
first ones I found via a quick grep on the source code.

>
> It would be good to fix the bug of course.
>

bug*s*, and make sure upstream gets the "please stop using $_REQUEST!" message".

>
> Thijs
>

Cheers,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net

Bill Vaughan  - "The tax collector must love poor people, he's
creating so many of them."

Message #23 received at 504771@bugs.debian.org (full text, mbox, reply):

From: "Raphael Geissert" <atomo64@gmail.com>

To: 504771@bugs.debian.org

Subject: Re: Bug#504771: wordpress can be subject of delayed attacks via cookies

Date: Fri, 7 Nov 2008 13:47:28 -0600

2008/11/7 Andrea De Iacovo <andrea.de.iacovo@gmail.com>:
>> Package: wordpress
>> Version: 2.0.7-1
>> Severity: grave
>> Tags: security
>>
>> Hi,
>>
>> Due to the completely incorrect usage of $_REQUEST almost all over the place
>> wordpress is subject to delayed attacks via cookies.
>>
>> The attack can be performed as long as there is some way to inject a cookie
>> which is sent by the browser to the server. Note that this means that some
>> XSS vulnerability in wordpress or in any other service, or even by visiting a
>> malicious site under the same domain could lead to any of the following (and
>> even lots more) attacks.
> I agree that the problem exists but I don't think it's a grave one.
> As you said, before exploiting wordpress we need to inject a maliciuos
> cookie and if we can do such things I really don't think the problem is
> going to be wordpress.
>
> At the moment there are no known XSS isues for wordpress (in lenny/sid
> and experimental) so I think the problem really applies to etch only
> (for which we still have CVE-2008-2068 and CVE-2007-4483).

Think about this situation:
You have a blog hosting account at domain.tld, they provide you a
subdomain called 'myblog' (i.e. myblog.domain.tld). Other folks just
like you do also have their blogs or websites or they whatever hosted
by domain.tld (anotherblog.domain.tld, www.domain.tld,
myshop.domain.tld, etc).
If any of those many sites has a an XSS vulnerability, or anything
else that could lead to the injection of a cookie for the
'.domain.tld' domain *everyone* would be affected.

>
> At the moment the entire wordpress structure is base on the use of
> $_REQUEST and this is obviously one of the worst errors developers could
> do; the changes to apply to get rid of this bad use of $_REQUEST are
> really important so I don't think I should do something without the help
> of upstream developers.

Sure

>
> As soon as the CVE gets confirmed I'll file a bug upstream asking to
> modify wordpress to use $_GET $_POST and $_COOKIES.

Please do not wait.

>
> Thank you very much for reporting this.
>
> Cheers.
>
> Andrea De Iacovo
>

Cheers,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net

Chris Rock  - "You don't pay taxes - they take taxes."

Message #28 received at 504771@bugs.debian.org (full text, mbox, reply):

From: Andrea De Iacovo <andrea.de.iacovo@gmail.com>

To: Raphael Geissert <atomo64@gmail.com>, 504771@bugs.debian.org

Cc: Thijs Kinkhorst <thijs@debian.org>

Subject: Re: Bug#504771: not a critical issue

Date: Fri, 07 Nov 2008 22:08:34 +0100

[Message part 1 (text/plain, inline)]

> Hi,
> 
> 2008/11/7 Thijs Kinkhorst <thijs@debian.org>:
> > Hi,
> >
> > I don't think this is a grave security issue. It is only a DoS for one client
> > application, which requires another vulnerability to be present, can be
> 
> It is not just about the DoS (because as I demonstrated, there are
> other possible attacks).
> The whole point is that wordpress' (ab)use of $_REQUEST is leading to
> more and more possible attacks (as I also demonstrated by showing how
> etch's version is less worst than lenny's).

All attacks can be done only by setting malicious cookies.
With a standard apache/php configuration, cookies can only be set for
the current subdomain (foo.bar.com) and not for the entire domain
(.bar.com).
However you can act on the php.ini changing the domain value with a php
script but I don't think that's wordpress' fault if the server
administrator allows you to dinamically change such configuration with a
simple script! 99% of the public hoster which give you a
yourname.hoster.com do not allow you to change the domain value for the
cookies and so should people do if hosting multiple websites with teir
debian machine.

> I do really believe it deservers to be considered as critical;
> although if you (or anyone else from the team) really insists I would
> not accept anything below important. Think about web hosting services
> where they share the same domain but use a different subdomain, it is
> possible for one site to inject cookies that will affect the others.

As I said if they allow such dangerous practises as dinamic change of
php.ini values that's not wordpress' fault.
You can exploit almost every web application overwriting it's cookies!

Cheers.

Andrea.

[signature.asc (application/pgp-signature, inline)]

Message #33 received at 504771@bugs.debian.org (full text, mbox, reply):

From: "Raphael Geissert" <atomo64@gmail.com>

To: 504771@bugs.debian.org

Cc: "Thijs Kinkhorst" <thijs@debian.org>

Subject: Re: Bug#504771: not a critical issue

Date: Fri, 7 Nov 2008 15:36:15 -0600

2008/11/7 Andrea De Iacovo <andrea.de.iacovo@gmail.com>:
>> Hi,
>>
>> It is not just about the DoS (because as I demonstrated, there are
>> other possible attacks).
>> The whole point is that wordpress' (ab)use of $_REQUEST is leading to
>> more and more possible attacks (as I also demonstrated by showing how
>> etch's version is less worst than lenny's).
>
> All attacks can be done only by setting malicious cookies.
> With a standard apache/php configuration, cookies can only be set for
> the current subdomain (foo.bar.com) and not for the entire domain
> (.bar.com).

Being one of the folks working on the php5 package lately I don't know
of any such apache or php configuration that restricts the domain of a
cookie. PHP has session.cookie_domain, but it does only work for the
session cookies of PHP's built-in session manager.

> However you can act on the php.ini changing the domain value with a php
> script but I don't think that's wordpress' fault if the server
> administrator allows you to dinamically change such configuration with a
> simple script! 99% of the public hoster which give you a
> yourname.hoster.com do not allow you to change the domain value for the
> cookies and so should people do if hosting multiple websites with teir
> debian machine.
>

You can also set cookies via javascript code, e.g.
<script>document.cookie = "GLOBALS=1;domain=.domain.tld"; </script>

>> I do really believe it deservers to be considered as critical;
>> although if you (or anyone else from the team) really insists I would
>> not accept anything below important. Think about web hosting services
>> where they share the same domain but use a different subdomain, it is
>> possible for one site to inject cookies that will affect the others.
>
> As I said if they allow such dangerous practises as dinamic change of
> php.ini values that's not wordpress' fault.

Invalid argument for both reasons: a) there's no such directive in
php.ini b) if there were such a directive, it would have a security
exception just like for magic_quotes, safe_mode, and other b0rken by
design options.

> You can exploit almost every web application overwriting it's cookies!

The problem here is that a) they have predictable names, b) they are
not just storing data but actually making the script do something it
was not requested to do (cookies, just like GET and POST request
methods, have some specific purpose. $_REQUEST should only be used
where it doesn't matter at all what kind of request it is, IOW:
never).

>
> Cheers.
>
> Andrea.
>

Cheers,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net

J. Paul Getty  - "The meek shall inherit the Earth, but not its mineral rights."

Message #38 received at 504771@bugs.debian.org (full text, mbox, reply):

From: Andrea De Iacovo <andrea.de.iacovo@gmail.com>

To: Raphael Geissert <atomo64@gmail.com>, 504771@bugs.debian.org

Cc: Thijs Kinkhorst <thijs@debian.org>

Subject: Re: Bug#504771: not a critical issue

Date: Sat, 08 Nov 2008 00:09:31 +0100

[Message part 1 (text/plain, inline)]

Il giorno ven, 07/11/2008 alle 15.36 -0600, Raphael Geissert ha scritto:
> 2008/11/7 Andrea De Iacovo <andrea.de.iacovo@gmail.com>:
> >> Hi,
> >>
> >> It is not just about the DoS (because as I demonstrated, there are
> >> other possible attacks).
> >> The whole point is that wordpress' (ab)use of $_REQUEST is leading to
> >> more and more possible attacks (as I also demonstrated by showing how
> >> etch's version is less worst than lenny's).
> >
> > All attacks can be done only by setting malicious cookies.
> > With a standard apache/php configuration, cookies can only be set for
> > the current subdomain (foo.bar.com) and not for the entire domain
> > (.bar.com).
> 
> Being one of the folks working on the php5 package lately I don't know
> of any such apache or php configuration that restricts the domain of a
> cookie. PHP has session.cookie_domain, but it does only work for the
> session cookies of PHP's built-in session manager.

Ok I was misinterpreting a man page.

> 
> > However you can act on the php.ini changing the domain value with a php
> > script but I don't think that's wordpress' fault if the server
> > administrator allows you to dinamically change such configuration with a
> > simple script! 99% of the public hoster which give you a
> > yourname.hoster.com do not allow you to change the domain value for the
> > cookies and so should people do if hosting multiple websites with teir
> > debian machine.
> >
> 
> You can also set cookies via javascript code, e.g.
> <script>document.cookie = "GLOBALS=1;domain=.domain.tld"; </script>

ok that's true.

So let's see what we have:
1. $_REQUEST references are widely used in wordpress.
2. the standard EGPCS makes cookies overwrite GET and POST values in
$_REQUEST
3. such values are used in "dangerous" cases (such as user deletion or
logout after redirection).
4. "grave" data loss (user, post, comments deletion) could be avoided
not logging in as administrator (but only as a user with some
privileges)
5. the issue is related to wordpress only and does not influence other
parts of the system
6. we can try to prepare a workaround while we wait an officile fix from
upstream: maybe I could implement a function to check out if dangerous
cookies are present and stop any other operation until those cookies are
not removed.

So I agree that I absolutely have to solve the bug(s) but I keep
thinking it should be set as important instead of grave.

Thank you very much for all your help with the issue.
If you need more information just ask me, please.

Cheers.

Andrea

[signature.asc (application/pgp-signature, inline)]

Message #43 received at 504771@bugs.debian.org (full text, mbox, reply):

From: "Raphael Geissert" <atomo64@gmail.com>

To: 504771@bugs.debian.org

Cc: "Thijs Kinkhorst" <thijs@debian.org>

Subject: Re: Bug#504771: not a critical issue

Date: Fri, 7 Nov 2008 17:31:42 -0600

2008/11/7 Andrea De Iacovo <andrea.de.iacovo@gmail.com>:
> Il giorno ven, 07/11/2008 alle 15.36 -0600, Raphael Geissert ha scritto:
>>
>> You can also set cookies via javascript code, e.g.
>> <script>document.cookie = "GLOBALS=1;domain=.domain.tld"; </script>
>
> ok that's true.
>
> So let's see what we have:
> 1. $_REQUEST references are widely used in wordpress.
> 2. the standard EGPCS makes cookies overwrite GET and POST values in
> $_REQUEST
> 3. such values are used in "dangerous" cases (such as user deletion or
> logout after redirection).
> 4. "grave" data loss (user, post, comments deletion) could be avoided
> not logging in as administrator (but only as a user with some
> privileges)

All fine, although 4 is more a social than a technical problem, as
there is no way we can force users to do that (although I definitely
agree that it is a way to mitigate many possible issues).

> 5. the issue is related to wordpress only and does not influence other
> parts of the system
> 6. we can try to prepare a workaround while we wait an officile fix from
> upstream: maybe I could implement a function to check out if dangerous
> cookies are present and stop any other operation until those cookies are
> not removed.

You better not, that's how the GLOBALS DoS work.

>
> So I agree that I absolutely have to solve the bug(s) but I keep
> thinking it should be set as important instead of grave.

But please do work with upstream so the changes actually take place up there.
Like I said to Thijs: although I do believe that the whole situation
makes it a critical issue, I am ok if the consensus turns out to be
that it isn't critical, as long as the severity isn't dropped to
anything below important.

>
> Thank you very much for all your help with the issue.
> If you need more information just ask me, please.

Thank *you* for being collaborative :)

>
> Cheers.
>
> Andrea
>

Cheers,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net

Bill Vaughan  - "The tax collector must love poor people, he's
creating so many of them."

Message #48 received at 504771@bugs.debian.org (full text, mbox, reply):

From: Richard van den Berg <richard@vdberg.org>

To: Andrea De Iacovo <andrea.de.iacovo@gmail.com>, 504771@bugs.debian.org

Cc: Raphael Geissert <atomo64@gmail.com>, Thijs Kinkhorst <thijs@debian.org>

Subject: Re: Bug#504771: not a critical issue

Date: Sat, 08 Nov 2008 00:52:57 +0100

On 8-11-2008 0:09, Andrea De Iacovo wrote:
> 6. we can try to prepare a workaround while we wait an officile fix from
> upstream: maybe I could implement a function to check out if dangerous
> cookies are present and stop any other operation until those cookies are
> not removed.
>   

There is an easy fix suggestion at
http://brian.moonspot.net/2008/01/17/responsible-use-of-the-_request-variable/


$user_input = array_merge($_GET, $_POST);

or even better:

if(!empty($_POST)){
$user_input = $_POST;
} elseif {
$user_input = $_GET;
}

Now replace all usage of $_REQUEST with $user_input. Sounds safe, but
needs testing.. in case wordpress actually reads cookie values from
$_REQUEST (yuck).

Regards,

Richard

Message #53 received at 504771@bugs.debian.org (full text, mbox, reply):

From: Andrea De Iacovo <andrea.de.iacovo@gmail.com>

To: Raphael Geissert <atomo64@gmail.com>, 504771@bugs.debian.org

Cc: Thijs Kinkhorst <thijs@debian.org>, richard@vdberg.com

Subject: Re: Bug#504771: not a critical issue

Date: Sat, 08 Nov 2008 14:29:14 +0100

[Message part 1 (text/plain, inline)]

> 2008/11/7 Andrea De Iacovo <andrea.de.iacovo@gmail.com>:
> > Il giorno ven, 07/11/2008 alle 15.36 -0600, Raphael Geissert ha scritto:
> >>
> >> You can also set cookies via javascript code, e.g.
> >> <script>document.cookie = "GLOBALS=1;domain=.domain.tld"; </script>
> >
> > ok that's true.
> >
> > So let's see what we have:
> > 1. $_REQUEST references are widely used in wordpress.
> > 2. the standard EGPCS makes cookies overwrite GET and POST values in
> > $_REQUEST
> > 3. such values are used in "dangerous" cases (such as user deletion or
> > logout after redirection).
> > 4. "grave" data loss (user, post, comments deletion) could be avoided
> > not logging in as administrator (but only as a user with some
> > privileges)
> 
> All fine, although 4 is more a social than a technical problem, as
> there is no way we can force users to do that (although I definitely
> agree that it is a way to mitigate many possible issues).

As for sure I can mention something in the readme file with the next
release.

> 
> > 5. the issue is related to wordpress only and does not influence other
> > parts of the system
> > 6. we can try to prepare a workaround while we wait an officile fix from
> > upstream: maybe I could implement a function to check out if dangerous
> > cookies are present and stop any other operation until those cookies are
> > not removed.
> 
> You better not, that's how the GLOBALS DoS work.

I think I did not explain this well.
GLOBALS DoS works because the application simply dies without explicit
errors or something like that.
I think I could do something like:
	function check_maliciuos_cookies(){
		$malicius = array("action", "GLOBALS", "ANYTHING_ELSE");
		foreach ($_COOKIES as $cname => $cvalue)
			foreach ($malicious as $mname => $mvalue)
				if ($cname == $mname)
					die("Malicious cookie detected. Please delete cookies for this host
and come back");
	}

Obviously the code should have a better optimization, this was just an
example.

Richard, the solution you suggested would make me modify the whole
wordpress code. For such great changes I think it's better to work with
upstream.

Thank you all.

Cheers.

Andrea

[signature.asc (application/pgp-signature, inline)]

Message #58 received at 504771@bugs.debian.org (full text, mbox, reply):

From: "Raphael Geissert" <atomo64@gmail.com>

To: 504771@bugs.debian.org

Cc: "Thijs Kinkhorst" <thijs@debian.org>, richard@vdberg.com

Subject: Re: Bug#504771: not a critical issue

Date: Sat, 8 Nov 2008 17:13:14 -0600

2008/11/8 Andrea De Iacovo <andrea.de.iacovo@gmail.com>:
>
> As for sure I can mention something in the readme file with the next
> release.

Sure (OT: you may want to review the setup procedure too, because last
time I checked it was not very clear).

>
>>
>> > 5. the issue is related to wordpress only and does not influence other
>> > parts of the system
>> > 6. we can try to prepare a workaround while we wait an officile fix from
>> > upstream: maybe I could implement a function to check out if dangerous
>> > cookies are present and stop any other operation until those cookies are
>> > not removed.
>>
>> You better not, that's how the GLOBALS DoS work.
>
> I think I did not explain this well.
> GLOBALS DoS works because the application simply dies without explicit
> errors or something like that.

It works because it is incorrect. Being unclear is another problem, though.

[...]
>
> Richard, the solution you suggested would make me modify the whole
> wordpress code. For such great changes I think it's better to work with
> upstream.

The best solution is to respect the pourpose of GET, POST, and COOKIES.

>
> Thank you all.
>
> Cheers.
>
> Andrea
>

Cheers,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net

Tallulah Bankhead  - "If I had to live my life again, I'd make the
same mistakes, only sooner."

Message #61 received at 504771@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <atomo64@gmail.com>

To: 504771@bugs.debian.org

Subject: Re: bug #504771 downgrade

Date: Sun, 30 Nov 2008 14:36:27 -0600

[Message part 1 (text/plain, inline)]

Hi,

[Sending it to the bug report to make sure the extra info is recorded]

On Saturday 29 November 2008, Andrea De Iacovo wrote:
> Hi.
>
> As you could have noticed wordpress-2.5.1-10 hit lenny carrying the
> workaround for #504771.
> Could you, please, downgrade the bug to important now?

I'm still not very much convinced because there are plenty of other attack 
vectors out there in the code; it is just a matter of grepping for _REQUEST 
in the source code and check what they are used for.

For example: another look at the code revealed that wp_get_referer can be 
abused to redirect the admin to whatever site is specified in a cookie 
called '_wp_http_referer' under certaim circumstances.

Also, setting a 'delete_comments' cookie will cause a minor DoS when trying to 
perform several actions on the comments (via edit-comments.php). That would 
be a nice play to prevent the admin from deleting spam comments for a while.

>
> Thank you very much for your cooperation.

Thank _you_.

>
> Cheers.
>
> Andrea

Cheers,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net

[signature.asc (application/pgp-signature, inline)]

Message #66 received at 504771@bugs.debian.org (full text, mbox, reply):

From: sean finney <seanius@debian.org>

To: 504771@bugs.debian.org

Cc: Raphael Geissert <atomo64@gmail.com>

Subject: status on #504771?

Date: Sat, 27 Dec 2008 21:45:08 +0100

[Message part 1 (text/plain, inline)]

hi guys,

has anyone considered something like richard's suggestion in msg 48?  if the 
sev is not going to be downgraded to important, that's probably the best
way forward wrt lenny...

it shouldn't be too hard to make a new global variable or function in some 
centrally included location, and have that variable/function "safely" mimick
the REQUEST variable's behaviour.

regarding richard's comments about cases where cookie values might
be used via the REQUEST variable, i'd be highly skeptical that
this was going on, but then again we're dealing with a php webapp, so...
i think to rule that out you just need to cross-reference with a recursive
grep -i for cookie and make sure there are no overlapping variables in
usage of REQUEST.


	sean

[signature.asc (application/pgp-signature, inline)]

Message #71 received at 504771@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Raphael Geissert <atomo64@gmail.com>

Cc: 504771@bugs.debian.org

Subject: Re: bug #504771 downgrade

Date: Tue, 30 Dec 2008 19:20:35 +0100

severity 504771 important
thanks

On Sun, 30 Nov 2008, Raphael Geissert wrote:
> On Saturday 29 November 2008, Andrea De Iacovo wrote:
> > Hi.
> >
> > As you could have noticed wordpress-2.5.1-10 hit lenny carrying the
> > workaround for #504771.
> > Could you, please, downgrade the bug to important now?

Andrea, you are the maintainer, it's up to you to downgrade the bug if you
really believe that the severity is over-inflated.

I tend to agree that important is enough. It would be better to have a fix
but if we don't have any, it's not a reason to remove the package from
lenny.

You could however document the problem in README.Debian until it's
properly solved.

Andrea, how did it progress with upstream ?

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

Message #78 received at 504771@bugs.debian.org (full text, mbox, reply):

From: Andrea De Iacovo <andrea.de.iacovo@gmail.com>

To: Raphael Hertzog <hertzog@debian.org>, 504771@bugs.debian.org

Cc: Raphael Geissert <atomo64@gmail.com>

Subject: Re: Bug#504771: bug #504771 downgrade

Date: Wed, 07 Jan 2009 08:39:29 +0100

[Message part 1 (text/plain, inline)]

> Andrea, you are the maintainer, it's up to you to downgrade the bug if you
> really believe that the severity is over-inflated.
Ok, thanks.

> Andrea, how did it progress with upstream ?
I opened a ticket in their bug tracking system. I'm waiting for
feedbacks.

Cheers.

Andrea

[signature.asc (application/pgp-signature, inline)]

Message #83 received at 504771-done@bugs.debian.org (full text, mbox, reply):

From: Giuseppe Iuculano <giuseppe@iuculano.it>

To: 504771-done@bugs.debian.org

Subject: Fixed in 2.5.1-10

Date: Sat, 15 Aug 2009 16:25:55 +0200

[Message part 1 (text/plain, inline)]

Version: 2.5.1-10

This bug was fixed in wordpress 2.5.1-10

Cheers,
Giuseppe.

[signature.asc (application/pgp-signature, attachment)]

Message #88 received at 504771-close@bugs.debian.org (full text, mbox, reply):

From: Giuseppe Iuculano <giuseppe@iuculano.it>

To: 504771-close@bugs.debian.org

Subject: Bug#504771: fixed in wordpress 2.0.10-1etch4

Date: Sun, 23 Aug 2009 14:03:09 +0000

Source: wordpress
Source-Version: 2.0.10-1etch4

We believe that the bug you reported is fixed in the latest version of
wordpress, which is due to be installed in the Debian FTP archive:

wordpress_2.0.10-1etch4.diff.gz
  to pool/main/w/wordpress/wordpress_2.0.10-1etch4.diff.gz
wordpress_2.0.10-1etch4.dsc
  to pool/main/w/wordpress/wordpress_2.0.10-1etch4.dsc
wordpress_2.0.10-1etch4_all.deb
  to pool/main/w/wordpress/wordpress_2.0.10-1etch4_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 504771@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Giuseppe Iuculano <giuseppe@iuculano.it> (supplier of updated wordpress package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 15 Aug 2009 11:58:32 +0200
Source: wordpress
Binary: wordpress
Architecture: source all
Version: 2.0.10-1etch4
Distribution: oldstable-security
Urgency: high
Maintainer: Andrea De Iacovo <andrea.de.iacovo@gmail.com>
Changed-By: Giuseppe Iuculano <giuseppe@iuculano.it>
Description: 
 wordpress  - an award winning weblog manager
Closes: 491846 500115 504234 504243 504771 531736 531736 536724
Changes: 
 wordpress (2.0.10-1etch4) oldstable-security; urgency=high
 .
   * [2ef79dd] Removed 010CVE2008-0664.patch, it caused a regression and
     wordpress 2.0.10 isn't affected by CVE-2008-0664. (Closes: #491846)
   * [abbabe9] Fixed CVE-2008-1502 _bad_protocol_once function in KSES
     allows remote attackers to conduct XSS attacks (Closes: #504243)
   * [e8a73eb] Fixed CVE-2008-4106: Whitespaces in user name are now
     checked during login. (Closes: #500115)
   * [8a2e4f9] Fixed CVE-2008-4769: Sanitize "cat" query var and cast to
     int before looking for a category template
   * [711274f] Fixed CVE-2008-4796: missing input sanitising in embedded
     copy of Snoopy.class.php (Closes: #504234)
   * [17c72c0] Fixed CVE-2008-6762: Force redirect after an upgrade
     (Closes: #531736)
   * [88d8244] Fixed CVE-2008-6767: Only admin can upgrade wordpress.
     (Closes: #531736)
   * [d5c02a9] Fixed CVE-2009-2334 and CVE-2009-2854: Added some CYA cap checks
     (Closes: #536724)
   * [80e9dbd] Fixed CVE-2008-5113: Force REQUEST to be GET + POST.  If
     SERVER, COOKIE, or ENV are needed, use those superglobals directly.
     (Closes: #504771)
   * [7f577ca] Fixed CVE-2009-2851: Sanitize HTML URLs in author comments
   * [f23d55f] Fixed CVE-2009-2853: Stop direct loading of files in wp-admin
     that should only be included
Files: 
 d9389cbc71eee6f08b15762a97c9d537 607 web optional wordpress_2.0.10-1etch4.dsc
 45349b0822fc376b8cfef51b5cec3510 50984 web optional wordpress_2.0.10-1etch4.diff.gz
 71a6aea482d0e7afb9c82701bef336e9 521060 web optional wordpress_2.0.10-1etch4_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqN5KUACgkQ62zWxYk/rQf2XgCdFV8GR2K1YxsS+LI4qrIQVc+z
FXQAoKs1Tt+JiOHxEEM61EeSOwUpUPhw
=kQoV
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.