A typo on spip.net and a security hole in SPIP 1.9.2e

Thomas_Sutton · Septembre 25, 2008, 5:41

Hi lists,

This message is posted to both SPIP-EN@ and SPIP-DEV@

First, another problem on the English download page: the <meta name="description"/> tag on <http://www.spip.net/en_download> contains "$$version_stable$$" and "$$version_stable_date$$". Perhaps a script that should be replacing these values is broken?

Second, I've just encountered a possible security flaw in SPIP. I installed SPIP 1.9.2e on a server but had to move on to something else before beginning that project. I've come back to it today to find that someone has attempted to inject a link to baidu, possibly through #SPIP_CRON.

The home page of the site contained:

<div style=« background-image: url(‹ http://www.baidu.comhttp://www.baidu.com/spip.php?action=cron ›); »></div>

instead of (note that the name currently resolves to a different machine):

<div style=« background-image: url(‹ http://www.keturah.com.au/spip.php?action=cron ›); »></div>

The content of the link occurs only in this #SPIP_CRON output and was only present on disc in seven files, all in tmp/cache:

cache/3/-inc-dis-som-en.8fc1eb8f
cache/2/-inc-dis-som-en.f0e25501
cache/b/-inc_head-en.4aeaaaf7
cache/f/-inc-dis-som-en.1047297b
cache/skel/html_41532c9143f310ca5a5e6f0e2a669ffd.php
cache/d/-inc-dis-som-en.1ad56fbd
cache/d/-inc-dis-som-en.d158200a

In addition to the #SPIP_CRON output I noticed in the live page, the cache also contained the same broken link in places that call #URL_PAGE (in dist/inc-pied.html) like:

There are no modified files, no new files (except those created by the installer) and the only files missing files are those I deleted manually. The output of running diff -ru against a clean version of SPIP 1.9.2e is attached. I have a backup of the whole site including the "polluted" tmp/cache if it will help.

There are no CGI programs and no web applications installed except SPIP and Thelia. The only network services run on this machine are:

  • Apache2 with OpenSSL listening on ports 80 and 443
  • OpenSSH listening on port 22
  • MySQL listening on 127.0.01:3306

There is only one other person with access to this machine and all accounts are disabled or protected with strong passwords.

There were several things I should have done and did not (rm -rf ecrire/install/; chmod 755 config/; chmod 400 config/*), but given that the problematic content occurred only in the cache I suspect that this a run-time problem with SPIP's handling of GET/POST input.

Is this a known bug? Is it a problem with #SPIP_CRON and #URL_PAGE, or might it be more wide-spread? Is there anything else I can do to try to track it down?

Regards,

Thomas Sutton

Web Developer
bouncingorange
graphic + web design

diff.txt (6.75 KB)