htaccess error

[EliteRides]

Anyone able to help me understand

Invalid command '\xfe\xff',

I do not have anything in my .htaccess file that refers to that.

[Spathiphyllum]

"\xfe\xff" is a path using hexadecimal. "x" tells a server parser that the next value is a hexadecimal number "fe" which translates to "254" in decimal. "ff" is the equivalent of "255".

So, this is either a record of a request for a resource that has the value of \254\255 in it or is an attempt to present an escape ("\") value before the "x" to pass the hexadecimal value as a literal string.

It's probably just part of a buffer overflow attempt through some worm or other exploit. Is this part of a much larger string (that was repeated), or is that all there is?

[EliteRides]

Thanks for the reply. That was all the error had. It just had the above statement in the error log and referenced the .htaccess file as the source.

I would have never thought it would be an exploit attempt, but I am interested in any examples you may know of. The reason why I would not have thought it would be that is because I am in the middle of transfering my site(s) over to JPC. That is just an error I ran into as I am setting them up. My sites are pretty heavy in PHP scripts. Would a misconfiguration while transferring my site cause an error like that? This part of the site with the error is using a Content Management System.

edit

It appears that with my .htaccess file empty the error goes away. What type of statement in an .htaccess file would cause this? I am on my phone now. I will post what I have in my .htaccess file when I am back on a PC.

[jason]

We'd have to see the .htaccess file to know for sure what's happening. Post it when you get a chance.

--Jason

[Spathiphyllum]

"SEARCH /\x90\x02\xb1\x02\xb1\x02\xb1\[very long repeating sequence snipped]\x90\x90\x90\x90"

This is an example of a "GET" request of sorts with a long string as a buffer overflow exploit attempt. I don't work with php CMS configurations, so I cannot provide explicit guidance. More info from your .htaccess file would be needed. Unless it's a server wide configuration that is causing the error, then you've narrowed the tweak to your end of server directives. The fact that an empty .htaccess file doesn't trigger the error clearly indicates it's a local and non-server-wide "bug".

It would superficially appear that the CMS importer is parsing a file improperly and may be producing an erroneous warning. I initially understood your problem to be that the .htaccess file on your "new" server was producing the error. Now I think I understand it better that an .htaccess file that is being transferred is the actual source string of the error. In that case it would be easier to detect the error when you post the .htaccess contents.

[EliteRides]

I found my .htaccess info from an old post on another forum. Aside from the default stuff that JPC adds here is what else my .htaccess file has.

#
# mod_rewrite in use
#

Options +FollowSymLinks
RewriteEngine On

# let the server know that we were reached via /xyz and not
# via the physical path prefix /abc/def

RewriteBase /

#
# Rules
#

RewriteRule ^content(.*) index.php
RewriteRule ^component/(.*) index.php

RewriteRule ^forums/(index.php)?$ /index.php?option=com_smf&Itemid=175

AddType text/html .shtml .html
AddHandler server-parsed .shtml .html
Options Indexes FollowSymLinks Includes
DirectoryIndex index.php

While I'm at it, can someone clarify these two lines for me?

Options Indexes FollowSymLinks Includes

and

Options +FollowSymLinks

What does the "+" symbol do? Can I get rid of that line since the rest is duplicated in the other line?

edit

I'm thinking it might be this part.

RewriteRule ^content(.*) index.php
RewriteRule ^component/(.*) index.php

This was used as a Rewrite to use SEF links. I disabled SEF links in the configuration. Would a Rewrite like that cause it?

[Spathiphyllum]

I'll have to come back to parsing your .htaccess files later due to time pressures. As for the questions re Apache directives, review the following and search for the keywords there:

Apache Core Directives

This will tell you more concisely exactly what you need to know. In fact, bookmark that page. It is the best reference you will have for tweaking your virtual server. From it you can expand your knowledgebase outward.

[Vin DSL]

Just for the hack fo it, try 'commenting out' that RewriteBase line...

#
# mod_rewrite in use
#

Options +FollowSymLinks
RewriteEngine On

# let the server know that we were reached via /xyz and not
# via the physical path prefix /abc/def

#RewriteBase /

#
# Rules
#

RewriteRule ^content(.*) index.php
RewriteRule ^component/(.*) index.php

RewriteRule ^forums/(index.php)?$ /index.php?option=com_smf&Itemid=175

AddType text/html .shtml .html
AddHandler server-parsed .shtml .html
Options Indexes FollowSymLinks Includes
DirectoryIndex index.php

If that doesn't work, start 'commenting out' everything else line-by-line until you find which line[s] it is.

[EliteRides]

Ok, well. I've commented each line out one by one. I've even removed them entirely one by one, including the default htaccess lines that JPC provides. If I have anything I get an internal server error. The only way for me to avoid it is to have no .htaccess file at all.

Any ideas?

[Spathiphyllum]

EliteRides,

Well, it would appear that it's not the contents of .htaccess at all. Obviously. I cannot imagine how this would produce an error but I'll ask anyway. What permissions do you have for the .htaccess file? It should be [-rw-r--r--]. Have you researched the CMS you are using to see if there are any issues documented for this? I'm puzzled since the CMS worked on another server and not on this one. What version of PHP were you using before? What version are you on now? Same for server. Have you been using Apache the entire time or are you migrating from a CMS application optimized for IIS?

I'm kinda scattershooting here because there is no reason that you should not be able to use .htaccess at all. The fact that the error presents even with a blank file means .htaccess contents are irrelevant and that is a constructive diagnostic result... just not sure what to do with it. Sometimes, a script error reports a flaw that is incomplete, i.e. it records one thing when the flaw was really flagged elsewhere in a particular block of code. Issues like that are best addressed by the application developers.

Sorry I couldn't be of more help. Maybe the aforementioned tips will point you in a better direction.

[EliteRides]

Thanks for the help everyone.

I know I'm new, but I guess I have not had the chance to prove that I am not a newbie. Everything was up to date (php version), permissions were set. I figured I knew what it was when I realized it was an .htaccess file at all, but was unable to troubleshoot at the moment. Problem solved. For some reason (I'm guessing it's Fetch) when I would actually FTP the file it was throwing the character at the bottome of this post into it as the first line. (For some reason anything after that character in this post gets erased. So, I have to put it at the bottom of the post to get everything in).

I loaded the file again, received the error again, but then I went into the JPC admin panel and edited it in there and removed the line. Everything is perfect now!

Thanks so much to everyone's willingness to help. It is greatly appreciated. I haven't moved hosts in years. Back then the number of files was minimal. This time it's different. I sure hope this is the last time. JPC, don't fail me now!

This is the culprit: þÿ

[jason]

A few tips for .htaccess files:

* They MUST be readable by Apache. If the server sees an .htaccess file in a directory list, but it can't open that file it will throw a 500 error.

* The must be uploaded to the server in Text/ASCII format (there should be a switch in your FTP program). This causes the FTP server to check and change endline characters to the native format for the OS the server is running. If Apache finds unexpected characters in the file, it throws 500 eror.

* All directives must be valid. If Apache can't understand even one line of the file it throws a 500 error.

In other words, Apache is very touchy when it comes to .htaccess files.

EliteRides, I'm glad you solved your problems. Good luck with the rest of your site move.

--Jason

[Gwaihir]

* The must be uploaded to the server in Text/ASCII format (there should be a switch in your FTP program).

That switch will probably say "binary / text / auto". If "auto" doesn't work for you, it's IMHO time to look for a new FTP-client; last time I had an issue with that auto-setting misguessing is years ago.

[Connie]

IMHO time to look for a new FTP-client; last time I had an issue with that auto-setting misguessing is years ago.

Maybe. I just had to reinstall WinSCP due to a PC rebuild. I always uploaded files based on the permissions on the server. Now WinScp installs files with all permissions at 644 regardless of the permissions that are on the server that file.

All I'm saying is that everything is not as black and white as we would like it to be.

[Vin DSL]

Maybe. I just had to reinstall WinSCP due to a PC rebuild. I always uploaded files based on the permissions on the server. Now WinScp installs files with all permissions at 644 regardless of the permissions that are on the server that file...

~