The sec-approval process makes users safer

[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 
> .
>  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/NUs/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

Intent to Ship: line-height returns normal as a resolved value.

[Emilio Cobos Álvarez]

Summary: Return "normal" for line-height's resolved value (the value 
returned from getComputedStyle()) rather than a concrete pixel value, if 
the computed value is "normal".


This aligns us with Blink, and seems the best option according to 
various working group discussions, see below. In particular, normal maps 
to something that is not completely representable by pixel values.


This change has been on Nightly and Beta 69 without any known issues 
other than internal consumers (the fonts panel and thunderbird).


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1579624

Standard: CSSWG resolution in 
https://github.com/w3c/csswg-drafts/issues/4249


Platform coverage: All

Preference: layout.css.line-height.normal-as-resolved-value.enabled

DevTools bug: N/A, this works fine in inspector, and required a fix to 
the fonts panel that landed long ago.


Other browsers: Blink matches this change, WebKit matches (some version 
of) current Gecko behavior.


WPT: Added with the implementation in bug 1536871.

Secure contexts: N/A

Is this feature enabled by default in sandboxed iframes? Yes

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fennec moving to extended support

[gbrown]

On Thursday, April 25, 2019 at 7:10:58 PM UTC-6, Ryan VanderMeulen wrote:
> Hello everyone,
> 
> tl;dr: Fennec will be following the 68 train to ESR68-based release.
> 
> Why are we doing it?
> 
> We want to provide users with a secure and supported legacy Firefox for
> Android until Fenix has matured enough for users to migrate to it.
> Therefore, starting from Gecko 68, we plan to use the ESR68 repository as a
> stable base for managing Fennec engineering, testing, and release of builds
> going forward.
> 
> Will end users notice a difference?
> 
> There will be little to no user-visible changes from this change. Users
> will continue to receive new releases on the same cadence as before.
> 
> What should developers expect?
> 
> We specifically chose to make this decision now to take advantage of a new
> ESR cycle in order to minimize the overhead such a change entails.
> Backports of security fixes and other critical bugs will continue as
> expected. This change allows us to continue supporting Fennec for lower
> cost while we focus our development resources on GeckoView and Fenix.
> 
> Also, in case of unforeseen issues with this plan going forward, we are not
> planning to make any breaking changes to Fennec builds and tests on
> mozilla-central until after the start of the Gecko 71 cycle. Tests will be
> moved to Tier 2 status and run at lower frequency, however.
> 
> How long will we support Fennec?
> 
> While the ESR68 branch is due to be supported until late 2020, we are not
> committing to tying Fennec’s support lifespan to that timeframe. The
> decision for if and when to officially EOL Fennec will depend on our
> readiness to replace it, which is still TBD.
> 
> If you have any questions about this plan, don’t hesitate to reach out and
> I will do my best to follow up. Also, a more detailed project plan is
> available at the link below:
> 
> https://docs.google.com/document/d/1oRPkwP3l7QzdQYj0Wn7d_3EfTZaakocA_i_pGKlG0dI/edit?usp=sharing
> 
> Thanks,
> 
> Ryan

Bug 1577037 recently stopped running almost all tests against Fennec in 
trunk-based (Gecko 71) continuous integration and on try; most of these tests 
had been running as tier 2 and with reduced frequency for the last several 
months. Fennec tests continue to run on the esr68 branch and Fennec tests can 
still be run on try from an esr68 context.

A few Fennec Raptor tests continue to run on trunk at this time since they were 
not yet available on esr68; I hope those will be moved to esr68 soon.

A full range of tests running against geckoview apps continues to run on 
emulators (Android 7.0 x86-64) and hardware (Android 7.0 MotoG5, Android 8.0 
Pixel2) on all trees.

This seems like a good time to remind ourselves that Fennec is shipped from 
esr68 now: Any changes required for Fennec need to be applied to esr68.

- Geoff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform