(Sorry for the continued laggy responses here...)
On 04/27/2017 03:38 AM, Henri Sivonen wrote:
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.
I don't see why we would do something different on Linux than we would
on any other OS. That seem more work than treating Linux as the same as
other OSes, and I doubt it would make sense to put more effort into
special casing Linux in any way. To make my perspective very clear, I
think it would make sense for Mozilla to have a single code path that
treats loading libvokko in the exact same way on all three desktop OSes
if at all possible. And if we need special code paths, having that on
Windows make more sense than having that on Linux.
I would appreciate if we can keep the rest of the discussion focused on
cross platform issues please. Even if we end up loading unsigned
binaries for this on Linux I honestly won't lose much sleep over it
given that in practice distros package our builds and they do what they
want in that process anyway.
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.
That is correct. I doubt Authenticode buys us anything?
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.)
There exists no such policy in the general terms AFAIK, so I don't think
we should be looking for one to inform our decision based on here. As
I'm sure you know, these things are always decided on a case by case
basis (and sometimes not really decided, when someone just lands code
without thinking about the size implications. :-/)
Here, the comparison between these two cases is actually not all that
hard to analyze. It is totally reasonable to expect someone using an
en-US build to go a web page with some Thai script text and expect to
not see garbage text. It is not at all reasonable for someone using an
en-US build without installing a Finnish dictionary to expect Firefox to
spell check Finnish text (at least until a future date where Firefox
doesn't force one to install that dictionary in the first place.)
Therefore the second class of users can't expect all en-US build users
to be penalized with the additional code size required to support spell
checking for that language.
(That being said, I *personally* hate how we discriminate against all
languages except the default UI locale one like this, I'd much rather if
Firefox would do more to support your languages for you, but we live in
the current world...)
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.
If we want to use this infra, someone needs to find out these answers.
:-) I sadly don't really have the bandwidth to do that myself these
days... Do you, Henri?
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.
Yes. :-)
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?
By opening up a path for us to run libvoikko out of firefox.exe. I
don't think any proposal that doesn't provide support for this really
addresses that concern (with all due respect to that project, but it's
still a pile of C++ code and all...)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
