How do apache hosts prevent against attacks like this? Or, at least how do they harden their implementations against it?
I'm not much of a sysadmin but this intimidates me. I've always known that allowing PHP/.htaccess uploads are dangerous, if not fatal, and have done everything I know how to prevent them.
Speaking broadly, you really can't afford to let users stuff things on to your filesystem directly. You need to fully control the location of the file in some manner the user has no access to, and the "filename" of the file should exist only as database entries somewhere mapping back to your controlled name. Probably shouldn't even be in the web server's path.
Oh, and if you've never thought about this before, odds are about 48% that you've got a JS injection on your file, too. Go upload a file called <script>alert("Hi")</script> and see what happens. The other 48% is that the shell you shouldn't be passing this filename directly to will go crazy because of the angle brackets being syntactically invalid. Oh, and if you can request files by name, can you request ../../../../../../../etc/passwd? Statistically speaking, probably yes.
It's theoretically possible to safely manipulate the filesystem from within a web server but it's a great deal harder than it appears at first; there's a lot more than just learning the parameters to the "open" call.
Generally, sound to somehow include the SHA1 of the filename in the filename, and to map [^A-Za-z0-9\.] to "_". If there's no reason to store a semantically valid filename on the filesystem, we usually just use the hash. It's easy and fast.
As jerf (+1, great answer), stepping back a little... it has been ~fifteen years since we started noticing problems with htaccess. It filled a niche when webserver configuration was hard and when CRUD admin interfaces were significant work. Htaccess (and friends) should go now. I don't just mean "use the palliative above": I mean any time a remote client can potentially download or overwrite the ACL then the design is probably broken. (Apache is not alone here).
With the myriad of possible use cases and massive deployed base apache is probably stuck with htaccess until extinction. Forever more, we will see this comment in httpd.conf:
# The following lines prevent .htaccess and .htpasswd
# files from being viewed by Web clients.
Security is seldom well served by agile's "simplest thing that could possibly work".
Worse, there is certainly other "best of breed" security stuff that we are doing right now that will be incontestably bad from a future viewpoint. What is that stuff?
As usual, allow the smallest subset of functionality which still permits legitimate uses. In these cases they're relying on .htaccess files being allowed specific overrides - FileInfo and Options being the most powerful ones.
'AllowOverride AuthConfig Indexes' is generally relatively safe (in my humble experience) - i'd be scared to see an htshell like these with just those.
Using mod_security (seeing attempts to access filenames with htaccess in them) and using the grsecurity kernel patch to disallow binaries from running that aren't "owned by root in a root owned directory". So you can upload all the binaries you want, but you won't be able to run them.
I'm not much of a sysadmin but this intimidates me. I've always known that allowing PHP/.htaccess uploads are dangerous, if not fatal, and have done everything I know how to prevent them.