Closed Bug 1382260 Opened 7 years ago Closed 7 years ago

[mac] Sandbox breaks font rendering for users with fonts managed via Linotype FontExplorerX or RightFont

Categories

(Core :: Security: Process Sandboxing, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla57
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 + fixed
firefox57 + verified

People

(Reporter: emanuela, Assigned: haik, NeedInfo)

References

Details

(Keywords: regression, Whiteboard: [gfx-noted] sb+)

Attachments

(7 files)

Version: Nightly 56.0a1 (2017-07-18) (64-bit)

OS: MacOs Sierra 10.12.5

Problem: fonts are not displayed on https://www.messenger.com/

How to replicate:

1. Go to https://www.messenger.com/
2. See all the characters replaced with [?] (see the attachment)

Note: I tested it Firefox releaseand didn't see the problem
Hmm, I did not see the problem of STR on Comment 0 with my mac(10.12). Can you still produce the problem with latest nightly? And can you provide information of Graphics section from about:support?
Flags: needinfo?(emanuela)
Yes, I'm still able to reproduce it :-/ 

Application Basics
------------------

Name: Firefox
Version: 56.0a1
Build ID: 20170725100255
Update Channel: nightly
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0
OS: Darwin 16.6.0
Multiprocess Windows: 2/2 (Enabled by default)
Web Content Processes: 4/4
Stylo: false (disabled by default)
Google Key: Found
Mozilla Location Service Key: Found
Safe Mode: false


Graphics
--------

Features
Compositing: OpenGL
Asynchronous Pan/Zoom: wheel input enabled; scrollbar drag enabled; keyboard enabled
WebGL 1 Driver WSI Info: CGL
WebGL 1 Driver Renderer: Intel Inc. -- Intel(R) Iris(TM) Graphics 6100
WebGL 1 Driver Version: 2.1 INTEL-10.25.13
WebGL 1 Driver Extensions: GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_separate_stencil GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_barrier GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod
WebGL 1 Extensions: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_frag_depth EXT_sRGB EXT_shader_texture_lod EXT_texture_filter_anisotropic MOZ_debug OES_element_index_uint OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc MOZ_WEBGL_depth_texture
WebGL 2 Driver WSI Info: CGL
WebGL 2 Driver Renderer: Intel Inc. -- Intel(R) Iris(TM) Graphics 6100
WebGL 2 Driver Version: 4.1 INTEL-10.25.13
WebGL 2 Driver Extensions: GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier
WebGL 2 Extensions: EXT_color_buffer_float EXT_texture_filter_anisotropic EXT_disjoint_timer_query MOZ_debug OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context MOZ_WEBGL_lose_context MOZ_WEBGL_compressed_texture_s3tc
Audio Backend: audiounit
GPU #1
Active: Yes
Vendor ID: 0x8086
Device ID: 0x162b

Diagnostics
AzureCanvasAccelerated: 1
AzureCanvasBackend: skia
AzureContentBackend: skia
AzureFallbackCanvasBackend: none
TileHeight: 1024
TileWidth: 1024
Decision Log
WEBRENDER:
opt-in by default: WebRender is an opt-in feature
Flags: needinfo?(emanuela)
:jfkthame, can you comment to the bug?
Flags: needinfo?(jfkthame)
This looks similar to bug 1340351, though we landed a patch to address the specific case there. Still, I think it'd be worth looking through the issues discussed there to see if there may be anything relevant.

emanuela, have you adjusted any font-related preferences (e.g. for downloadable fonts)? Does the problem occur with a fresh profile? Are you using some kind of font manager (like the Adobe creative cloud "font sync" utility) to activate fonts on your system? Do any error messages show in the system console (Console.app), similar to bug 1340351 comment 32? Any errors in the Browser Console in Nightly?
Flags: needinfo?(jfkthame) → needinfo?(emanuela)
Yes, I'm using FontExplorer X Pro 6 v 6.0.2 to manage my font!

This is what the console gives to me in Nightly when I’m on messenger.com

t_start www.messenger.com:3:1251
Unknown property ‘-moz-outline-style’. Declaration dropped. DW0RQ50L-Hw.css:1:375
Unknown property ‘zoom’. Declaration dropped. I-QFzQP6tS-.css:1:120
Error in parsing value for ‘image-rendering’. Declaration dropped. UzrFajKU-8F.css:2:223
Error in parsing value for ‘image-rendering’. Declaration dropped. UzrFajKU-8F.css:2:257
Expected color but found ‘invert’. Error in parsing value for ‘outline-color’. Declaration dropped. UzrFajKU-8F.css:29:188
Expected color but found ‘invert’. Error in parsing value for ‘outline-color’. Declaration dropped. UzrFajKU-8F.css:34:68
Unknown property ‘zoom’. Declaration dropped. dWFTfAOoezd.css:2:71
Unknown property ‘zoom’. Declaration dropped. dWFTfAOoezd.css:2:254
Unknown pseudo-class or pseudo-element ‘last’. Ruleset ignored due to bad selector. 5L2CUBSuXD8.css:7:672
Error in parsing value for ‘display’. Declaration dropped. VaskMrbHMuj.css:5:15
Expected end of value but found ‘�’. Error in parsing value for ‘background-size’. Declaration dropped. VaskMrbHMuj.css:8:33
Error in parsing value for ‘word-break’. Declaration dropped. VaskMrbHMuj.css:9:152
Unknown property ‘tab-size’. Declaration dropped. VaskMrbHMuj.css:9:358
Unknown property ‘zoom’. Declaration dropped. ufkuj5tnblS.css:1:62
Expected end of value but found ‘1px’. Error in parsing value for ‘border’. Declaration dropped. jfBmnyge6hC.css:10:46
Error in parsing value for ‘color’. Declaration dropped. jfBmnyge6hC.css:10:212
Error in parsing value for ‘word-break’. Declaration dropped. jfBmnyge6hC.css:14:521
Unknown pseudo-class or pseudo-element ‘-ms-clear’. Ruleset ignored due to bad selector. O5qyi07GhJi.css:1:245
Unknown pseudo-class or pseudo-element ‘-ms-clear’. Ruleset ignored due to bad selector. O5qyi07GhJi.css:9:993
Unknown pseudo-class or pseudo-element ‘-ms-clear’. Ruleset ignored due to bad selector. xBP_99KBUxA.css:2:762
Unknown pseudo-class or pseudo-element ‘-webkit-input-placeholder’. Ruleset ignored due to bad selector. xBP_99KBUxA.css:2:1280
Unknown pseudo-class or pseudo-element ‘-ms-input-placeholder’. Ruleset ignored due to bad selector. xBP_99KBUxA.css:2:1446
Unknown pseudo-class or pseudo-element ‘-webkit-input-placeholder’. Ruleset ignored due to bad selector. xBP_99KBUxA.css:2:1525
Unknown pseudo-class or pseudo-element ‘-ms-input-placeholder’. Ruleset ignored due to bad selector. xBP_99KBUxA.css:2:1691
Unknown pseudo-class or pseudo-element ‘-ms-clear’. Ruleset ignored due to bad selector. xBP_99KBUxA.css:18:239
Unknown pseudo-class or pseudo-element ‘-ms-clear’. Ruleset ignored due to bad selector. xBP_99KBUxA.css:27:766
Unknown pseudo-class or pseudo-element ‘-ms-clear’. Ruleset ignored due to bad selector. xBP_99KBUxA.css:35:630
Unknown property ‘tab-size’. Declaration dropped. wSKUqwZpVuO.css:1:367
Error in parsing arguments for filter function. Error in parsing value for ‘filter’. Declaration dropped. NdVFWOZEM3Y.css:2:1618
Unknown property ‘-moz-border-radius’. Declaration dropped. i2qbsjHtJvI.css:1:62
Expected media feature name but found ‘-webkit-min-device-pixel-ratio’. 3VRRxGbzztb.css:43:1891
Expected media feature name but found ‘-webkit-min-device-pixel-ratio’. 3VRRxGbzztb.css:43:2026
Error in parsing value for ‘width’. Declaration dropped. eleonora.margaret
t_domcontent www.messenger.com:3:1251
t_tti www.messenger.com:3:1251
t_prehooks www.messenger.com:3:1251
t_hooks www.messenger.com:3:1251
t_layout www.messenger.com:3:1251
perf_trace {"name": "e2e", "parent": "PageEvents.BIGPIPE_ONLOAD"} ioy2KO8VWv5.js:127:2619
t_paint www.messenger.com:3:1251
["add",{"textareas":[],"contenteditables":[],"iframes":[],"htmlghosts":[]}] bundle.js:8321:29
Error in parsing value for ‘width’. Declaration dropped. eleonora.margaret
POSTXHR
https://www.messenger.com/mercury/unseen_thread_ids/
GETXHR
https://0-edge-chat.messenger.com/pull
POSTXHR
https://www.messenger.com/ajax/mercury/mark_seen.php
GETXHR
https://0-edge-chat.messenger.com/pull
GETXHR
https://0-edge-chat.messenger.com/pull
[HTTP/2.0 200 OK 19236ms]
GET
https://static.xx.fbcdn.net/rsrc.php/v3/yj/l/0,cross/UzrFajKU-8F.css
POSTXHR
https://www.messenger.com/ajax/bz
GET
https://static.xx.fbcdn.net/rsrc.php/v3/yu/l/0,cross/TNQWHDv1TWD.css
GET
https://static.xx.fbcdn.net/rsrc.php/v3/yb/l/0,cross/DW0RQ50L-Hw.css
GET
https://static.xx.fbcdn.net/rsrc.php/v3/yi/l/0,cross/XSHUrCgKov2.css
GETXHR
https://0-edge-chat.messenger.com/pull
[HTTP/2.0 200 OK 13249ms]
GETXHR
https://0-edge-chat.messenger.com/pull
Flags: needinfo?(emanuela)
That's from the web console or browser console within Nightly, right? What about any messages that appear in the system console, Console.app (normally found in /Applications/Utilities, if you're not familiar with it). I'm particularly looking for any Sandbox-related messages, similar to that seen in bug 1340351 comment 32, or any messages that appear to relate to font files or the FontExplorer program.
Flags: needinfo?(emanuela)
Also, does setting security.sandbox.content.level to 1 in about:config (and restarting the browser, I presume) resolve the problem for you?
Whiteboard: [gfx-noted]
Attached image fontexplorer-setup.png
Pretty sure this is a sandbox-related issue, very much like bug 1340351. I took a brief look at FontExplorerX, and notice that during setup, it offers to "Organize" the user's fonts, which apparently can involve moving the files to a new location, potentially "outside of the System, User or Application directories"; see screenshot.

