Plaidophile

Sounds like a good reason to upgrade to Scoop/Slash/MT etc.

Scoop/Slash suck for what I want to do. That's also a bit of throwing out the baby with the bathwater, considering this particular exploit was already fixed.

It's also not as if Scoop or Slash are necessarily bug- or exploit-free. They're just not in very wide use, unlike phpBB which gets a lot of attention directed to it.

People still do that?

Apparently.

FWIW, this is trikuare.cx's first security incident in over five years of operation, and it was one which caught a lot of phpBB sites with their pants down over the holiday weekend.

So yes, I've heard of keeping my files up to date.

%2527%252e

Still not quite sure how that works, but whatever. Yay for being on Full-Disclosure and hearing about these things early.

suexec is a mixed blessing. On one hand, having it means you can't get your config.php read by other users - on the other hand, it means that can happen.

Urgh. Working Linux "capabilities" would be really nice around here.

The parameter is passed to urldecode(), which converts it from %-escaped stuff to plain ASCII. The first character in it confuses the PHP parser into injecting arbitrary code.

The particular exploit which hit trikuare.cx works by just creating a file called "tmp.php" which just executes whatever command is passed to it as a URL. Unfortunately, one of the first things they did after installing tmp.php was to divert my access_log so I couldn't see exactly what else they did after that, aside from what I could tell by the crap left around in /tmp and the various rogue processes, such as some sort of file-sharing client called xfs (not to be confused with the filesystem), a few attempts at a rootkit which my webhost has fortunately been patched against, and a few other random things (which were named similarly to standard UNIX stuff, like 'sh' and 'screen', and also with random characters intended to trip up the novice, like { and ^M and so on).

What I don't get is how the uploaded exploit was actually run, though, since my webhost's configuration requires all PHP files to be set executable and start with a #!/usr/local/bin/php, which none of these files I looked at were.

I'm also surprised (and very glad) that they didn't mangle other files in my phpBB installation or installed any other backdoors, or else I'd have been very upset since it'd have taken me a while to reapply all of the useful mods I've installed. When I get home from work tonight I'll probably go through and just do a clean reinstall anyway, though, just to be safe.

It frustrates me how so many assholes out there far outnumber me in terms of time and ability to keep up with all the latest security issues, though. This also has me strongly considering my idea of writing secure-first fancy-later comments-anywhere forum software again, except that I don't exactly have a lot of free time to waste on this shit. Grr. This has already taken up way too much of my workday as it is.

Some peoples' children. Meh.

BTW, the bugtraq report for the exploit shows how the mechanism works, only totally underestimates the impact. It looks like it's a PHP bug in how urldecode() works, leading to arbitrary PHP injection (not just SQL injection like what the howdark folks believed).

Well, hmm. urldecode() doesn't seem to do anything wrong when it hits %2527 - it just converts that to a single quote, just as expected.

The bug is probably somewhere in phpBB where they implement highlight= in some rather asinine way involving eval(). I haven't looked at the phpBB highlighting code yet, but I will.

Well, it's not urldecode per se which is incorrect, so much as the way that PHP handles the stray ' later on. There's no eval() - it's in a preg_replace() that the newly escaped-out string has its fun.

The bug in phpbb, of course, was calling urldecode() on something from $_GET[] to begin with - $_GET[] has already been urldecode()d. However, this is an easy logical mistake to make:

[quote=zetawoof]Well, hmm. urldecode() doesn't seem to do anything wrong when it hits %2527 - it just converts that to a single quote, just as expected.

Except that urldecode("%2527") should return %27 - what was passed to urldecode was "%27".

Oops. I meant to say that urldecode("%2527") returns %27 like it should.

Dammit, now I'll have to hunt down an old copy of phpBB and see where this all goes wrong. I'm still not quite sure how an improperly sanitized string can get executed by PHP without an eval().

(And, like I said, PHP, and Linux in general, seriously need some way for a script/program to drop capabilities - like, in this case, opening files for writing.)

(later, after hunting down a copy of phpBB 2.0.6)

Okay... so a "naughty" highlight value gets sent through various functions, then finally passed into the templating engine. It goes through a bunch of stuff on the way - including, yes, preg_replace - but that doesn't cause trouble directly. Embedding variables in strings, a la "foo $bar baz" does not reevaluate the string as an expression (a shell script might, though - that's why I hate shell scripting sometimes). So I guess it's into the templating engine we go...

and yup, the templating engine does use eval() all over the place. In fact, I'm surprised this hasn't come up as an issue before....

Ah. I guess the various error messages are just confusing. php needs better call-trace capabilities. (by "better" I, of course, mean "any whatsoever")

Ah...that would explain how my site got hacked twice. This morning the jackass hacker was even bold enough to post his email address. Grrrr!!!