Almost everyone decompress the drupal directory to server, and them CHANGELOG.txt is a potencial risk to exponse the version that drupal is in use.

Example
User1 download Drupal 6.0, and decompress the drupal directory to server;
Drupal release version 6.1 with Critical Bugs;
User2 see the the critical bugs in Drupal.org;
User2 go to User1 website http://www.siteexample.com/CHANGELOG.txt and discovery that can exploit User1 website.
User2 exploit User1 website.

So we can change CHANGELOG.txt to CHANGELOG.TXT.php
and add that code to the beginner of the file:

// No access from webserver
die( 'Restricted Access' );
CommentFileSizeAuthor
#5 block-CHANGELOG-213921-5.patch703 bytespwolanin

Comments

pwolanin’s picture

pwolanin commented
Title: CHANGELOG.txt is a potencial risk » *.txt is a potential risk
Priority: Critical » Minor

NOT critical. Critical means the code is badly broken.

Security-aware admins can already chmod these *.txt files, of course, since any or all might reveal the Drupal version. For the savvy hacker, there are many clues to which version of Drupal is running, so even this is no real assurance.

At most, I'd suggest adding a note to INSTALL.txt

int’s picture

int commented
Priority: Minor » Normal

"Security-aware admins can already chmod these *.txt files" but by default the files are exponse..

Joomla made this security, but if you don't matter with other (newbie) people...ok

"At most, I'd suggest adding a note to INSTALL.txt", not every people read this. And we can't make security depend of the user delete the file, or chmod.
Is quite easy to safe..

pwolanin’s picture

pwolanin commented

ok - this engendered some interesting discussion on IRC, on the pros and cons

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

We discussed in #drupal-dev for a /long/ time about this.

Joomla's solution to this is 1) a hack and 2) do-able because they're using a revision control system that can track revisions through file name changes. CVS cannot, without admin intervention.

So if we employed the same fix, we'd of course want to do so across both core /and/ contrib, which means driving dww completely batty with requests to manually edit server-side CVS files. Blarg.

So I advocate instead for a fix in .htaccess, that disallows direct viewing of specific file names (CHANGELOG.txt, README.txt, INSTALL.txt, etc.)

This both:
a) fixes the problem for core and contrib both.
b) enforces a good naming convention in contrib for these types of files.

Basically, we employ the same fix that prevents direct viewing of .module files. And if this protection goes away, you are screwed anyway, because an attacker can look directly at the exact line of code and see if you've patched it or not. :P

pwolanin’s picture

pwolanin commented
StatusFileSize
new block-CHANGELOG-213921-5.patch703 bytes

Here's a starter patch - only covers CHANGELOG and README

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Needs review » Closed (duplicate)

So it depends to what extent we want to protect these files from wandering eyes.

CHANGELOG.txt will identify the Drupal version down to the point release.
INSTALL*.txt and UPGRADE*.txt will identify the Drupal version down to the major release.
MAINTAINERS.txt, COPYRIGHT.txt, and LICENSE.txt /could/ change each major release.

I'd recommend at least INSTALL.* and UPGRADE.* being added to the filter.

By the way, this issue is a duplicate of http://drupal.org/node/79018. I'll move discussion over there.