Javascript JIT in web browsers

[Brandon Lozza]

I've already seen websites exploit firefox tabs and they made use of my
gmail account to send spam.

Why should we make firefox easier to exploit?

On Mon, Aug 16, 2010 at 5:07 AM, drago01 <drago01 at gmail.com> wrote:

> On Mon, Aug 16, 2010 at 1:15 AM, Kevin Kofler <kevin.kofler at chello.at>
> wrote:
> > drago01 wrote:
> >> The times where javascript is only used for some fancy effects are
> >> long over ... welcome to 2010 ;)
> >
> > Some web sites are indeed abusing JavaScript. Why should we promote this
> > behavior? It is a vehicle for proprietary software, where people often
> > aren't even aware they're using non-Free code, or just ignore the issue.
> > See also http://www.gnu.org/philosophy/javascript-trap.html . A web site
> is
> > not and should not be an application, an application is not and should
> not
> > be a web site.
>
> There is a difference between a website and web *application*.
> Besides who is stopping me (or anyone else) from writing a free
> software web app that uses Javascript? People have been and are doing
> that all the time.
> By your logic we should ban gcc, java, mono, python, perl, bash ... as
> one can use them to create and/or run non free software.
>
> Also you may be aware that javascript has its uses *outside* of the
> web too (just like you can write apps in python you can do it in JS;
> and having a JIT that speeds them up is definitely a plus).
>
> >> The "problem" is fixable there is a patch that is being discussed
> >> upstream to fix the issue and allow selinux memory protection it is
> >> just not merged yet.
> >>
> >> Using a JIT is not a security risk by itself.
> >
> > Workarounds which make SELinux happy are still not as secure as sticking
> to
> > a pure bytecode interpreter. Exploit code can still write to the memory
> to
> > be executed, with ANY JIT, as this is how a JIT works. It's just that the
> > writing has to happen through a different address space window as the
> > execution, making the JIT harder, but not impossible, to exploit.
> >
> > So IMHO the right fix is to disable the JIT altogether.
>
> This is *not* a fix. You can't solve problems by disabling features
> and pretending they do not exists.
>
> > But the proposed patch would still be better than the crappy solution
> > implemented now just to "stick to upstream"
>
> Yeah because forking a web browser which would end up with a more
> secure experience than joining forces with upstream with the expertize
> there and can deliver security fixes on time (which also apply to our
> version).
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20100816/88866c88/attachment.html