Closed Bug 850069 Opened 7 years ago Closed 7 years ago

Disable DirAuto for Firefox 20

Categories

(Core :: Layout: Text and Fonts, defect)

20 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
firefox19 --- unaffected
firefox20 + fixed
firefox21 --- unaffected
firefox22 --- unaffected
firefox-esr17 --- unaffected
b2g18 --- unaffected

People

(Reporter: dveditz, Assigned: smontagu)

Details

(Keywords: sec-other, Whiteboard: [adv-main20-])

Attachments

(1 file)

DirAuto is a bidi-related text feature supported starting in Firefox 20 (bug 548206). There have been a considerable number of regressions, many of which have been potentially exploitable security problems.

https://bugzilla.mozilla.org/buglist.cgi?keywords=regression%2C%20&keywords_type=allwords&f1=blocked&o1=equals&v1=548206

Not all of the above fixes have been backported to Firefox 20, and new ones are still coming in. bidi code has historically been fragile and this feature bears that out. It should bake for another cycle so we don't expose our users to risk.

I don't believe there is a pref for this feature. It would be risky to try to back-out all the code but maybe we could change the parser to ignore the attribute. Would that be safe? It would not be the same as the code that existed before the feature landing but hopefully the regressions are coming from us applying the feature and wouldn't happen in cases where we didn't. I haven't seen any regressions blamed on bug 548206 that did not use the DirAuto attribute so it might be a workable approach. (I should look more thoroughly though.)
tracking-status20+ because release-drivers need to "track" this issue one way or another, not prejudging their decision that a fix is less risky than carrying on.

Although this bug is rated "sec-other" (it's not describing a specific security flaw) most of the security regressions that have been fixed have been sec-critical use-after-frees. If there are more bugs lurking I would expect them to be of that type and potential severity.
Yes, I agree that we should do this.  Unfortunately, I can't think of an easy kill-switch.  :(  Maybe Simon can?
Assignee: nobody → smontagu
I agree we need another cycle before releasing this feature. There's no oneliner kill-switch, but it won't be particular hard just to back out all the code, most of which is isolated in DirectionalityUtils.
Status: NEW → ASSIGNED
(In reply to Simon Montagu from comment #3)
> I agree we need another cycle before releasing this feature. There's no
> oneliner kill-switch, but it won't be particular hard just to back out all
> the code, most of which is isolated in DirectionalityUtils.

Can back this out before Tuesday afternoon? a=akeybl

We don't have an opinion on disabling versus backing out. Disabling is probably lower risk functionally, but backing out may be lower risk security-wise.
Attached patch Backout patchSplinter Review
Attachment #726709 - Flags: review?(ehsan)
Comment on attachment 726709 [details] [diff] [review]
Backout patch

Review of attachment 726709 [details] [diff] [review]:
-----------------------------------------------------------------

I didn't do a proper review since this is a backout of all of this stuff.  If there's something that actually needs review, please let me know.
Attachment #726709 - Flags: review?(ehsan) → review+
https://hg.mozilla.org/releases/mozilla-beta/rev/2192bce8badc
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [adv-main20-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.