[VIM] Verified ACal issue(s)

[Steven M. Christey]

I verified (source inspection) the ACal issues reported by alex at evuln.

Based on my read, the header.php/footer.php modification is RESULTANT
from the poor authentication issue.  The edit.php file clearly intends
to allow the admin to replace header.php and footer.php in their
entirety if need be, but it's only the poor authentication that lets
it occur.  My current thinking is that I'd argue that only the primary
issue - i.e. poor authentication - should be included, with PHP
execution as a consequence.  Although PHP hosting solution providers
might care about even letting ACal admins modify their own
header/footer code.

- Steve


======================================================
Name: CVE-2006-0182
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0182
Reference: MISC:http://evuln.com/vulns/25/summary.html
Reference: FRSIRT:ADV-2006-0152
Reference: URL:http://www.frsirt.com/english/advisories/2006/0152

login.php in ACal Calendar Project 2.2.5 allows remote attackers to
bypass authentication by setting the ACalAuthenticate cookie variable
to "inside".


======================================================
Name: CVE-2006-0183
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0183
Reference: MISC:http://evuln.com/vulns/25/summary.html
Reference: FRSIRT:ADV-2006-0152
Reference: URL:http://www.frsirt.com/english/advisories/2006/0152

Direct static code injection vulnerability in edit.php in ACal
Calendar Project 2.2.5 allows authenticated users to execute arbitrary
PHP code via (1) the edit=header value, which modifies header.php, or
(2) the edit=footer value, which modifies footer.php.  NOTE: this
issue might be resultant from the poor authentication as identified by
CVE-2006-0182.  Since the design of the product allows the
administrator to edit the code, perhaps this issue should not be
included in CVE, except as a consequence of CVE-2006-0182.