On Tuesday 06 May 2008 03:31:34 pm J.M.Roth wrote:
Just make sure that if you fix the problem (again), that the fix is in
the spirit of the actual Cacti security advisory.
afaik it is.
Currently, I am having a hard time seeing why exactly all these checks
are done. Maybe someone could elaborate? I only read something about XSS
and SQL injection. Why do these fixes prevent that?
afaik the vulnerability is that SCRIPT_FILENAME or PHP_SELF could be poisoned
in an XSS attack from a malicious link. this is a corner case as most people
administering cacti don't visit it by clicking on a link from some random
page on teh internets. furthermore, in most situations cacti is set up as an
internal service in a local network, usually not even advertised to the
outside world.
Apparently, they have all not been written for the scenario where Cacti
is used via Aliases in Apache.
this was the problem with the upstream fix, where it is wrongly assumed that a
cacti installation is always installed via being unpacked in the web root
(which has a seperate set of implications, and part of why that is not how
webapps should be installed in debian)
So instead of just doing something that makes the error disappear (and
potentially again creating security holes) please, someone who has the
insight, take a look.
afaik the problem is fixed. you and anyone else are of course encouraged to
give it as much scrutiny as you like.
furthermore i should just point out that the turnaround time for the
regression fix was less than 24 hours. regressions happen, mistakes are
made. after the fact, the only thing you can hope for is a quick and
effective response from the parties involved, which i think in this case was
quite satisfactory.
sean
signature.asc
Description: This is a digitally signed message part.
