Recent events, including vulnerabilities that were reported and the subsequent discussions about how they were handled, have made those of us that manage Asterisk development decide that it is time for the Asterisk project to have a formal security vulnerability and advisory reporting process. Over the next few weeks we will begin to formalize and document this process on the asterisk.org website, but here are the initial steps we are taking: 1) We will begin to assign our own advisory numbers and publish our own advisory reports when security issues are reported to us. 2) All code changes committed to our Subversion repositories will be tagged with the assigned advisory number, so that anyone can see exactly what code was affected and in what way, thereby easing the process for people who cannot upgrade to a new release and want to just backport the specific fix required for that vulnerability. 3) The advisory reports will include all information that is reported to us, and all information we learn while verifying and correcting the problem, including known exploit scripts and code and any other relevant information. 4) We will attempt, as best we can, to provide an accurate high-level summary and severity level for each advisory, so that end users can quickly determine which vulnerabilities they need to be concerned about. 5) We will post our security advisories to (at least) these mailing lists: - asterisk-security - asterisk-announce - asterisk-users - asterisk-dev - VOIPSEC (voipsec@xxxxxxxxxx) - bugtraq (bugtraq@xxxxxxxxxxxxxxxxx) - full-disclosure (full-disclosure@xxxxxxxxxxxxxxxx) - vulnwatch (vulnwatch@xxxxxxxxxxxxx) 6) We will post and archive all our advisories on the asterisk.org website, and provide an RSS feed for those who wish to watch the advisory listing page with automated newsreaders. 7) We will include the advisory numbers for every vulnerability that was addressed in any release of one of our projects. This process will begin with three vulnerabilities that are being posted today; these advisories were given advisory numbers ASA-2007-010, -011 and -012. We intentionally skipped -001 through -009 so that we can review this year's commits and publish official advisories for any other issues that have already been corrected and not properly reported. We appreciate everyone who provided their input into the discussions regarding our previous handling of security advisories. While not everyone was cordial and courteous with their comments, every opinion presented to us was taken into account and we are attempting to ensure that everyone will be satisfied with this new process. Obviously it is still a work in process and we welcome additional comments and input on ways that it could be improved. As always, thanks for supporting Asterisk, Zaptel and the other Asterisk-related projects!
|