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.)
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.
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...
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.
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?
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.
Suppose they'd say they'd want to ship it as Web Assembly in a Web Extension?
We'd have concern about allocating engineering time to enable a Web
Extension to act as a spell checking provider, when there's only one
extension that'd foreseeably use it.
As far as I'm concerned, anything that involves us having to run JS for
this is overkill and puts us in a tough spot in the future, so I'd very
much like to avoid that at all costs if possible. Porting this to
WebAssembly is my least favorite option of all!
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
