Hi, I'm taking this opportunity to share a new wiki page documenting guidelines for patching a core-security bugs: https://wiki.mozilla.org/Security/Firefox_security_bug_fixing
You'll find generic security principles about handling security bugs, as well as the detailed process for fixing security rated bugs. Should you be dealing with a security bug for the first time or wishing to refresh your memory, that's the place to go! For those of you who are familiar with the Bug Approval Process wiki page [1], you'll get similar information but specifically intended for a developers audience. Cheers, [1] https://wiki.mozilla.org/Security/Bug_Approval_Process On Tue, Sep 10, 2019 at 3:01 AM Jeff Walden <jwal...@mit.edu> wrote: > Those of you longer in the tooth may remember Firefox was successfully > exploited in Pwn2own 2012...and we didn't have to lift a finger to fix it. > We already had -- in the Firefox release shipping days later. 🤦 > > https://bugzilla.mozilla.org/show_bug.cgi?id=735104 (pwn2own bug) > https://bugzilla.mozilla.org/show_bug.cgi?id=720511 (cover bug, > discussion only of a spec-compliance issue) > https://bugzilla.mozilla.org/show_bug.cgi?id=720079 (sec bug noting the > sec issue) > > We later discussed whether the exploit had been "achieved" by reading our > public commits. https://bugzilla.mozilla.org/show_bug.cgi?id=735104#c2 > The fruit of this discussion was our security approval process, where > security patches land only after approval, in relative lockstep close to > release, with incriminating tests/comments removed. This is also where > sec-approval comment hoop-jumping began. > > sec-approval is a pain. Is it really worth it? > > The recent Apple iOS WebKit/JSC exploits conclusively answer "yes". The > Project Zero post > https://googleprojectzero.blogspot.com/2019/08/jsc-exploits.html > discusses the possibility that some exploits were acquired from published, > pre-release security fixes and testcases: > > > For many of the exploits it is unclear whether they were originally > exploited as 0day or as 1day after a fix had already shipped. It is also > unknown how the attackers obtained knowledge of the vulnerabilities in the > first place. Generally they could have discovered the vulnerabilities > themselves or used public exploits released after a fix had shipped. > > > > Furthermore, at least for WebKit, it is often possible to extract > details of a vulnerability from the public source code repository before > the fix has been shipped to users. > > > > CVE-2019-8518 > https://bugs.chromium.org/p/project-zero/issues/detail?id=1775 can be > used to highlight this problem (as can many other recent vulnerabilities). > The vulnerability was publicly fixed in WebKit HEAD on Feb 9 2019 with > commit < > https://github.com/WebKit/webkit/commit/4a23c92e6883b230a437bcc09f94422d7df8756c>. > This commit contains a testcase that triggers the issue and causes an > out-of-bounds access into a JSArray - a scenario that is usually easy to > exploit. However, the fix only shipped to users with the release of iOS > 12.2 on March 25 2019, roughly one and a half months after details about > the vulnerability were public. > > > > An attacker in possession of a working exploit for an older WebKit > vulnerability would likely only need a few days to replace the underlying > vulnerability and thus gain the capability to exploit up-to-date devices > without the need to find new vulnerabilities themselves. It is likely that > this happened for at least some of the following exploits. > > (paragraph breaks added) Incredibly, saying, "It is likely that > [attackers used public commits/testcases to create exploits]" *soft-pedals* > it. The first exploit the post discusses includes this text and image: > > > [T]he exploit trigger is almost exactly the same as in the bug report > and the regression test file in the WebKit repository. This can be seen in > the following two images, the left one showing the testcase published in > the WebKit code repository as part of the bugfix and the right showing the > part of the in-the-wild exploit code that triggered the bug. > > > https://1.bp.blogspot.com/-PEZlVLEefs0/XWg4BdDSxkI/AAAAAAAANUs/ELjHWgzHOZIRKSTV45E-moRivJKrAWIkACLcBGAs/s1600/JSC%2BDIFF.png > (alt text: "This image shows a line-by-line, side-by-side comparison > between the vulnerability test case from the webkit tracker on the left, > and the vulnerability trigger code used in the exploit on the right. They > are very similar, with matching variable names and code structure. The only > difference is that one value which had the fixed value 1.45 in the test > case has been parameterised out to a variable named ow in the exploit, and > the trigger has been wrapped inside a function definition which takes ow as > an argument.") > > The *only* difference between testcase and exploit is s/1.45/ow/. There's > no plausible way that similarity (including variable names) is > coincidental. Attackers (the Chinese government, it seems) copied the > testcase into a function, then changed the one bit of the test controlling > how a crash happens to make it usefully push-button. > > So if you ever questioned whether all that sec-approval nonsense is really > necessary...well, it is. Approvals, syncing up with release timelines, > getting rejected because too much risk, it's all pretty obnoxious. But > it's better we're careful for the users who aren't being exploited for one, > and it's better than the week WebKit/JSC are probably having now for two. > > Jeff > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
