Advanced search  

News:

cpg1.5.46 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter recently discovered vulnerabilities. It is important that all users who run version cpg1.5.44 or older update to this latest version as soon as possible.
[more]

Pages: [1]   Go Down

Author Topic: Exclude CPG version/revision from front-end files  (Read 1616 times)

0 Members and 1 Guest are viewing this topic.

wilk

  • Translator
  • Coppermine novice
  • **
  • Country: pl
  • Offline Offline
  • Gender: Male
  • Posts: 46
  • Wilk Wilkowy
    • #QuizPL @ IRCnet
Exclude CPG version/revision from front-end files
« on: June 18, 2016, 06:24:59 PM »

Providing CPG version/revision in every .htm/css/js files is not necessary and leaks minor security information to potential attacker.
Logged
PM me for Polish translations (new/update)

Αndré

  • Administrator
  • Coppermine addict
  • *****
  • Country: de
  • Offline Offline
  • Gender: Male
  • Posts: 15277
Re: Exclude CPG version/revision from front-end files
« Reply #1 on: June 20, 2016, 10:23:37 AM »

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.
Logged

wilk

  • Translator
  • Coppermine novice
  • **
  • Country: pl
  • Offline Offline
  • Gender: Male
  • Posts: 46
  • Wilk Wilkowy
    • #QuizPL @ IRCnet
Re: Exclude CPG version/revision from front-end files
« Reply #2 on: June 20, 2016, 05:54:42 PM »

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)
Logged
PM me for Polish translations (new/update)

Jeff Bailey

  • Dev Team member
  • Coppermine addict
  • ****
  • Country: us
  • Offline Offline
  • Gender: Male
  • Posts: 1325
  • Fishing relaxes me.
    • Bailey Family Co.
Re: Exclude CPG version/revision from front-end files
« Reply #3 on: June 21, 2016, 05:29:59 PM »

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
Logged
Thinking is the hardest work there is, which is probably the reason why so few engage in it. - Henry Ford

wilk

  • Translator
  • Coppermine novice
  • **
  • Country: pl
  • Offline Offline
  • Gender: Male
  • Posts: 46
  • Wilk Wilkowy
    • #QuizPL @ IRCnet
Re: Re: Exclude CPG version/revision from front-end files
« Reply #4 on: June 21, 2016, 08:18:47 PM »

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]
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).
Logged
PM me for Polish translations (new/update)

wilk

  • Translator
  • Coppermine novice
  • **
  • Country: pl
  • Offline Offline
  • Gender: Male
  • Posts: 46
  • Wilk Wilkowy
    • #QuizPL @ IRCnet
Re: Exclude CPG version/revision from front-end files
« Reply #5 on: June 21, 2016, 08:38:59 PM »

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.
Logged
PM me for Polish translations (new/update)
Pages: [1]   Go Up
 

Page created in 0.076 seconds with 20 queries.