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
