Emergency code change without dual control

General information

Complaint

[aug 3, 2009] Last week an attack was announced in media forums against CAs. This resulted in an ad hoc team coming together in CAcert to work on checking the situation (also assisting were Mark Lipscombe, Florian Lagg, Iang). Philipp Gühring checked the code and installed a quick fix [1] into the production webserver on the critical machine to block the addition of domains with NULLs in them. Potentially other fixes as well. Dirk Astrath wrote a quick attempt at a database scanning program, but had to hand it over to PG for completion. This may have been run at this point.

Security Policy 7.4 [2] says inter alia (amongst other things): "Each software change should be reviewed by a person other than the author

Yet, SP 3.2.3.1. _“emergency” patching_ provides that such a situation be referred to dispute resolution to provide the dual control. I therefore request the appointment of an Arbitrator to oversee and rule on emergency patching within the null-stuffing affair. I also request the Arbitrator to review this area of the SP and provide comments to the policy group, if possible.

Additional Information

Changeset

revision 1.142
date: 2009-07-31 23:25:38 +0200;  author: philipp;  state: Exp;  lines:
+8 -0;  commitid: yLEtVkDVQWsErUXt;
Added NullByte Prevention

cvs diff -r 1.141 -r 1.142 account.php
Index: account.php
===================================================================
RCS file: /var/lib/cvs/cacert/includes/account.php,v
retrieving revision 1.141
retrieving revision 1.142
diff -r1.141 -r1.142
423a424,431
>         if(strstr($_REQUEST['newdomain'],"\x00"))
>         {
>                         showheader(_("My CAcert.org Account!"));
>                         echo _("Due to the possibility for nullbyte
domain exploits we currently do not allow any domain names with
nullbytes.");
>                         showfooter();
>                         exit;
>         }
>

Ruling

The code change can be justified as an emergency code change as defined by Security Policy (SP) §3.2.3.1.

Comments

Dual control cannot be provided by arbitration since the arbitrator usually is not familiar with software development and the system configuration. For me as an arbitrator the changes look ok, however I do not have the background. So I asked for comments on the cacert-devel mailinglist - no objections were raised.

So "Application of patches in this case may occur as soon as possible, bypassing the normal configuration-change process." may be applied. Following that the review as of SP §7.4 is not needed.

"Emergency patch events must be documented within the regular summaries by the team leader to Board independent of filed disputes." This has been done by posting to the systemlog list.

All policies have been followed within this process. However SP is too permissive in this case. It is necessary that changes in emergency cases can be applied at once. But this should not ignore the review process, so there should be a post review in these cases.

Current WIP SP §7.6 shows a good intention here: "The Application Engineer is responsible for basic testing of functionality and emergency fixes, which then must be back-installed into the repositories." The requirements on the repository could be extended to have automated notifications on changes including complete changesets. With a large enough developer community there would automatically happen a review process once the changes are commited to the repository.

Policy is asked to review and change SP regarding these comments. Until a changed policy and supporting systems are in place, developers applying (emergency) changes to the code should show the changeset to the whole developer community for review via a documented channel. E.g. the cacert-devel or a new mailinglist for this purpose.

History

Arbitrations/a20090810.1 (last edited 2009-12-09 04:52:34 by UlrichSchroeter)