Exclude CPG version/revision from front-end files

[wilk]

Providing CPG version/revision in every .htm/css/js files is not necessary and leaks minor security information to potential attacker.

[Αndré]

That information is used by the versioncheck tool. Users are encouraged to keep their software up-to-date, so (in an ideal world) there shouldn't be an issue if potential attackers knows the version.

In cpg1.6.x the revision has already been dropped, but the Coppermine version number still exists for abovementioned reason. User's who are concerned about that information need to remove it themselves IMHO.

[wilk]

Well, I'm pretty sure there are hundreds of old installations. This is not an ideal world. People often do not have a time to keep up to date, especially when many changes were made to release code. Without checking for real vuln attacker mostly couldn't guess if this version has any known bugs.

Anyway the version tagging in files (here mostly the backend files as well) also makes updating quite difficult. Why? Because when we compare for differences and want to update only changed files and apply own patches we get 100% changed files. So actually every update is a nightmare of dropping a whole new release files onto server, applying personal patches, checking what to remove again (like readme's etc.) and finally checking what custom files were overwritten and recovering them (like favicon, site logo, custom image set).

There are at least two solutions which come to my mind now (both compatible with self):
- aside of full package there could be package with only changed files (similar to phpbb3 distros)
- drop the idea of file tagging and use file hashes - everything would stay on server side, we only need to know if a file was changed, but if we really need to know the actual version we could keep a list of hashes for previous versions (the list wouldn't be that long, because hash would change only when file was changed between versions - now because of version/release tags file looks as changed every time)

[Jeff Bailey]

You are right that there are plenty of old installations all over the web but no one here can be held accountable for the responsibility of website owners to upgrade regardless of reason.

TBH if an attacker is spending time manually checking version numbers of each site they are attacking the won't make it very far. Attacks are typically scripted and indiscriminate of version number, the attack runs and either fails or is successful. Writing a script to read Coppermine's version number before running attacks could be done but the time saved running it instead of running the attack directly would be negligible.

Anyway the version tagging in files (here mostly the backend files as well) also makes updating quite difficult. Why? Because when we compare for differences and want to update only changed files and apply own patches we get 100% changed files. So actually every update is a nightmare of dropping a whole new release files onto server, applying personal patches, checking what to remove again (like readme's etc.) and finally checking what custom files were overwritten and recovering them (like favicon, site logo, custom image set)

No offence but I think this argument is a little exaggerated.
Nothing forces a user to upgrade all the files in a new release, the version check may fail but it also fails if the user has any mods/patches present. It even says in the upgrade docs to backup any modded files (or to simply delete them from the new version download before uploading) and if no major changes have been made you can replace the newer files with your modded files or update the new files with your mod.
All websites require maintenance.

- aside of full package there could be package with only changed files (similar to phpbb3 distros)

git pull (--rebase if you have mods)
Shouldn't be uploading new version directly into production anyway IMHO, use a testbed and push updates from there to production.
Once 1.6 is the official release the whole process should get easier.

- drop the idea of file tagging and use file hashes - everything would stay on server side, we only need to know if a file was changed, but if we really need to know the actual version we could keep a list of hashes for previous versions (the list wouldn't be that long, because hash would change only when file was changed between versions - now because of version/release tags file looks as changed every time)

keep the version number present but obscure it?
or like git tag? I agree with this for bug fixes/build changes but still believe in major.minor.release versioning for releases.

Anyway this is all option and only really applies to the git repo but this is an open source project: https://github.com/coppermine-gallery

[wilk]

Attacks are typically scripted

That is correct, but why expose to public bits of information that are strictly for CPG admin's use?

Nothing forces a user to upgrade all the files in a new release, the version check may fail but it also fails if the user has any mods/patches present. It even says in the upgrade docs to backup any modded files (or to simply delete them from the new version download before uploading) and if no major changes have been made you can replace the newer files with your modded files or update the new files with your mod.
All websites require maintenance.

I do not use a versioncheck. Of course I keep patches against current version, but comparing old with new release gives almost 100% changes. Leaving some files from old releases would make a total mess in instalment and pose security threat. Yes, all need, but why make it in the hard way?

Shouldn't be uploading new version directly into production anyway IMHO, use a testbed and push updates from there to production.

I'm sorry, but I'm talking about single user, not a company with dozen of servers. In this case putting a 503 to public and uploading updates or changing the code is totally sufficient.

keep the version number present but obscure it?

No. I was talking about a database with hashes accessible only to the CPG versioncheck script, not for the whole world. Example structure:

Code Select Expand


a94a8fe5ccb19ba61c4c0873d391e987982fbbd3 file1.php 1.5.36
109f4b3c50d7b0df729d299bc6f8e9ef9066971f file1.php 1.5.38,1.5.40
3ebfa301dc59196f18593c45e519287a23297589 file2.php 1.5.36-1.5.40


Script would make a hash of file and browse this DB by hash+filename and retrieve valid version to know if it matches with current release (instead of checking written in plain text headers). DB could be hard-coded in php or kept in separate text file (excluded by .htaccess/chmod).

[wilk]

BTW. Why search by hash+filename (or rather path) not only hash? Because we can have few same files (for example those directory listing blockers like index.php files) named differently or at different paths, but introduced in different releases.