(In reply to :Gijs (he/him) from comment #0)
In bug 1538007, we were faced with the possibility of a sandbox escape executed by installing a malicious language pack. While we've made a number of changes to Firefox, especially on 68 onwards, to defeat this attack in the product, as part of defense in depth improvements and to help protect users on older versions (especially ESR), it would be desirable to refuse to sign language packs that contain markup in their locale strings that doesn't pass some sanitizer list of allowed element/attribute/value combinations.
Can you provide that list? How are the mitigations done in Firefox?
(In reply to Kris Maglione [:kmag] from comment #3)
(Note: We're coming up on their standard disclosure deadline next week, so we really can't bank on more than a few days)
I think that a few days is a bit unrealistic since we'd probably be needing to make something from scratch to sanitize these formats, unless something pre-exists, also there are some issues with sanitization - see my next comment:
(In reply to Kris Maglione [:kmag] from comment #6)
This is about third-party language packs uploaded for signing by users, not langpacks generated in automation. We're relatively confident in the safety of the latter.
(In reply to Jorge Villalobos [:jorgev] from comment #5)
Is there a spec somewhere of what's supposed to be allowed or disallowed in a langpack?
Essentially, we just need to disallow any entities with markup that contains scripts, either as
<script> tags, or elements with event handler attributes or
data: URLs. Running them through a standard markup sanitizer and checking that it doesn't remove anything would probably be sufficient.
Unfortunately it's not that easy, because if I look at the english lang pack on AMO the file chrome/en-US/locale/en-US/global/dom/dom.properties contains the string <script> for translations like so:
ScriptSourceLoadFailed=Loading failed for the <script> with source “%S”.
If I ran that through a markup sanitizer like DOMPurify that would just strip out the <script> and everything after it but in this case it's benign. Since sanitization is context sensitive so I'm not sure how viable it is to sanitize up front since we don't have knowledge of the way each string is being consumed.
I presume backporting the client mitigations to older versions to alleviate the potential threat has been already discounted?