On Mon, Oct 27, 2014 at 6:30 PM, Benedikt Freisen <[email protected]> wrote:
> May I ask, why you prefer signing byte-code files and thereby limiting > the exploitation of a security hole in the interpreter to one party over > solving the actual problem, i.e. hardening the interpreter (lt-proc) in > such a way that nothing evil can happen? > > If I correctly understand what lt-proc is doing (processing some sort of > state transition table), the worst thing that could happen in a > range-checking implementation would be an infinite loop. That however > could be detected by a time-out, excessive output size compared to the > input size, etc. > > I personally think that quirky workarounds should only be used when the > possibility of actually fixing the bug is ruled out. > We are talking about lttoolbox-java, and not C++ lttoolbox/apertium. In the Java version transfer rules are not interpreted but compiled into Java/Dalvik bytecode, which is then invoked dynamically. See http://wiki.apertium.org/wiki/Bytecode_for_transfer for more details. The mobile app uses precompiled bytecode, so if we store it in the external storage and some kind of malware modifies it, the app would invoke that modified and potentially malicious bytecode. As far as I know there is no way to solve this problem other than using cryptography. > > Regards Benedikt > > Am 27.10.2014 um 01:19 schrieb Jim O'Regan: > > On 26 October 2014 22:56, Mikel Artetxe <[email protected]> wrote: > >> On Sun, Oct 26, 2014 at 7:56 PM, Jim O'Regan <[email protected]> wrote: > >>> > >>> On 26 October 2014 15:05, Mikel Artetxe <[email protected]> wrote: > >>>> 2) Cryptographically sign the bytecode and verify this signature every > >>>> time > >>>> that we load it. Probably not too hard to implement, but we would have > >>>> to > >>>> take care of the infrastructure involved, which is not trivial (e.g. > who > >>>> would keep the private key? only people with it could publish or > update > >>>> language pairs, but we could not make it public either as potential > >>>> attackers would then have access to it). > >>> > >>> A phone or tablet fits the definition of "user product"[1] in the > >>> GPL3, so you would be required (section 6) to also provide the keys > >>> used to sign the binaries for packages covered by the GPL3. > >> > >> > >> If I understood you correctly, using a language pair from Apertium was > more > >> or less like playing a video from a video player in terms of licensing, > as > >> GPL would consider both of them "mere aggregation". The only thing that > I > >> would be doing is verifying that this "mere aggregation" comes from a > >> trusted source. Doesn't GPL allow me to do that? That sounds like an > >> extremely stupid restriction! > >> > > > > TiVo did the same thing with signed versions of the Linux kernel, and > > that's why the GPL3 includes this clause, why it's restricted to "user > > devices", and why Linux is GPL2-only. > > > >> What's more, language pairs must already come from a verified source in > the > >> current version. The only thing that changes is the way in which this is > >> achieved: currently it is the OS that makes sure that nobody can > modifiy the > >> transfer bytecode, and in the proposed system it would be the app > itself by > >> using some very basic cryptography. I see no difference between them. > >> > >> More importantly, is there any workaround for this restriction other > than > >> having a security hole in the app? Some ideas that come to my mind: > >> > >> 1) Allow the user to add any other public key that they trust on. So > >> technically any transfer bytecode could be run as long as it is > explicitly > >> trusted by the user. > >> > >> 2) Alert the user if the signature check fails, but give the option to > run > >> the code under their own risk. > >> > >> 3) An extreme idea: give the option to go into an unsafe mode, but make > it > >> ridiculously hard to activate. For instance, if the user presses certain > >> button for, let´s say, 24 hours, the next signature check will be > skipped. > >> Technically this would be possible, but we could be pretty sure that it > >> would never happen. A stupid solution for a stupid restriction. > >> > >> PD: Are we also supposed to publish the keys that we use to sign the app > >> itself to upload it to Google Play? That would be even more stupid! > > > > No; it has to be included in the "installation information", which > > wouldn't normally go somewhere like Google Play. > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Apertium-stuff mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/apertium-stuff >
------------------------------------------------------------------------------
_______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
