13 replies to this topic

[trogan]

http://www.milw0rm.com/exploits/9556

As far as I can see this vulnerability is on all osCommerce 2.2 RC2a sites.

A quick way to ensure that you site is not vulnerable is to password protect the /admin directory. This can usually be done with your hosting control panel (such as Cpanel). Alternatively this can be done using htaccess, there are many guides around the internet on how to do this (e.g. http://www.javascriptkit.com/howto/htaccess3.shtml)

Trogan

[germ]

An excerpt from the script:

$admin_path = 'admin/';
$shellcode = "filename=fly.php&file_contents=test<?php%20@eval(\$_POST[aifly]);?>";
$message="POST ".$path.$admin_path."file_manager.php/login.php?action=save HTTP/1.1\r\n";

Looks like renaming the admin folder to something else (suggested on this forum all over the place) or removing the osC file manager (also suggested more times than I can count) would also provide immunity.

[SambaMambo]

i confirm that with an htaccess for the admin path resolve the problem
but it seems that the login.php has a whole so you can write files on the server.
does anyone know which line we have to correct to fix that security bug?

[germ]

Quote

but it seems that the login.php has a whole so you can write files on the server.

That would be an incorrect assumption.

Look at tne code example I posted.

It's file_manager.php doing the writing, not login.php

Remove file_manager.php or rename the admin folder (if you rename the admin folder you have to change the configure file too - don't be stupid).

Either one provides you immunity from this exploit.

[SambaMambo]

sorry... my mystake ...
yes it's file_manager.php not login.php (i was writing on it during my post... sorry for the mystake)
rename the folder doesn't change anything ...
with a good http scanner we can find easily where is the admin folder
i just asked if there is any bug correction available ... not a "delete file" solution ....

[germ]

My advice would be to do both - remove the file manager and rename the admin folder.

Problem solved.


Edit: AND add .htacess protection as the originator of this thread suggested.

That can't hurt either.

Edited by germ, 01 September 2009 - 01:23 PM.

[ecartz]

germ, on Sep 1 2009, 09:09 AM, said:

Either one provides you immunity from this exploit.

If by immunity you mean, "until they find out your admin folder name and change the script".  Renaming the admin folder does not provide what I would call immunity (nor even the lower bar of security).  It would prevent that script from working as written and in general stops automated scripts that rely on the admin folder being named admin.  Password protecting the directory and using https to access would provide security (not immunity).  Removing the file_manager.php would provide actual immunity from this exploit (may still leave other exploits open though; for example, is define_language.php vulnerable to the same kind of exploit?).  

Incidentally, setting up your server so that it doesn't allow the web user write access to files would prevent this entire class of exploit (and incidentally break file_manager.php and define_language.php).  This is what I mean when I say that requiring 444 permissions for includes/configure.php is less secure than allowing 644 permissions -- the server should not be able to write to any files, not just includes/configure.php.  If I was going to pick one file to replace to compromise an osCommerce install, it would not be includes/configure.php.  That's the file that I don't want others to read.  I would want to write to a different file.  

Unfortunately, it has become common to set things up with the account user as the web user.  These really should be two separate functions.  It used to be that way.  The web server ran as apache or whatever and each user had their own account.  Then there were problems with users compromising the accounts of other users, so they separated it.  However, they took a step back.  Instead of creating a new account for each web user, they started using the user account as the web user.  As a result, if your user account has the ability to edit a file, so does the web application.  It would be better to have a separate account for the web and the ability to chown files and directories (e.g. the images directory) to be owned by the web.  

For that matter, for osCommerce purposes, it would be better to have three accounts:  a catalog web user account, an admin web user account, and a regular user account.  The catalog account could have low permissions, just read on all files in the catalog directory (and its children -- not counting the admin directory, which can be put elsewhere).  The admin web account would have higher permissions, which allow writing to image folders and reading the admin directory.  The regular user account would have write permissions on all files.  By setting ownership and group settings correctly, the system would be secure in general, even in the face of buffer overflow exploits in apache that permit compromise of web users.  At worst, such a compromise would allow editing of files in the images directory, which with proper configuration in a <Directory> section in httpd.conf (so that PHP and other CGI scripts do not run from the images directory) is of limited use to a cracker.

[SambaMambo]

what if file_manager.php is needed?
i have a client that needs it because he doesn't know anything about FTP and FTP program
so it's easier for him to go thru the file_manager.php
so no solution for him? just learn how to manage a FTP with a FTP program?
file_manager.php is kind of "native" script of OSC and no one can fix it?
fixing a bug by delete a file doesnt fix anything ....

[spooks]

Do not use file manager, its a security risk & damages files, best removed.

http://www.oscommerce.info/kb/osCommerce/Common_Problems/15

Is it a good idea to let customers use a application that you know could damage the site when they use it.

There are alternatives if u search

[Adrian Bardt]

Im reading this .... thinking.?.?.?..?.?....  you guys have fixed this ?..... right?

[toyicebear]

The latest version 2.3.1 does not have this vulnerability. (Also 2.3.1 does not have a file manger)

[kelagedart]

The above links are broken.

Are there any working links to updating and securing 2.2rc2a?
Mine is a fully functional and heavily modded site so I wont be updating anytime soon....

[DunWeb]

@kelagedart

This is the only link you need to read about Rc2a


http://forums.oscommerce.com/topic/313323-how-to-secure-your-oscommerce-22-site/



Chris

[MrPhil]

SambaMambo, on 02 September 2009 - 12:39 PM, said:

what if file_manager.php is needed?
i have a client that needs it because he doesn't know anything about FTP and FTP program
so it's easier for him to go thru the file_manager.php
so no solution for him? just learn how to manage a FTP with a FTP program?
file_manager.php is kind of "native" script of OSC and no one can fix it?
fixing a bug by delete a file doesnt fix anything ....

Well, osC's File Manager was poorly written and insecure from the get-go. All of its functionality may be found in any hosting service's "control panel" and a good FTP client such as Filezilla. Given the choice of trying to fix osC File Manager's numerous problems, it was easier just to tell people to use their hosting service's built-in tools to accomplish these tasks.