On Wed, Apr 26, 2017 at 9:49 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 04/26/2017 07:02 AM, Henri Sivonen wrote: >> >> On Tue, Apr 25, 2017 at 9:02 PM, Bill McCloskey <wmcclos...@mozilla.com> >> wrote: >>> >>> On Tue, Apr 25, 2017 at 5:41 AM, Henri Sivonen <hsivo...@hsivonen.fi> >>> wrote: >>>> >>>> What problem did you mean to address by code signing? >>> >>> The reason I suggested code signing is because loading libvoikko would >>> provide an easy way for people to inject code into Firefox. > > > Yes, this is precisely what I'm worried about as well. >>> >>> For a while >>> we've been trying to make it difficult for >>> semi-legit-but-not-quite-malware >>> parties to load crappy code into Firefox (I'm thinking of crappy >>> antivirus >>> software, adware, etc.). Removing binary XPCOM components and NPAPI >>> support, >>> and requiring add-on signing, are all facets of this. If we simply load >>> and >>> run code from any file named voikko.dll on the user's computer, then >>> we've >>> opened up another door. It's a less powerful door since we probably (I >>> hope) >>> wouldn't give them access to XPCOM. But they could still open windows >>> that >>> look like they came from Firefox and I imagine there's other bad stuff I >>> haven't thought of. >>> >>> People often object to this argument by saying that, without libvoikko, >>> these bad actors could just replace libxul or something. But I think in >>> practice it would be harder for them to pull that off, both technically >>> and >>> socially. From a technical perspective, it's harder to replace core parts >>> of >>> Firefox while still leaving it in a working state, especially if the >>> updater >>> is still allowed to run. And socially, I think it makes their software >>> look >>> a lot more like malware if they replace parts of Firefox rather than >>> simply >>> install a new DLL that we then load. >> >> This concern applies to Windows but not to Linux, right? What about Mac? > > FTR my main concern is about Windows here. But that being said I think we > can probably do something similar for Linux and Mac (but if we don't have > the time or resources to address those first/now, that's probably fine.)
As noted previously about how we load other libs on Linux, I think it doesn't make sense to do load-time signature checking on Linux. >> To address that concern, the local system itself would have to be >> treated as semi-hostile and the signature would have to be checked at >> library load time as opposed to the usual library install time. Do we >> have pre-existing code for that? > > We should treat the local system as *hostile*. Because that's what it is in > the real world at least for our Windows users. > > I was hoping that we can use the code that we use to sign and verify our mar > files for the updater here, see for example this header which we use for > signature verification > <http://searchfox.org/mozilla-central/source/modules/libmar/verify/cryptox.h>. > I'm suggesting to use this code as a *basis* for this work, so there will be > some new code to be written for sure. > > The advantage of this code is that it's pretty self-contained, so for > example we can use it to create a small command line utility to give the > voikko folks to use for signing, etc. So this would be a special Mozilla-specific code signing scheme and not Authenticode for Windows. >> AFAIK, in the case of OpenH264 we check a hash at library install >> time, but when we subsequently load the library, we don't check a hash >> or signature. In the case of OpenH264, the library gets loaded into a >> sandbox, which probably addresses the concern of a replacement >> OpenH264 with dodgy additional code being able to open windows that >> look like they came from Firefox. >> >> Assuming that we don't already have code for validating library >> provenance at library load time, wouldn't it make more sense to put >> effort into reusing the facilities for spawning a GMP process to spawn >> a low-privilege spell checking process than to try validate the >> provenance of already-installed code in a way that still doesn't >> address the crash impact concern in the case of the code being >> legitimate? >> >>> Overall, though, I agree with Ehsan that this discussion isn't very >>> worthwhile unless we what the voikko people want to do. >> >> It seems to me that this thread raises enough concerns on our side >> that it doesn't make sense to ask a third party what they want to do >> before we have an idea what we'd be OK with. >> >> Suppose they'd say they'd want to include libvoikko in Firefox like >> Hunspell? >> We'd have binary size and crash impact concerns. > > To make the concerns here more concrete, the core of the issue is that our > non-English builds are merely a repack of the en-US builds, so currently > it's not possible to ship extra code to those users. That being said, it > _may_ be an option to use the locale repackaging step as a vehicle for > delivering the library binary that the voikko project provides us if we end > up going that option. We should check with the l10n team how easy/possible > packaging this would be inside the locale as a resource... This seems to imply that there exists no non-zero code size addition that we'd take for a non-Web-facing feature that applies to a small number of locales. (For Web-facing features, there is precedent for non-zero-size code that applies e.g. to the Thai script only.) >> Suppose they'd say they'd want to make libvoikko download on-demand >> using Mozilla infra like OpenH264? >> We'd have concerns of finding release engineers and front end >> engineers with time to set it up, the crash impact concern and the >> concern of another party dropping malware in libvoikko's place. > > FTR, it may actually be useful to look into this... I sort of assumed this > isn't an option because I don't know how reusable the infra that we have for > OpenH264 is, but if it is easily reusable without a lot of work, this may be > a good option too. Experience from the CDM case suggests that adding another downloadable to Balrog isn't a big deal. On the client side, adding another Firefox-managed plug-in to the add-on manager UI requires some front-end developer effort to add another hard-coded thing. I don't know about the reusability the infra that's used to build and stage OpenH264 itself, since that infra wasn't applicable in the CDM case. >> Suppose they'd say they'd want to install libvoikko somewhere on the >> user's library path and have us dlopen() it? >> We'd have concerns about crash impact, being able to remedy crashes, >> directing people to install non-Mozilla software (though @firefox on >> Twitter regularly does) and other parties dropping malware in >> libvoikko's place. >> >> Suppose they'd say they'd want to ship a back end for system spell >> checking frameworks and have us use the system spell checking API[1]? >> We'd have concerns of Windows 7 not being covered, directing people to >> install non-Mozilla software and crash impact at least in the Linux >> case (AFAICT, Enchant doesn't provide process isolation from the back >> end; I *think* Apple's solution does; not sure about Windows 8+) and >> having to write 3 system-specific spell checking integrations. > > Does the above lay out a good alternative? I take it that the above refers to what you said above and not to what you quoted me saying immediately above about system frameworks. > They'd install libvoikko somewhere on the user's system and they sign it > somehow and we verify that signature and load it upon successful > verification and call a known entry point in the loaded library. How would your concern about locale-specific crashes be addressed in this scenario? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
