Fixed over a week ago.
Patched version of xmlrpc.php for 2.2 can be found here:
http://trac.wordpress.org/browser/branches/2.2/xmlrpc.php?rev=5584&format=raw
Ive diffed that file to a reg. 2.2 file and Im not feeling the love with the changes.
The new file has 4 changes all related like so:
<api name="WordPress" blogID="1" preferred="false" apiLink="<?php bloginfo_rss('wpurl') ?>/xmlrpc.php" />
<api name="Movable Type" blogID="1" preferred="true" apiLink="<?php bloginfo_rss('wpurl') ?>/xmlrpc.php" />
<api name="MetaWeblog" blogID="1" preferred="false" apiLink="<?php bloginfo_rss('wpurl') ?>/xmlrpc.php" />
<api name="Blogger" blogID="1" preferred="false" apiLink="<?php bloginfo_rss('wpurl') ?>/xmlrpc.php" />
5 changes regarding fixing the $post_date in mysql …
1 change like so:
$max_results = (int) $args[4];
and this:
$post_author = $postdata["post_author"];
Do tell, what specifically adresses that exploit?
$max_results = (int) $args[4];
is about the closest I can see.
ON an off note — it’s nice of ‘them’ to let people know about things. So, they have a support forum, and people come here asking questions ALL day about things as trivial as setting up permalinks, and they expect the same people that cant set up permalinks to ..
what? run the svn version?
idle on trac all day??
thats a crock of crap.
Do tell, what specifically adresses that exploit?
$max_results = (int) $args[4];
You nailed it in one.
The specific changeset is here:
http://trac.wordpress.org/changeset/5584
The reason this fixes it is because the exploit posted above relies on the fact that $args[4] is passed directly into the SQL query without modification. Casting $args[4] to an int means that only numbers will get through. Any text injected into there will make that cast return a zero (or an error, either way works).
The link I posted was to the latest version of the 2.2 branch of xmlrpc.php.
ON an off note — it’s nice of ‘them’ to let people know about things. So, they have a support forum, and people sit her asking questions ALL day about setting up permalinks, and they expect the same people that cant set up permalinks to ..
what? run the svn version?
idle on trac all day??
thats a crock of crap.
To be entirely fair, I see nothing in trac to indicate that anybody knew that this was an exploitable hole and in the wild. It was a bugfix, as far as the text reads to me.
does this effect 2.0.10 ?
cheers.
thanks for the clarification.
The link I posted was to the latest version of the 2.2 branch of xmlrpc.php.
Yes, which isnt the downloadable version — Im frustrated with the lack of communication, but hey, what else is new.
does this effect 2.0.10 ?
Definitely not. The wp_suggestedCategories function was not in the 2.0 series.
linickx, no.
2.2 introduced an entirely other api .. thats what this is specific too.
2.0.x didnt have that yet.
The exploit doesnt affect 2.0.x and the patch isnt applicable.
Yes, which isnt the downloadable version.
Well, yes. 2.2.1 has not been released yet. It’s the 2.2 BRANCH that I pointed to.
Westi pointed out (on trac) that this exploit only works if the remote user already has one valid user and password, and so the only vulnerable sites would be those with user registration enabled.
as the exploit says.. neither here nor there imo.
Thats informational only and not especially heartening.
whooamu & Otta42, thanks 🙂
isnt
$category = $args[3];
....
WHERE cat_name LIKE '{$category}%'
exploitable either ?
No. Above that, the code calls $this->escape($args); which should escape them and eliminate any issues.
The exploitable bug in the max_results is that it comes at the end of the query. So if you sent: “0 UNION ALL SELECT user_login, user_pass…” you could pull out extra information, and that would get past the escape filter. Any useful exploit code that could be inserted into that LIKE clause would not make it through the escape.
I apoligize for the modlook but may I suggest removing the ‘&format=raw’ out of that link within the second post? I know my browser can’t handle the link. Landing on the page would probably be better.
The format=raw makes it serve up as an application/octet-stream, which makes any normal browser open a save dialog. That’s why I posted that link. You should be saving the raw file and using it that way.
Here’s the link if you want it in a text format, but you should really download the file using the raw link instead:
http://trac.wordpress.org/browser/branches/2.2/xmlrpc.php?rev=5584&format=txt