If a user takes advantage of this, the font files may end up somewhere entirely different, and the content process will then be blocked from accessing them by our sandbox rules.

(Even if the user doesn't let FontExplorerX "organize" all their existing fonts, I suspect that any additional fonts purchased and activated via the application will probably be in a new location; I didn't go that far with it.)

Given that FontExplorerX doesn't guarantee the font files will be in any specific location that we can add to the sandbox rules, I'm not sure what we can do about this.
Haik, if I'm understanding this correctly, it looks like the content-process sandbox is potentially going to cause bad breakage for users who have the Linotype FontExplorerX utility. Is there something we can do to address this?
Blocks: 1332190, 1377522
Flags: needinfo?(haftandilian)
Hmmmmm, so we currently allow access to the Adobe Livetype directory (https://dxr.mozilla.org/mozilla-central/source/security/sandbox/mac/SandboxPolicies.h?q=SandboxPolicies.h&redirect_type=direct#254), but that relies on the fact that there's a stable location for it.

Unless FontExplorerX has a stable install directory, or the OS provides an API for locating font installation directories, I'm not sure we have a fix until font loading is remoted.
Summary: fonts not displayed (() on facebook messenger → [mac] Sandbox blocks access to Linotype FontExplorerX font directory
(In reply to Jonathan Kew (:jfkthame) from comment #9)
> Haik, if I'm understanding this correctly, it looks like the content-process
> sandbox is potentially going to cause bad breakage for users who have the
> Linotype FontExplorerX utility. Is there something we can do to address this?

As Alex said, we could whitelist the directory where FontExplorerX is storing the fonts, but we need to know where it is at runtime. However, if there is a default location, and most users use that default, we could start with that.

But I suspect there's some way in OS X to enumerate active font directories because the system needs to be able to find them.

With build 56+, to get sandbox violation logging, security.sandbox.logging=true must be set.

emanuela, could you try setting the pref security.sandbox.logging=true, then restarting the browser, and then reproducing the problem. Before you do that, startup the OS X Console app and filter on plugin-container. Then when you reproduce the problem, you should see some sandbox violations related to your font directories.
Flags: needinfo?(haftandilian)
emanuela, if you run the tryserver build of Nightly from https://treeherder.mozilla.org/#/jobs?repo=try&revision=355c420847057affe4bfa709375c6b3887ad616a (see [1] for the actual download), does this solve the problem (without altering sandbox settings)?

[1] https://queue.taskcluster.net/v1/task/cC1NN-08SMagaAKIQDSv2g/runs/0/artifacts/public/build/target.dmg
(In reply to Jonathan Kew (:jfkthame) from comment #12)
> emanuela, if you run the tryserver build of Nightly from
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=355c420847057affe4bfa709375c6b3887ad616a (see [1] for
> the actual download), does this solve the problem (without altering sandbox
> settings)?
> 
> [1]
> https://queue.taskcluster.net/v1/task/cC1NN-08SMagaAKIQDSv2g/runs/0/
> artifacts/public/build/target.dmg

It doesn't :(

(In reply to Haik Aftandilian [:haik] from comment #11)
> 
> emanuela, could you try setting the pref security.sandbox.logging=true, then
> restarting the browser, and then reproducing the problem. Before you do
> that, startup the OS X Console app and filter on plugin-container. Then when
> you reproduce the problem, you should see some sandbox violations related to
> your font directories.

:haik, I'm not familiar with Console, could you please indicate me how I can filter for plugin-container? I'm sorry :-/
Flags: needinfo?(emanuela)
(In reply to emanuela [ux team] from comment #13)
> > emanuela, could you try setting the pref security.sandbox.logging=true, then
> > restarting the browser, and then reproducing the problem. Before you do
> > that, startup the OS X Console app and filter on plugin-container. Then when
> > you reproduce the problem, you should see some sandbox violations related to
> > your font directories.
> 
> :haik, I'm not familiar with Console, could you please indicate me how I can
> filter for plugin-container? I'm sorry :-/

No problem. Here are the steps.

First, in about:config, search for the setting security.sandbox.logging and change it to true.

Then quit Firefox.

Launch the Console application. It's the app named "Console" in /Applications/Utilities.

Once it's open, in the search field, put in "plugin-container" without the quotes. (See screenshot attachment.)

Click the "Clear" button in Console toolbar.

Then start Firefox and reproduce the problem.

Then check Console for any error messages. There are going to be some SandboxViolation error messages and things like "deny(1) mach-register com.apple.axserver". Anything that might be related to fonts would be good to note.

A simple way to record all the log entries in Console is to do an Edit->Select All, then Copy, then Paste into a text editor and save a file with all the log entries.
Screenshot showing OS X Console filtering for plugin-container log entries.
Flags: needinfo?(emanuela)
Attached file console-log.txt
Interesting twist. I updated my Nightly ( 57.0a1 (2017-08-09) (64-bit)) this morning and the problem wasn't present. 

I set the security.sandbox.logging to false, restart Nightly and still not present!

Any idea what fix the problem?

for the sake of completeness, I attached my log in this comment.
Flags: needinfo?(emanuela)
Just to check: if you look in about:config, what is the setting of the security.sandbox.content.level preference?
Flags: needinfo?(emanuela)
(In reply to Haik Aftandilian [:haik] from comment #11)
> But I suspect there's some way in OS X to enumerate active font directories
> because the system needs to be able to find them.

I'm not sure that's true, because the OS X font management APIs (e.g. [1] allow an application (such as the FontExplorerX utility) to "activate" fonts from arbitrary locations; the "URLs" here would normally be local file:// URLs but could point anywhere in the filesystem where FontExplorerX has read access.

So while there is a set of "standard" font directories (/Library/Fonts, etc), whose fonts will be automatically activated by default, the full collection of available fonts is not based on a set of "active font directories" but on the individual font files that have been activated.


[1] https://developer.apple.com/documentation/coretext/1499470-ctfontmanagerregisterfontsforurl
(In reply to Jonathan Kew (:jfkthame) from comment #17)
> Just to check: if you look in about:config, what is the setting of the
> security.sandbox.content.level preference?

security.sandbox.content.level | default | interger | 3
Flags: needinfo?(emanuela)
OK, that's as expected. Then I don't know why the behavior has changed for you; perhaps Haik will know of relevant changes that have happened recently.

The other factor would be the set of fonts you currently have activated through FontExplorerX. Have you made any changes there? Whether the problem shows up could be very dependent on the exact collection of fonts you currently have activated, compared with the fonts requested by the web page.
(In reply to Jonathan Kew (:jfkthame) from comment #20)
> OK, that's as expected. Then I don't know why the behavior has changed for
> you; perhaps Haik will know of relevant changes that have happened recently.
> 
> The other factor would be the set of fonts you currently have activated
> through FontExplorerX. Have you made any changes there? Whether the problem
> shows up could be very dependent on the exact collection of fonts you
> currently have activated, compared with the fonts requested by the web page.

Didn't change anything with FontExplore but I actived my Creative Cloud font library (I'm using it for Fira and others few fonts). I'll try to turn it off again and see if something changes.
See also bug 1379964 comment 17 (and surrounding discussion), which appears to confirm that FontExplorerX activates fonts from arbitrary locations (a Dropbox-managed library, in that instance) such that we cannot simply white-list a "standard" FontExplorerX directory and resolve this.

I don't know how widely used FontExplorerX is, but my suspicion is that it's fairly common among the design-oriented Mac-using community; given that we've had several reports already while the tighter sandbox restriction was only on Nightly, I'm concerned that if we allow this to go out to the Firefox release channel as-is, there are going to be a pretty significant number of affected users.

And given the catastrophic impact of the failure that occurs here (see attachment 8887973 [details]), which renders Firefox totally unusable for affected users/sites, with no obvious workaround (typical trouble-shooting steps such as creating a new profile, resetting Firefox, or running in safe mode will not help), I think this is serious enough to block the deployment of security.sandbox.content.level=3 to the release channel, until we have a mitigation or solution.
Component: Graphics: Text → Security: Process Sandboxing
Keywords: regression
Priority: P3 → P1
Summary: [mac] Sandbox blocks access to Linotype FontExplorerX font directory → [mac] Sandbox breaks font rendering for users with fonts managed via Linotype FontExplorerX
FontExplorerX is not the only such font management utility; there's also RightFont, which similarly allows users to "activate or deactivate fonts stored in any location...", which leads to similar breakage. (See bug 1379964 comment 19.)
Summary: [mac] Sandbox breaks font rendering for users with fonts managed via Linotype FontExplorerX → [mac] Sandbox breaks font rendering for users with fonts managed via Linotype FontExplorerX or RightFont
Questions on my mind in terms of thinking about how to solve this:

- Do we have any way of knowing whether or not a custom font manager has been enabled?
- Do we have any way of enumerating the paths they use? (Seems like no)
- Do they have any common/default paths we could whitelist, as we do for the Adobe font manager?

Failing any of those, the only other option appears to be remoting font loading to the parent; I don't know how difficult that's likely to be. (Note to self: ideally we'd load the file in the parent, but do the font file parsing in the sandboxed child, since font formats are nasty)
Something else for consideration:

- Allowing read of files that appear to be a font based on their extension. For example, allow .otf files.
Assignee: nobody → haftandilian
(In reply to Alex Gaynor [:Alex_Gaynor] from comment #25)
> Failing any of those, the only other option appears to be remoting font
> loading to the parent; I don't know how difficult that's likely to be. (Note
> to self: ideally we'd load the file in the parent, but do the font file
> parsing in the sandboxed child, since font formats are nasty)

I'm not sure how we'd go about that, given that we don't read the font files directly from Gecko code at all (Gecko generally doesn't even know where the underlying files are located); we access font data through macOS APIs, which ultimately access the underlying files as needed.

(In reply to Haik Aftandilian [:haik] from comment #26)
> Something else for consideration:
> 
> - Allowing read of files that appear to be a font based on their extension.
> For example, allow .otf files.

If we could allow .otf, .ttf, .ttc, .otc, and .dfont (all case-insensitively) I believe that would resolve the issue, at least in the overwhelming majority of cases. Other legacy font formats are not generally supported on current macOS anyway.
In trying to understand how the font managers work, I found ATSCreateFontQueryRunLoopSource[1] (deprecated) and ATSFontQueryCallback[2] which are only documented in name on developer.apple.com. 

This site mirroring older Apple docs has more of an explanation:
http://mirror.informatimago.com/next/developer.apple.com/documentation/Carbon/Reference/ATS/atsfontsref_Reference/function_group_4.html#//apple_ref/c/func/ATSCreateFontQueryRunLoopSource

Font managers can register a callback to be invoked when an application requests a font. Presumably, font managers use this functionality to return the appropriate font which could be anywhere on the filesystem.

I couldn't find a newer API replacement for ATSCreateFontQueryRunLoopSource. 

I wonder if it is possible for the parent process to use this API to intercept plugin-container font queries and deal with them by submitting its own query and then copying the returned font to a location we allow content processes to read from. Even if possible, that's not ideal because it adds I/O and latency to the font query. And we'd have to essentially maintain our own font cache.

I'm going to provide a build that whitelists font files by extension so that we can validate that solves the problem.

1. https://developer.apple.com/documentation/applicationservices/1563673-atscreatefontqueryrunloopsource?language=objc
2. https://developer.apple.com/documentation/applicationservices/atsfontquerycallback
(In reply to Haik Aftandilian [:haik] from comment #28)
> In trying to understand how the font managers work, I found
> ATSCreateFontQueryRunLoopSource[1] (deprecated) and ATSFontQueryCallback[2]
> which are only documented in name on developer.apple.com.

I believe the whole Apple Type Services framework is deprecated and unmaintained; we shouldn't be adopting those APIs, even if they still exist in some form. (Indeed, on looking at your link [1], I see that ATSCreateFontQueryRunLoopSource is listed as "SDK: macOS 10.2–10.8", so it's apparently long gone.)

There are newer font management APIs in Core Text (e.g. see comment 18), which I'd guess provide the main functionality used by font managers; this allows an app to register (activate) fonts from any location, such that they'll be seen by other applications. I'm not sure how activate-on-demand would be implemented, though; I suspect this may be depending on some kind of internal/undocumented APIs.
(In reply to Jonathan Kew (:jfkthame) from comment #29)
> (In reply to Haik Aftandilian [:haik] from comment #28)
> > In trying to understand how the font managers work, I found
> > ATSCreateFontQueryRunLoopSource[1] (deprecated) and ATSFontQueryCallback[2]
> > which are only documented in name on developer.apple.com.
> 
> I believe the whole Apple Type Services framework is deprecated and
> unmaintained; we shouldn't be adopting those APIs, even if they still exist
> in some form. (Indeed, on looking at your link [1], I see that
> ATSCreateFontQueryRunLoopSource is listed as "SDK: macOS 10.2–10.8", so it's
> apparently long gone.)
> 
> There are newer font management APIs in Core Text (e.g. see comment 18),
> which I'd guess provide the main functionality used by font managers; this
> allows an app to register (activate) fonts from any location, such that
> they'll be seen by other applications. I'm not sure how activate-on-demand
> would be implemented, though; I suspect this may be depending on some kind
> of internal/undocumented APIs.

Thanks, Jonathan. I missed the link you posted in that comment when I first read it.
Track 56+/57+ as regression.
The posted fix allows files with extensions from the list Jonathan recommended (.otf, .ttf, .ttc, .otc, and .dfont) to be loaded from content processes. The fix isn't ready for review yet. All the fonts on my system and fonts I found online for Mac's were one of those. OS X does support other font types according to online docs.

Here's a build with the fix:
  https://queue.taskcluster.net/v1/task/OrJdYVMjS4O5VymBQt3b4g/runs/0/artifacts/public/build/target.dmg

hibatsu or emanuela, if the problem is still reproducible for you, would you be able to test this dmg and see if it addresses the problem?

I tested with OpenSans (per bug 1379964) with RightFont and was able to reproduce the problem and verify the fix. With RightFont, it stores downloaded fonts in ~/RightFont.
Flags: needinfo?(hibatsu)
Flags: needinfo?(emanuela)
Assuming the fix does address the problem, we may want to only enable this with a pref because the fix doesn't allow us to limit the allowed files to actual fonts and not other types of files with those extensions. For example, .otc is also used for OpenDocument chart templates.
Whiteboard: [gfx-noted] → [gfx-noted] sb+
It would be possible for us to determine all the font directories that we need to whitelist using CTFontManagerCopyAvailableFontURLs() [1] which returns the path for every activated font. I did some quick tests using this at ContentProcess startup time and the call takes 5 to 10 milliseconds. With about 1000 fonts, the checks to examine each font path to determine if the font is in a non-standard directory had negligible overhead. I'll attach the proof-of-concept patch.

If we did this at startup, it would mean that if the user activated fonts from a directory that didn't have activated fonts when Firefox was started, they would have to restart the browser for Firefox to be able to use those fonts.

If the user activated fonts in a directory that already had some activated fonts, Firefox would be able to use those without a restart.

There's a question of if the font manager (with non-standard directories) use case is worth supporting. We've got a few users hitting this problem on Beta/Nightly and for some this will be a regression in build 56. Without any real data, I think this is worth fixing despite it slightly weakening the sandbox. We definitely want to support graphic designers testing on Firefox who may be atypical users.

My plan with this bug is to land a fix similarly to the patch posted on MozReview now (i.e., whitelist all files with font extensions) and file a follow up bug to use CTFontManagerCopyAvailableFontURLs() so that we can either 1) only enable the whitelisting when fonts from non-standard directories are detected OR 2) only enabling the font whitelisting for files in detected font directories with matching extensions.

The current patch doesn't include extensions for all of OS X supported fonts, just what appear to be commonly used.

1. https://developer.apple.com/documentation/coretext/1499478-ctfontmanagercopyavailablefontur
This proof-of-concept patch adds a call to CTFontManagerCopyAvailableFontURLs() and checks whether any of the returned fonts are outside of the system font dirs. It checks /System/Library/Fonts/, /Library/Fonts/, and ~/Library/Fonts/. There are other system font dirs we may want to include. The patch doesn't affect sandbox rules, it just prints out a message to indicate if external font directories were detected.
Comment on attachment 8899919 [details]
Bug 1382260 - Patch 1 - Fix file access test bug.

https://reviewboard.mozilla.org/r/171240/#review176408
Attachment #8899919 - Flags: review?(agaynor) → review+
Comment on attachment 8898168 [details]
Bug 1382260 - Patch 2 - [Mac] Allow reading of font files from the content sandbox.

https://reviewboard.mozilla.org/r/169536/#review176416

::: security/sandbox/test/browser_content_sandbox_fs.js:323
(Diff revision 2)
> +  let fontTestPaths = [];
> +  let badFontTestPaths = [];

Move these declarations inside teh `if` branch?
Comment on attachment 8898168 [details]
Bug 1382260 - Patch 2 - [Mac] Allow reading of font files from the content sandbox.

https://reviewboard.mozilla.org/r/169536/#review176416

Oops, dropped my comment somehow:

This makes me pretty uncomfortable, though I can't think of an attack (besides making these files readable, of course!).

a) Should this be behind a pref, or some other detection logic?
b) Do we have a plan to be able to remove it eventually?
Comment on attachment 8898168 [details]
Bug 1382260 - Patch 2 - [Mac] Allow reading of font files from the content sandbox.

https://reviewboard.mozilla.org/r/169536/#review176416

I can't think of an attack either, other than how a non-font file might end up with a matching extension. Use of a regex makes me nervous too, but we already rely on regex's in the policy.

> a) Should this be behind a pref, or some other detection logic?

The list of font system paths is available via a call to CTFontManagerCopyAvailableFontURLs(). I posted a proof-of-concept patch to the bug which uses that to detect when we have fonts outside of the standard directories. That could be used to limit the whitelisting to only the necessary paths, but I'd rather land a simpler fix for now because this will need to be uplifted.

I have a bit of an explanation on comment 35 - https://bugzilla.mozilla.org/show_bug.cgi?id=1382260#c35

I'm open to using a pref to disable the whitelisting by default. My reasoning for not putting it behind a pref is to not cause regressions for font manager users. I think that is a small percentage of users, but don't have data. And maybe those users are more likely to be web designers and influential users.

> b) Do we have a plan to be able to remove it eventually?

I will file a bug to improve this leveraging CTFontManagerCopyAvailableFontURLs().
Comment on attachment 8898168 [details]
Bug 1382260 - Patch 2 - [Mac] Allow reading of font files from the content sandbox.

https://reviewboard.mozilla.org/r/169536/#review176888

One more small nit.

::: security/sandbox/mac/SandboxPolicies.h:346
(Diff revision 3)
>        (subpath appTempDir)
>        (require-any
>          (vnode-type REGULAR-FILE)
>          (vnode-type DIRECTORY))))
> +
> +  ; Font files ending in .otf, .ttf, .ttc, .otc, .dfont

Can you add a comment explaining the font manager issue, or at least pointing at the bug?
Attachment #8898168 - Flags: review?(agaynor) → review+
Comment on attachment 8898168 [details]
Bug 1382260 - Patch 2 - [Mac] Allow reading of font files from the content sandbox.

https://reviewboard.mozilla.org/r/169536/#review176888

> Can you add a comment explaining the font manager issue, or at least pointing at the bug?

Added comment and reference to bug. Thanks.
Pushed by haftandilian@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9995d46d468f
Patch 1 - Fix file access test bug. r=Alex_Gaynor
https://hg.mozilla.org/integration/autoland/rev/47a2bf7ad918
Patch 2 - [Mac] Allow reading of font files from the content sandbox. r=Alex_Gaynor
See Also: → 1393259
Comment on attachment 8898168 [details]
Bug 1382260 - Patch 2 - [Mac] Allow reading of font files from the content sandbox.

Approval Request Comment
[Feature/Bug causing the regression]:
Bug 1332190 - [Mac] Enable level 3 Mac content sandbox, removing filesystem read access

[User impact if declined]:
Users on Mac that make use of font managers (such as RightFont and FontExplorerX) may encounter pages with completely broken/unreadable fonts where characters appears as boxes.

[Is this code covered by automated tests?]:
Yes. The patch includes testing changes to validate that fonts can be read by the content process. Existing automated tests cover a small subset of sandbox functionality.

[Has the fix been verified in Nightly?]:
Yes, for the RightFont use case.

[Needs manual test from QE? If yes, steps to reproduce]:
Install the RightFont font manager. There may be a free evaluation version available. Install the OpenSans font attachment on Bug 1379964 and visit https://uxchecklist.github.io/ as described on 
https://bugzilla.mozilla.org/show_bug.cgi?id=1379964#c0 

[List of other uplifts needed for the feature/fix]:
Patch 1 should also be included.

[Is the change risky?]:
No

[Why is the change risky/not risky?]:
It changes the Mac content sandbox rules to be less restrictive which is unlikely to cause regressions.

[String changes made/needed]:
None
Attachment #8898168 - Flags: approval-mozilla-beta?
Comment on attachment 8899919 [details]
Bug 1382260 - Patch 1 - Fix file access test bug.

Approval Request Comment
[User impact if declined]:
This is a testing-only patch that fixes a broken test. See approval request for patch 2. Patch 2 depends on this test fix.
Attachment #8899919 - Flags: approval-mozilla-beta?
Flags: needinfo?(emanuela)
Hi Florin, could you help find someone to verify if this issue was fixed as expected on the latest Nightly build? Thanks!
Flags: qe-verify+
Flags: needinfo?(florin.mezei)
I tested on Mac OS X 10.12 with FF Nightly 57.0a1(2017-08-29) following the steps from comment 50, and I can't reproduce this issue. Please note that I also tested this with a build that doesn't have the fix and I still didn't reproduce this. 
To be sure of this fix I'll need info Emanuela to help us here. 

Hi Emanuela, can you please verify if this issue is reproducible on the latest Nightly? Thanks
Flags: needinfo?(florin.mezei) → needinfo?(emanuela)
(In reply to ovidiu boca[:Ovidiu] from comment #53)
> I tested on Mac OS X 10.12 with FF Nightly 57.0a1(2017-08-29) following the
> steps from comment 50, and I can't reproduce this issue. Please note that I
> also tested this with a build that doesn't have the fix and I still didn't
> reproduce this. 
> To be sure of this fix I'll need info Emanuela to help us here. 
> 
> Hi Emanuela, can you please verify if this issue is reproducible on the
> latest Nightly? Thanks

It's all good here with FontExplore X Pro!
Flags: needinfo?(emanuela)
Thanks Emanuela,
Based on comment 54 and 53 I will mark this issue as verified fixed.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Comment on attachment 8898168 [details]
Bug 1382260 - Patch 2 - [Mac] Allow reading of font files from the content sandbox.

New regression in 56, fix is verified, let's uplift it for beta 8.
Attachment #8898168 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 8899919 [details]
Bug 1382260 - Patch 1 - Fix file access test bug.

Thanks for the test fixes too!
Attachment #8899919 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.