mactype incompatible with new Chromium network process sandbox

[wfharris]

Hello I work on the Chromium open source browser.

We are adding a new sandbox on the Chrome network process. This prevents the mactype detour DLLs from functioning correctly inside this process type and is causing it to crash, resulting in Chrome being non-functional when mactype is installed.

I have tested with Chrome Canary 64-bit 90.0.4414.0 and mactype 2019.1-beta6 in service mode.

I wonder if it would be possible to not inject into this process type? It can be identified by looking for the command line --type=utility

We are tracking this issue on our tracker here -> https://bugs.chromium.org/p/chromium/issues/detail?id=1177395

[sammilucia]

I'm sure @snowie2000 will comment soon enough, however, a genuine question:

If a rogue process can cause Chromium to become non-functional, then isn't this itself a denial of service attack vector for malware? Shouldn't Chromium handle this case gracefully?

In the meantime, you can add chrome.exe to the Exclude list in the MacType INI.

This is disappointing. There areat least 10,000 users of MacType, many of whom want to continue using Chrome-based browsers to tune DirectWrite.

Maybe there's some way we can work together to enable this?

[wfharris]

Chrome does not view locally installed malware/applications as part of its threat model, as it can't defend against them.

See https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Why-arent-physically_local-attacks-in-Chromes-threat-model

here, I am actively trying to work with mactype to try and come up with a mutually beneficial solution here. Perhaps Chrome's utility processes could be added to a default Exclude list, so people don't have to add them manually?

[snowie2000]

Checking for command line parameters can be supported without too much trouble for sure, but I checked the crash report of Chromium which was crashed because of "Out of memory"?

What happened to the process? What's the conflict between the easyhook(I believe this is the key component of the problem) and your new sandbox?

[sammilucia]

here, I am actively trying to work with mactype to try and come up with a mutually beneficial solution here. Perhaps Chrome's utility processes could be added to a default Exclude list, so people don't have to add them manually?

I appreciate you're here. I can add chrom*.exe to the default exclude list, and we're keen to help with the problem.

It's just that Chrome no longer working with MacType for DirectWrite tuning solves Chromium's problem without regard to the MacType userbase. That's, by definition, not mutual, unless I'm missing something?

[sammilucia]

@wfharris is it just the utility process, not the main exe that needs exclusion?

[wfharris]

The conflict is that the process is now running at a significantly reduced privilege level, so the APIs that easyhook is using are failing and causing unexpected behavior such as crashes or OOM (e.g. allocations will fail).

I presume you still want to be able to smooth the fonts in Chrome, so you'll probably still want to be in browser process? I don't think mactype needs to be in any utility processes, and these are identified by the --type=utility command line.

However, bear in mind at some point mactype will no longer function in any of Chrome's processes, since we are gradually locking down the processes for security and stability - see https://blog.chromium.org/2017/11/reducing-chrome-crashes-caused-by-third.html

Does mactype currently work with Chrome?

[TabrisKing]

No. You can try centbrowser

[snowie2000]

@wfharris Yes, mactype still works with official Chrome and any third-party chromium-based browsers.
Although most of them have adopted DirectWrite as their default rendering method, MacType still can manipulate parameters of the DW to make the text look the way they like.

I can totally understand that blocking unknown dll injections can make chrome secure and, arguably, better, but since Windows text rendering is always so dissatisfactory and are likely to continue that way, I suspect that the demand to make texts of chrome look better will be gone any time soon and enforcing chrome that way by blocking everything out is not ideal.

I personally suggest that if it's possible, could Chrome expose some sort of way or API or maybe a separate text rasterizer process that accepts interception or can accept glyph generation addons so that the way of text displaying in Chrome can be safely altered. In that way, mactype no longer needs to inject into any of the chrome processes and users can still enjoy a good browsing experience.