* Case Number: a20120522.1 * Status: closed * Claimants: Marcus M * Respondents: CAcert * Initial Case Manager: AlexRobertson * Case Manager: MartinGummi * Arbitrator: EvaStöwe * Date of arbitration start: 2014-07-26 * Date of ruling: 2014-08-09 * Case closed: 2014-08-09 * Complaint: Possibility to save executable web code in the database * Relief: TBD Before: Arbitrator EvaStöwe (A), Respondent: CAcert (R), Claimant: Marcus M (C), Case: a20120522.1 <> == History Log == . 2012-05-22 (issue.c.o) case s20120522.229 . 2012-05-22 (C): accepts CCA/DRP in dispute filing . 2012-05-22 (iCM): added to wiki, request for CM / A . 2014-07-26 (CM): Appointed CM / A . 2014-07-26 (CM): send init mail to (C) . 2014-07-26 (A): placed case under seal . 2014-07-26 (A): Tested the bug on the testserver, it was working on !WoT15 for assurer, assuree, support, confirmed by (CM) . 2014-07-26 (A): entered private bug 1291 into bugtracker . 2014-07-26 (A): asked internal Auditor about his estimate. (phone) . 2014-07-26 (internal Auditor): recommends to seal the case (phone) . 2014-07-26 (A): decided to seal the case at least until bug is fixed . 2014-07-26 (A): asked board to confirm seal . 2014-07-26 (A): asked software team members to handle case with urgency and to review sql-queries . 2014-07-26 (A): addressed internal Auditor with the question why nobody had addressed the case or fixed the bug . 2014-07-26 (A): informs software team and internal Auditor about further tests for related bugs done by A and CM . 2014-07-27 (SA1): ok to sql-queries, also provides alternatives for 2nd query . 2014-07-27 (A): informs C about seal . 2014-07-27 (board): informs about entry of motion for seal into motion system . 2014-07-30 (SA2): ok to sql-queries, asks why SA2 only gave an alternative for 2nd query, query was tested on testserver . 2014-07-30 (A): describes SA2 the different approaches and why it would not make sense for the other field but as the alternative would only provide more false positives without providing more possilbe true positives wants to execute original queries. . 2014-08-04 (A): intermediate ruling, send to C, critical team . 2014-08-04 (board): approved the seal with motion Motion [[https://community.cacert.org/board/motions.php?motion=m20140727.1|m20140727.1]] . 2014-08-09 (SA1): informs A that critical was addressed with patch for bug 1291 (chat) . 2014-08-09 (critical team): informed about the installation of the patch and send the results of the sql-query encrypted to A and CM . 2014-08-09 (A): decides to remove the seal . 2014-08-09 (A): asks software team to set bug to public, announces the removal of the seal to C, software and critical team, board, internal Auditor . 2014-08-09 (A): final ruling send to C, software team, arbitration team, internal Auditor . 2014-08-09 (A): thank you to all involved parties . 2014-08-09 (CM): close case == Original Dispute == {{{ while testing today in the software telco we found out, that it is possible to save executable code in the WebDB through the any input. When opening a page with the executable code from the WebDB it is executed. see details below: Account with 2150 Points +CATS [Testserver details of 1st account] Account With 100 Assurances Points, 50 Experiens Points, CATS [Testserver details of 2nd account] Assurer With 100 Assurances Points, 50 Experiens Points, CATS Assure Someone https://cacert1.it-sls.de/wot.php?id=5 Name 9 autotest DoB 1950-01-01 (JJJJ-MM-TT) Location: Date Checkboxes 1 1 0 Punkte: Msg: "In Kürze werden Sie und die von Ihnen bestätigte Person eine E-Mail-Bestätigung erhalten. Es ist dafür von Ihrer Seite aus nichts weiter zu tun." I accept CCA and DRP }}} * '''Link to Arbitration case [[Arbitrations/priv/a20120522.1|a20120522.1 (Private Part)]], Access for (CM) + (A) only)''' <> ==== EOT Private Part ==== ---- == Preliminary Considerations and Activities == After picking up the case some things were unclear: 1. Was the bug solved? 1. Was there a bug entered in the bugtracker? 1. Why was a case about a security relevant bug that may be unsolved not picked up by arbitration? 1. What does the claimant ask with the dispute? 1. Should the case be sealed? === Was the bug solved? === The first step was to check if the bug could be reproduced. If it could be reproduced on the testserver it would also be open on the productive server. Some tests by A and CM showed: * The bug was not solved at least for the "new calculation" (WoT 15). * Some other fields and pages were tried for the same exploit === Bugtracker-Entry === The next step was a search for a bug entry for this bug in the bugtracker. Non was found. Bug Bug:1291 was entered. (Look there for more details about the bug and the tried exploits). === Why was the bug and the case not attended for over 2 years? === The bug was discovered in a software team session. It looks like the decision back then was to enter this dispute and to wait for arbitration to pick it up. Also it may be that the software team thought the bug to be fixed as it was not working for the old calculation (!WoT10). At the same time it looks like nobody of the arbitration team thought the case to be relevant enough to pick it up for two years. This may be because the dispute is quite technical and does not ask arbitration for anything to do. As the dispute was also filed out of a software session, maybe the arbitrators thought that the bug probably was treated so that there may no need to pick it up, soon. Even if that would be the case, possible exploits may have been working based on the kind of the fix, so even this can be considered to be a little bit careless. However the question why the case was not picked up for some time, is not the focus of this case, even if it is an important question. As this is obviously not covered by the dispute, the only action here was to inform the internal Auditor about the issue and to hope that he will follow this and find some advice how to prevent that other security relevant cases will stay unattended in the future. Beside of this the teams can only be encouraged to install some kind of prioritisation system to ensure that security relevant issues are attended, soon. === Domain of the Dispute === The domain of the dispute was considered to be to ensure that the bug was fixed and to find possible exploits based on the bug. === Sealing of the case === At the time the case was picked up, the bug was open. It was not clear when it would been solved and how long it would take to ensure that there was no way to exploit it further. Any sensible documentation of the case and especially intermediate rulings (which would have to be posted when there is no seal) would invite people to exploit the bug further and by this possibly harm other members. Because of the possible attack the internal Auditor suggested to seal the case at least until the bug was fixed. The Arbitrator decided to follow the advice of the internal Auditor and seal the case until it was ensured that the bug was fixed and possible exploits analysed. ---- == Discovery == === Security relevance of the bug === Because of the bug it was possible to enter anything into the location field of assurances. As long as it was possible to enter free texts into the date field of the assurance, the same seem to be true for that field. By this is was possible to enter scripts into this fields. Those scripts would be executed every time the contents of the fields were displayed by the software. * List of points / assurances of the assurer * List of points / assurances of the assuree * List of points / assurances for accounts in the support view. A possible attacker could have tried to execute a script or to take over the session of someone else, for example a support engineer (by asking to take a look at the points based on some other complaint). === Bug fix === * 2014-07-26 The bug was entered and confirmed as Bug Bug:1291 to the bugtracker. * 2014-07-27 A patch was applied to the testserver and reviewed by a SA, some tests and adjustmends were made * 2014-07-28 Second review was added * 2014-07-29 Last test added * 2014-08-05 Enough tests and reviews present, patch set to "ready to deploy" * 2014-08-09 Software team asks critical team to deploy patch on the productive server * 2015-08-09 Patch applied by critical team The bug is fixed, now. 1. Any entry in free fields gets escaped before entered in the DB. 1. Before any none-escaped entry is displayed it is escaped temporarly to prevent its execution. === Handling of possible exploits === Any relevant exploit of the bug would have contained a combination of "<" and later ">". As most browser allow to execute also scripts that are missing closing "", they would not be needed for an exploit-attempt. To find possible exploits a search for "<" followed by anything and ">" in the affected fields (location and date of assurances) was needed. As a combination of both characters is seldom needed to describe a location and never needed to describe a date, the chance to hit false positives was considered to be relatively small. The Arbitrator decided to search for possible exploits with two SQL-queries that would provide any assurance id and location/date entry for assurances with location/date entries that contain "<" and later ">". While the location field is a sensible field regarding the privacy of our members, stand alone it does not reveal anything about any special member. The connection to the member would only be needed if an exploit would be found. This would require a second search in the case The assurance id would be helpful to get an idea of time frames of any exploits (for both fields) is some were found. But it would not point to any member as any member can assure any member at any time and order. As long as the identity of the assurer and the assuree is not looked up afterwards the privacy of the affected members would be kept as best as possible while searching for possible exploits. The following SQL-query were approved and tested by two software assessors: {{{#!highlight sql SELECT `id`,`location` FROM `notary` WHERE `location` LIKE '%<%>%'; SELECT `id`,`date` FROM `notary` WHERE `date` LIKE '%<%>%'; }}} One alternative for the date was discussed but dismissed by the Arbitrator. The execution of the queries (see Intermediate Ruling) provided 5 hits. All of them were classified as non-exploiting, uncritical false positives by the critical team lead and the Arbitrator and CM of this case. ---- == Sealing history == . 2014-07-27 This case was set under seal by the Arbitrator. . 2015-08-04 One intermediate ruling was issued by the Arbitrator and kept under seal (and noted in the case file). . 2014-08-04 The seal was approved by board with motion m20140727.1. . 2015-08-09 The seal was removed by the Arbitrator. While the seal was set, all communication was done encrypted and excluded from the archive (as it cannot handle encrypted mails). At the same time the internal Auditor was included in said communication as an additional pair of eyes to ensure correct handling of the case. (However the result-set of the queries was kept private between critical team, A and CM.) ---- == Ruling == === Intermediate Ruling === After applying the patch for bug #1291 with the normal procedures, Critical Team should execute the following two SQL-queries and send the results encrypted to the Arbitrator and Case Manager of a20120522.1: {{{#!highlight sql SELECT `id`,`location` FROM `notary` WHERE `location` LIKE '%<%>%'; }}} and {{{#!highlight sql SELECT `id`,`date` FROM `notary` WHERE `date` LIKE '%<%>%'; }}} As the patch for bug #1291 is currently not approved by software team the execution of this ruling has to wait until software team finishes their work on it. -- In a train between Osnabrück and Bremen, 2014-08-04 === Final Ruling === The bug reported in the dispute was found open. It is fixed now. A search for exploits was done. The bug was not exploited. No harm was found, so no action against anybody is required. One additional point has to be addressed: The bug was found during a software session but not covered with a bug-entry until the case was picked up by the Arbitrator. This was over two years after the bug was found. The question remains why the case and the bug were not attended for so long. This question is not covered of the dispute so it should not be treated in this case. The internal Auditor was informed about it and may consider further actions. Additionally software team and arbitration team should be advised to find ways to ensure that security relevant cases and bugs are treated without delay. Software team already categorises bugs for urgency. It would be a good idea to do so for arbitration cases, as well. As the arbitration team probably was not aware of the security relevance and thus urgency, it would have been the duty of the claimant to ask the iCM or DRO for urgent treatment of the case. Any member who is aware of a security relevant issue has the duty to ensure that they are resolved (see SP 9.1.6.). -- Cologne, 2014-08-09. == Execution == . 2014-08-04 (A): intermediate ruling, sent to C, critical team . 2014-08-09 (critical team): executed intermediate ruling, send results encrypted to A, CM . 2014-08-09 (A): final ruling send to C, software team, arbitration team, internal Auditor . 2014-08-09 (A): thank you to all involved parties == Similiar Cases == || [[Arbitrations/a20140422.1|a20140422.1]] || [[Arbitrations/a20140422.1|Gather evidence about the SQL injection/ shell execution discovered in #1272]]|| || [[Arbitrations/a20140322.1|a20140322.1]] || [[Arbitrations/a20140322.1|Maybe lost information in the database]]|| || [[Arbitrations/a20120614.1|a20120614.1]] || [[Arbitrations/a20120614.1|Emergency Patch]]|| ---- . CategoryArbitration . CategoryArbCaseSystemTasks . CategoryArbCaseOthers