FW: [cacti-announce] Cacti 0.8.6j Released (fwd)

Thu Jan 18 20:40:15 UTC 2007

On Thu, 18 Jan 2007, Jeremy Chadwick wrote:

> For those who don't have the time/care enough to go look
> at the Secunia report, I'll summarise it:
>
> 1) cmd.php and copy_cacti_user.php both blindly pass
>   arguments passed in the URL to system().  This, IMHO, is
>   reason enough to not run this software.

I've said this several times recently in less public places, but IMO, 
cacti is a bit of a security train wreck.  The glaring problem isn't that 
the above mentioned php scripts have poor security / user supplied input 
sanitization.  It's that those scripts were never intended to be run via 
the web server.  So WTF are they doing in a directory served by the web 
server in a default cacti install?  It seems to me, it would make much 
more sense for cacti to either split itself into 2 totally separate 
directories, one for things the web server needs to serve, one for 
everything else, or at least put all the 'web content' portions under one 
subdirectory of the cacti install directory, so that subdirectory can be 
either the DocumentRoot of a server or symlinked from elsewhere in a 
DocumentRoot.  There's no reason for things like poller.php or any of the 
others that are only meant to be run by the admin from the commandline to 
be in directories served by the web server.

I've heard from several people, and spent some time trying to help one of 
them, who had servers compromised (entry via cacti, then a local root 
compromise) over the past weekend due to this.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________