Removing non-essential files from main CPG directory (for security reasons)

[slausen]

Hi-

I was wondering if there is a list of essential files for user operation of CPG.

I was looking through the main directory and I see that there is a "phpinfo.php" file as well as others that I would not want to be in a user-accessible directory such as "upload.php" or "delete.php".

I am thinking that I want to set up a separate "user install" directory that only contains the php files needed for basic browsing, search, comments, ratings, and favorites, without any of the admin-related stuff.

Is this an accurate list of the minimum set of files (from the CPG root) a CPG non-admin user would need to use the system?:

addfav.php
albums/
db_input.php
getlang.php
images/
include/
index.php
keyword_create_dict.php
keyword_select.php
keywordmgr.php
lang/
login.php
logout.php
profile.php
ratepic.php
scripts.js
search.php
searchnew.php (are both of these needed?)
showthumb.php
themes/
thumbnails.php
util.php

Thanks!

[Nibbler]

The versioncheck will tell you mandatory/optional files as do the docs in a section about a minimal installation. searchnew.php is used for batch adding only.

[slausen]

The versioncheck will tell you mandatory/optional files as do the docs in a section about a minimal installation. searchnew.php is used for batch adding only.

Hi Nibbler-

Thanks again! I did not even think to look at versioncheck for this info! The system I am working on is behind a firewall so I couldn't run versioncheck, but I looked in the code and found this, which I think has the info used by the script for the compare:

http://coppermine.sourceforge.net/repository.txt

But I notice that it designates files such as "install.php" and "installer.css" and "phpinfo.php" as mandatory. And the directory "sql/"is listed as mandatory also. It seems like maybe "mandatory" means "mandatory for install" to the versioncheck script.

Do you know of any way to find out which files are mandatory for end-user operation?

[Joachim Müller]

all those files that a regular user isn't meant to run are being protected by checks within the code that allows to file only to be run by the admin. Although you can savely remove install.php, there are other files that will certainly break your coppermine install when removed.
When using versioncheck, you could as well have unchecked the option "try connecting to the online repository" and you would have been fine just as well, even if your server dosn't have internet access.
This all sound to me like you're trying to give admin privileges to users you don't fully trust and that you're trying to harden the script by removing "critical" files you don't want those "untrusted" admins to mess with.
Coppermine is not unsecure because there are files within the package that are more harmful than others. Usually, if there are exploits being discovered, they exist within the core files (XSS vulnerabilities etc.), so removing "unneeded" files won't do anything.
As Nibbler suggested: remove the files suggested in the FAQ for minimal installs, leave the rest as-is.

[slausen]

all those files that a regular user isn't meant to run are being protected by checks within the code that allows to file only to be run by the admin. Although you can savely remove install.php, there are other files that will certainly break your coppermine install when removed.
When using versioncheck, you could as well have unchecked the option "try connecting to the online repository" and you would have been fine just as well, even if your server dosn't have internet access.
This all sound to me like you're trying to give admin privileges to users you don't fully trust and that you're trying to harden the script by removing "critical" files you don't want those "untrusted" admins to mess with.
Coppermine is not unsecure because there are files within the package that are more harmful than others. Usually, if there are exploits being discovered, they exist within the core files (XSS vulnerabilities etc.), so removing "unneeded" files won't do anything.
As Nibbler suggested: remove the files suggested in the FAQ for minimal installs, leave the rest as-is.

Hi GauGau-

I actually want to remove all the Admin functionality, for most users, and have only a few with Admin access.

This is for a project for a large company, with upwards of 4500 people with access to pictures of parts, and integration into their Order Entry system. But only a few people would get Admin access, and they have internal security requirements for all applications, and when I looked through the directory, I saw a lot of files that I would not want exposed to that many casual users. For example, the "phpinfo.php" and "/sql" directory.

I understand that you guys have taken steps to try and lock down the code.

But no one is perfect, and my approach is to err on the side of caution, especially when I am the one who is supposed to think through these kinds of issues for them. Another consideration is that a outside security audit of Coppermine has not even been done - so why are you so sure there are no holes? I am not saying Coppermine is unsecure, I just want to take every possible precaution to be on the safe side.

I am sure you can see that removing non-critical files from the user directory reduces the exposure of the box in the event that any expoits are discovered in the future. I mean, that is one of the great things about open source, right? You can actually make changes...

I looked for minimal install and I didn't see anything in the doc - which section is it in? FAQ? I will take another look at that.

[Nibbler]

http://coppermine-gallery.net/demo/cpg14x/docs/faq.htm#minimumInstall

The files in sql/ are plain text files that are part of the package. There are no possible security risks associated with them.

[slausen]

http://coppermine-gallery.net/demo/cpg14x/docs/faq.htm#minimumInstall

The files in sql/ are plain text files that are part of the package. There are no possible security risks associated with them.

Hi Nibbler-

Thanks for that link.

However, I have to say that comments like "there are no possible risks" associated with exposing the "/sql" directory worry me and are exactly why I want to make sure non-critical files are not accessible to users.

