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

Thu Jan 18 21:33:10 UTC 2007

NMS Software should not be placed in the public domain/internet.  By the
time anyone who would like to attack Cacti itself can access the server
and malform an HTTP request to run this attack, then can also go see
your entire topology and access your SNMP keys (assuming v1).  There is
this Network Management theory called Out of Band Management.  If you
are concerned about security, you should only be polling anything you
expect to be secure on a private management link/network.  If you want
to run an MRTG stats collector that is publicly visible and expect it to
be secure, write it yourself or purchase it from a vendor that can
support and guarantee the security of the product.

Cacti is a free open source tool, and in my opinion these should never
be expected to be 100% free of bugs, errors, and exploits.  If it is
that is great.  I would say you get what you pay for, but if you use
good practices around it, cacti can be a very useful and powerful tool.

That my 2 cents,

	-Scott

------------------------------------------------------------------------
------------
Scott Berkman CCNP
404-975-0097
Network Engineer
scott.berkman at reignmaker.net 

-----Original Message-----
From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of
Jon Lewis
Sent: Thursday, January 18, 2007 3:40 PM
To: Jeremy Chadwick
Cc: Gadi Evron; nanog at merit.edu
Subject: Re: FW: [cacti-announce] Cacti 0.8.6j Released (fwd)

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_________