One Of The Best SEO Tools Now The Biggest Security Risk

10 comments

Anyone doing any basic level of seo is using mod_rewrite to make thier urls pretty.

Today the Apache Foundation released versions to fix the exploit within mod_rewrite.

Upgrade your servers and urge your providers to do so asap.

You can read the official announcement here

Depending on the manner in which Apache HTTP Server was compiled, this software defect may result in a vulnerability which, in combination with certain types of Rewrite rules in the web server configuration files, could be triggered remotely. For vulnerable builds, the nature of the vulnerability can be denial of service (crashing of web server processes) or potentially allow arbitrary code execution. This issue has been rated as having important security impact by the Apache HTTP Server Security Team.

This flaw does not affect a default installation of Apache HTTP Server. Users who do not use, or have not enabled, the Rewrite module mod_rewrite are not affected by this issue. This issue only affects installations using a Rewrite rule with the following characteristics:

* The RewriteRule allows the attacker to control the initial part of the rewritten URL (for example if the substitution URL starts with $1)
* The RewriteRule flags do NOT include any of the following flags: Forbidden (F), Gone (G), or NoEscape (NE).

Please note that ability to exploit this issue is dependent on the stack layout for a particular compiled version of mod_rewrite. If the compiler used to compile Apache HTTP Server has added padding to the stack immediately after the buffer being overwritten, it will not be possible to exploit this issue, and Apache HTTP Server will continue operating normally.

The Apache HTTP Server project recommends that all users who have built Apache from source apply the patch or upgrade to the latest level and rebuild. Providers of Apache-based web servers in pre-compiled form will be able to determine if this vulnerability applies to their builds. That determination has no bearing on any other builds of Apache HTTP Server, and Apache HTTP Server users are urged to exercise caution and apply patches or upgrade unless they have specific instructions from the provider of their web server. Statements from vendors can be obtained from the US-CERT vulnerability note for this issue at:

Comments

This is a major problem

I have a ton of clients doing this... uhhhggg!!

i use mod rewrite all over

i use mod rewrite all over the show, i thought with some confidence. :-/

Quote:
Please note that ability to exploit this issue is dependent on the stack layout for a particular compiled version of mod_rewrite. If the compiler used to compile Apache HTTP Server has added padding to the stack immediately after the buffer being overwritten, it will not be possible to exploit this issue, and Apache HTTP Server will continue operating normally.

WTF does that mean.

Can someone explain in non bearded ,*nix geek style tongue, where my type of mod rewrite sites are at risk please?

Can they do XSS, can they hack the server, can they DROP the database etc etc

Wow. I'd just seen this, was

Wow. I'd just seen this, was of course concerned and, not a couple of hours later, received the usual Server Software Notification email from my host (Verio) advising that they'd upgraded Apache. How cool is that for late on a Friday?

ukgimp -

ukgimp -

XSS is cross site scripting... completely different thing. This is much much much worse.

This is a buffer overflow which basically means that anyone can execute code as the apache user. Most cases people will send a series of commands which will fork the webserver to download a rootkit; unzip it; then try to hack root and email the person that executed the code if successful.

This if course will all be automated.

So bascically if your box is comprimised someone can not only kill the database.... it can kill the whole box. But generally script kiddies will just backdoor them and them use them for dos attacks or for distributing pirated files.

Perhaps a better security professional like JasonD can go into more detail

Explanation

From what I read into this, if you have any rewrite rules that are written with $1 as the beginning of the rewrite - ie
RewriteRule /something/$1 $1-somethingelse
AND
you also do not have any of the following flags - F,G,NE (Forbidden, Gone, No Escape)
AND
you happen to be on a certain OS using a certain compiler (which were not spelled out)

Then you are vulnerable. There are very few situations that I can fathom where this would be the case, but it's good to update anyways. Running the install is a heck of a lot easier than searching through your config and htaccess files to see if you are vulnerable.

Be aware though - that if you upgrade from 2.0.x to 2.2.3 (like I just did), you will also have to recompile php post-upgrade. And any other modules that you built that used apxs - like mod_geoip, mod_perl, or anything like that.

shoe, cheers for that.

shoe, nev, cheers for that. Because the warnings are so vague I was not sure if it allowed a user to stuff a new value of $X into the url and do some funky shit.

>>This is a buffer overflow which basically means that anyone can execute code as >>the apache user

I dont even like people logging in as root with SSH :-) so allowing some dude via a URL to run apache level commands is heavy heavy shit.

Hmmmm, need to look into this further

compiler used

First, let me say that the compiler is not responsible for the flaw. In fact the compiler may mask the flaw. Perhaps in a spirit of "community", it was decided not to name the compiler.

However, it is possible to deduce the compiler used by examining the list of binary versions that is posted in the announcement.

The versions affected include the binary distributions from apache.org and packaged with Redhat Fedora as well as Ubuntu. The toolchain used for these particular distributions is GCC. For confirmation, examine the build notes for any particular version in the source code tarballs.

This implies that almost all installations using mod_rewrite in the specified manner are affected since GCC is almost universally used as the compiler for apache.

The most likely exceptions to GCC are those installations running on Windows where the admin chose to use a Microsoft compiler. The flaw would still exist, it is only that the compiler produces a binary with a different structure.

This release builds on and extends the Apache 2.0 API. Modules written for Apache 2.0 will need to be recompiled in order to run with Apache 2.2, but no substantial reworking should be necessary.

Right.

As this flaw has existed since 1.3 in a core module, I'm going out on a limb here to say that the old argument that open source is inherently better because of the number of eyeballs looking at it is just so much rhetorical eyewash.

If I read it right....

Something like this, which is the only use of $1 on my site:

RewriteCond %{HTTP_HOST} ^domain\.com
RewriteRule ^/(.*)$ http://www.domain.com/$1 [R=301,L]

Should be relatively safe, maybe...

Perhaps a better security

Quote:
Perhaps a better security professional like JasonD can go into more detail

me a security pro??

Dunno about that, but personally there are some other vulns I am more interested in and playing with at the moment.

On this specifics of this one, it IS a major, majaor problem, but it isn't as simple as others to take advantage of to "specificially" get hold of you via your sites.

Reason I say that is that your Apache installation has to be vulnerable in the method described and you need to be using Mod Rewrite rules of the kind that are vulnerable. The thing is that there is no quick check for an attacker to know that all of these variables are in place on site X.

It is highly possible that many machines could be "OWNED" by this technique but my believe is it will be a worm based attack, trying any and all random domains and IP addresses with adaption to existing URLs it finds, potentially by a search on a major SE.

We all remember the Santy worm and how it requested information from G, well imagine an attack that used the site: command on any of the major engines ! Quite hard to block while still allowing the functionality required for legit users.

The answer, so you don't get hit is actually quite simple. Upgrade Apache

Nothing new

It was a security risk for a long time few years ago, so no surprise, it had to come once.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.