If you look just at what is inside the file "schema.sql", it contains:
-specific version information as to what CPG version is being run (malicious hacker could download an exact copy of source)
-all of the table and column names in the application (column names are often the same as PHP variable names)

Just out of cuiosity, what would be the reason for leaving a table creation script in a user-accessible location on a production system?

All I can say is that I have learned the hard way to be over-cautious when it comes to security.

[Nibbler]

This is open source software, the code is available to all. Complaining that people can find out the db structure is just silly. We make no effort to hide the version number, it is available from the HTML source.

[slausen]

This is open source software, the code is available to all. Complaining that people can find out the db structure is just silly. We make no effort to hide the version number, it is available from the HTML source.

Another petty "silly" comment.    Really, you guys are pretty arrogant given that most of the heavy lifting in Coppermine is done by Apache, Imagemagick, PHP, and MySQL. Where would you be if those teams had your attitude?

And the fact that you guys make no effort to hide the version number in the HTML is a security risk as well... if you got a security audit done, they would tell you that.

I will ask again: Just out of curiosity, what would be the reason for leaving a table creation script in a user-accessible location on a production system?

[Nibbler]

There is no reason to have the script delete it after installation. It is harmless. If you feel Coppermine is insecure then don't use it.

[Joachim Müller]

re phpinfo.php: try running it in your browser as regular user or guest - it's pretty safe imo.

The "missing" external security audit is being performed by thousands of users on the internet, that's the whole idea of open-source apps. Of course we're only human and make mistakes, and there have been security flaws that had crept into the code - they have been discovered by the community / some internet users and fixed. That's the idea of open source. If you don't trust this concept, then I recommend reviewing the whole idea of running an open source app at all and going for closed-source instead.

I come from a corporate network admin background (that's my day job), so I think I know what I'm talking about. I'm maintaining several open-source apps on the company's intranet (Typo3, Coppermine, SMF etc.), and so far none of the wannabe-hackers on the network managed to break them (however they broke several closed-source apps).

Really, you guys are pretty arrogant given that most of the heavy lifting in Coppermine is done by Apache, Imagemagick, PHP, and MySQL. Where would you be if those teams had your attitude?

Nobody said that you must use coppermine. If all the hard work is done by the other apps you mentioned, then it should be easy for you as the genius coder you claim to be to come up with an app like coppermine on your own. You're free to use coppermine, and you're free to come here to look for support. You're free to leave just as well. Just stop trolling, will you?

And the fact that you guys make no effort to hide the version number in the HTML is a security risk as well... if you got a security audit done, they would tell you that.

As suggested above, the security audit is done by the millions of users of the many thousands of coppermine-driven pages that exist on the net and the hackers out there. The version number is not being taken into account by search engine spiders, so an spreading like the infamous phpbb virus last year is unlikely. We explicitely output the version number for support reasons.
I've gone through security audits, and imo they're a waste of time and money: those guys just go through the book of possible flaws and network issues (most of them based on the dangers of the internet and on the work white-hat hackers have done on security issues) without actually providing a proof-of-concept hack. Yet the importance of security audits for corporate networks is irrelevant - as I suggested, the security audit done for opens-ource apps is the fact that they're open-source.

I will ask again: Just out of curiosity, what would be the reason for leaving a table creation script in a user-accessible location on a production system?

What would be the reason to hide it when everybody can get the information in that particular file by downloading coppermine and taking a look at the sources? However, if you're afraid of the data in the sql folder being abused, you're free to remove it.

[slausen]

There is no reason to have the script delete it after installation. It is harmless. If you feel Coppermine is insecure then don't use it.

I can see you disagree with me on this... no problem. You can bet that if the company doesn't feel Coppermine is secure they will not use it for this project.

It is interesting to me that you guys do not see any benefit to publishing which files are truly mandatory for end-user operation of the system, though. It seems like that would be useful...

OK, well thanks anyway for your participation in this thread, Nibbler.

[slausen]

The "missing" external security audit is being performed by thousands of users on the internet,

We explicitely output the version number for support reasons.

I can see you guys are on a different wavelength with me about this, so I am not going to try and convince you anymore, but I would ask you and the other Coppermine developers to consider two things:

1) Who will pay for the cost of security breaches encountered by customers running code that has not been through a real external security audit? Companies (losses) ? Consultants (sued)? Employees (fired)?

2) Customers often value security more highly than support costs. (which is why I am asking for this info)

If there is anyone else on the Coppermine team who knows the codebase well enough to give a quick answer or provide some direction before I start going through the code it would be much appreciated. Thanks.

[Joachim Müller]

1) Who will pay for the cost of security breaches encountered by customers running code that has not been through a real external security audit? Companies (losses) ? Consultants (sued)? Employees (fired)?

Does Microsoft (closed-source) pay for the cost of security breaches caused by flaws in their software? If yes, please give me the phone number of the person at M$ that I can call to get our money back...