iframe injection problem?

heres a quick fix:

[bad fix removed]

I agree, sorta. Here is where I dont.

These attacks have been going on for weeks, if not months. HAD you waited, how many more blogs WordPress blogs would have been exploited while they “got on top of of it”.

Now theres a fix. Now, when someone says “hey, this happened”, we, you and I, and everyone else that reads the forums knows what to say happened and can explain how to fix it.

Frankly, they, and I mean no disrespect to any developers of WP, have had ample time to “get on top” of something that has been going on for months.

You, in my opinion, did the right thing, by shining a light on a big ass black hole that bothered a lot of us now for quite some time. Excellent catch..

—

Did it go unnoticed that this thread started THREE months ago?

Well, I’m not completely convinced this is the only one. The person who hacked my page managed to do so in such a way that it stayed published.

But thanks for the support.

I saw your comment. ?? yeah we tested it, on the SVN as well – both resulted in edited posts that were changed to drafts.

I was actually wondering how many threads I could dig up on here where ppl complained about logging in and finding that their previously published posts had somehow reverted to draft status, and how far back that went.

A cursory look at xmlrpc.php indicates that in 2.0.x there WAS and IS user checking. In 2.1.x it *appears* to have changed to the way it currently sits, unless there was user checking elsewhere.

Well, if they do it again, I’m logging up the wazoo right now. Hopefully I’ll figure it out. ??

I’m actually thinking that there are two different exploits, but I haven’t found the other. I think that this is the exploit they used to actually change the content of the post, and I think there is another that they used to set it to “publish”.

That’s why I think there were two separate xmlrpc calls.

This whole codebase could use a serious audit.

whoami, your fix does not. I would rather not have people think they’re safe and really not be, and there is a release coming shortly anyway. If you’d like to post more to this thread please reply to the email I sent you this morning.

If anyone is scared and wants a fix NOW, they should either turn off registration (which is off by default) or delete xmlrpc.php.

Matt, thanks for your attention to this, and again I’m sorry if I caused more trouble than necessary. I’m not sure I would do it too differently if done all over again, but I think I would give you guys a couple of days to get a patch out.

Otto42 was correct a month ago that any information should be sent to our security address, that way a real fix can be put out before you inform every bad guy on the planet about the problem, even if one already has it. This is what security professionals do, too, because they know it causes far greater harm than not to.

Perhaps. But I would respond that in addition to my other reasonings, it was 4:30 AM, I was kind of gobsmacked that I even found the d*mn thing in the first place (I’m a very experienced coder/system administrator, etc., but I’ve never ever found a bug of this scale before), and I had no idea the “security” address even existed. I kinda lost my head.

I think it’s a learning experience for both sides, and we’ll leave it at that. After all, while I may have handled this in a suboptimal manner, it did take four months for it to be found – and then by someone who had nothing to do with coding wordpress and had honestly never really looked at the code before. So let’s just chalk it up to experience. I apologize for the trouble. Deal?

The security address was mentioned a few posts before yours, but okay.

Matt, I didn’t see it. If I had have, I would have known what to do. That’s my bad, especially if it were staring right at me like that, but what’s done is done.

Wait a minute … if we’re talking about security then we’re talking about something like strict logic. (Someone mentioned “audit”? I’m available … I won’t tell you what I wrote for optimizing VB5 shiet. As for normalizing a commodity trading shop’s QuatroPro and Paradox? $250/day 14 years ago. And I did MEL-SPEC FMECA at fed rates. You wanna wade into that swamp, get yourself a good boat. Or skis.)

I don’t see anything here like fault-isolation and identification. /Not saying it’s not; saying don’t see./

Here’s the noisy bit I found in VillageIdiots’ thread:
“they managed to edit mine in place and leave it published.”
Well ok: if that’s so, then we’ve got A.
But if it’s “the posts end up being changed to drafts” (That’d be nice!) then we’ve got B.

So: if we reporter could re-iterate again, for once more time, reduntantly, that’s verified as a UserCase.
When someone maps out how to disconfirm that, they should publish IEEE.

Point is: it’s distinct scenarios; either they’re left in / toggled to Draft (1 chain) or they remain Publish (1 chain … a different one).
The facts merely collapse the probability wave and provide a link back to the failure node, they don’t fix the fault.

*I’m not much into coaxing a worm to squirm or a cat to stray … call me old-fashion.*

–bentrem

There were two separate xmlrpc calls. I suspect we have B that turns into A. Just because it was set to published doesn’t mean this is an invalid scenario, it just means there is a component to it that has not yet been identified.

(someone DID register to my site before this happend)

Your style is very poetic and very difficult to understand.

@duskglow Yes, you’re right, it’s true. But not always. ??

1) concensus seems to be “left in Draft”; you wrote “managed to do so in such a way that it stayed published” … have there been others reports of “left as Published”? did the test scenario you blogged leave things as Published?

2) do you think it’s two separate scenarios?

In TRAC the call seems to be for more hard data.