Hi Jeff, thank you for bringing this up!
Halvar Flake (also formerly of P0) argues here that committing a patch is not very different from committing the test case: <http://addxorrol.blogspot.com/2019/08/rashomon-of-disclosure.html> Which is not something I'm willing to believe in totality. I think our sec-approval process is useful because it buys us some time. But it's important to care about timing once a patch is committed. The fact whether a bug is a sec bug is observable after all. Am 10.09.19 um 02:58 schrieb Jeff Walden: > 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
