There’s an article about a security problem getting a bit of attention lately,
Apache Access Vulnerability Could Affect Thousands of
Applications.
Sounds really scary. Here’s a better article about it, Zero-day in popular jQuery plugin actively
exploited for at least three
years.
Looking at those titles you might think that the problem is either with a
jQuery plugin, or Apache’s .htaccess files. It’s neither. The real
situation is more complicated. You might think that if you’re not using this
plugin on your website, you’d be safe. You’d be wrong. You might think that
patching the plugin, or the Apache web server, would solve the problem. You’d
be wrong about that, too. The real problem is still there, waiting to bite
you in the tail. If you don’t have a website, or don’t allow file uploads,
you can stop reading now unless you’re curious. If you do, stick around
(or jump to the last section if all you want is the fix).
The problem being reported
You may have noticed that the two titles up there are highlighting different
aspects of the problem. There’s that “popular jQuery plugin”,
blueimp/jQuery-File-Upload.
People building websites use it to allow their users to upload files (e.g.,
cat pictures). It’s really popular – 7800 forks on GitHub, 29,000 stars;
probably tens or hundreds of thousands of sites using it. And then there’s
the Apache web server. Apache is even more
popular – it runs some 45% of the
web. Since there
are presently just short of two
billion websites
(although all but a couple of hundred million are currently active). And more
specifically and specifically htaccess
files, which are used
to override certain server configuration options (including security options,
which is almost as scary as it sounds, but doesn’t have to be).
The specific problem is this: jQuery-File-Upload lets visitors to a web site
upload their cat pictures. These get put in a directory somewhere in the
server’s file system. If you’re running a website and have any sense, you’ll
put that directory someplace where it can’t be seen from the web, but of
course that means that your visitors can’t see the cat pictures they’ve
uploaded, without you or your software doing some work, and that could be
tricky.
If you have a directory that’s part of your website that you want to be
invisble from the web, or visible safely (we’ll get into that a little later),
there are two ways to set that up. If you have access to Apache’s
configuration files, you do it there. Unfortunately that requires root
access, and most of us are using shared servers and our hosting sites don’t
allow that, because it would be a huge security hole if they did. The other
way of configuring your site is to put a file called .htaccess somewhere on
your site, and it will apply configuration overrides to that directory and
everything below it. That’s a little dicey, because it’s possible to get that
wrong, especially if you’re not an experienced system administrator, but if
you’re operating a shared hosting service like the one I use, you have to give
your users some way of setting parameters, and .htaccess is the only game
in town.
Finally there’s the fact that, some ten years ago, Apache changed the
defaults on their server so that .htaccess files are disabled, so the
administrator has to specifically re-enable them. What does that mean?
Well, if you are allowing users to upload files, and if you put the upload
directory where it can be seen from the web (meaning that people can
download from it), and if you were counting on a .htaccess file to
protect that directory, and if you upgraded Apache any time in the last
ten years, and if you or your system administrator didn’t re-enable
.htaccess files, and if you thought that your .htaccess file was
still protecting you, then you have a problem. That’s a lot of “if”s, but
there are an awful lot of websites.
Here’s how this situation can be exploited, as reported by a security
researcher at Akamai named Larry Cashdollar, in an article titled Having The
Security Rug Pulled Out From Under
You.
If you can upload files to a website, all you have to do is:
1$ echo '<?php $cmd=$_GET['cmd']; system($cmd);?>' > shell.php
2$ curl -F "files=@shell.php" http://example.com/jQuery-File-Upload-9.22.0/server/php/index.php
It’s not hard. The first line there creates a one-line file with some PHP
code in it. The second line uploads it. Now you have a file called
shell.php on the server. You can send a request for that file with a query
string attached to it, and PHP will helpfully pass that string to the
system, which runs it. Boom.
The problem with the reporting
Here are a couple of passages quoted from the ZDNet
article:
The developer’s investigation identified the true source of the
vulnerability not in the plugin’s code, but in a change made in the Apache
Web Server project dating back to 2010, which indirectly affected the
plugin’s expected behavior on Apache servers.
…
Starting with [version2.3.9], the Apache HTTPD server got an option that would
allow server owners to ignore custom security settings made to individual
folders via .htaccess files. This setting was made for security reasons, was
enabled by default.
Actually, what happened was that the server disabled .htaccess files by
default, and it was done for performance reasons – having to read
.htaccess files with every request is a big performance hit. Here’s what
the Apache documentation says about it:
.htaccess files should be used in a case where the content providers need to
make configuration changes to the server on a per-directory basis, but do
not have root access on the server system. In the event that the server
administrator is not willing to make frequent configuration changes, it
might be desirable to permit individual users to make these changes in
.htaccess files for themselves. This is particularly true, for example, in
cases where ISPs are hosting multiple user sites on a single machine, and
want their users to be able to alter their configuration. [emphasis mine]
The DARKReading
Article
adds,
A security vulnerability is born, Cashdollar said, when a developer looks at
very old documentation and uses .htaccess for authentication instead of one
of the methods now suggested by the Apache Foundation.
Well, no. The documentation is still current, and it’s very clearly marked
as something you shouldn’t use unless you have to. And most of the people who
have vulnerable websites aren’t developers, don’t have any choice about
whether to use .htaccess, and aren’t reading the docs. They’re just doing
cut-and-paste from the quick-start documents that their web host provides.
What’s the real problem?
There are a couple of things that the articles I’ve refererred to didn’t
mention, or just glossed over.
The first is that uploading files is a problem, and it’s been a problem
since long before there was a World Wide Web! I first ran into this while
running an FTP server. There are all sorts of ways file uploads can be
abused. Somebody can bring down your server by uploading junk and filling
your disk. They can upload malware. It has nothing at all to do with
jQuery-File-Upload; this has been a problem since day 1.
The solution, if you must allow uploads, is to upload them to someplace safely
outside of your website, and process them immediately – either with your
server-side code, or a cron job. This is just as much common sense as not
using any form data until it’s been validated and sanitized. Some
languages, like Perl, give you some help with this. This is true on the
client side too, if you have JavaScript. Validate your inputs! I ran into
that one last week, you may remember.
The second problem is PHP. Actually, the problem is putting executable
files in your website instead of someplace like a CGI script directory, or a
web server. But PHP is the biggest offender. It was designed to make it so
easy to build a website that anyone could do it. And everyone did.
PHP was designed to be simple. It wasn’t designed to be safe. (It has a
lot of other problems, too, but that’s the big one.) See Why PHP
Sucks and PHP: a fractal of
bad design, for
example.
The biggest problem with PHP is that it works by mixing executable executable
code with the documents you’re serving to the user. Sure, it’s convenient.
It’s also bad design – it’s a series of disasters waiting to happen, and this
is only the most recent one.
What should you do?
- Obviously, if you have access to your server’s configuration, you should
disable
.htaccess and do everything at the server level. That’s not
always possible.
- If you aren’t using PHP on your website, disable it.
- At the very least, disable PHP in your upload directory!
- If you want to let users upload files, put them someplace outside your
document root and keep them there until you or your software can review
them for safety. (When I was running an FTP server, I had separate
‘incoming’ and ‘outgoing’ directories.)
You may find Disable PHP in a directory with Apache .htaccess - Electric
Toolbox
helpful: just put these three lines into an .htaccess file, either at the
top level of your site, or down in any directories where it’s not needed
(which includes not only your upload directory but also image directories and
other assets, just to be sure).
RemoveHandler .php .phtml .php3
RemoveType .php .phtml .php3
php_flag engine off
While you’re at it, make it so that the web server – and anyone else who isn’t
you – can’t write into your
website files:
1cd your_server's_document_root
2chmod -R go-w .
Have fun, be safe out there, and don’t use PHP.
Another fine post from The Computer Curmudgeon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-syndicated.gif){kind=small}
