[liberationtech] Browser extensions or native application for crypto? Was: Whiteout OpenPGP.js encrypted mail client (Chrome HML5 App)

[Edwin Chu]

Comments inline.

Edwin


On Thu, Jan 23, 2014 at 3:05 AM, Fabio Pietrosanti (naif) <
lists at infosecurity.ch> wrote:

> Let's try to get  bit deeper in the comparison of the effective
> vulnerability exposure window of a chrome browser extensions vs. native
> application.
>
> My feeling is that chrome browser extensions are more secure than native
> applications.
>
> >
> > Il 1/22/14, 9:53 AM, Tony Arcieri ha scritto:
> >
> > It's true that native applications have wide-ranging capabilities that
> > browser extensions don't.
> Which kind of capabilities does natives applications, that browser
> extensions doesn't provide within the context of encryption software?
>

For example, privileges separation using application sandbox, jail, LXC or
various techniques are useful for writing secure software. I don't aware of
any comparable technologies on Chrome App platform.


>
> > Where browser extensions can fall down is unexpected interactions with
> > web pages and JavaScript running on them. This is a problem that
> > native apps don't have because the browser is attempting to act as a
> > sandbox, so escalating privilege from a JavaScript to access to native
> > code execution is much more difficult than escalating privileges to
> > interact with browser extensions unexpectedly. In this regard, native
> > apps are superior, because the browser is trying to prevent that
> > interaction from happening. Native apps are "airgapped" from web pages
> > in a way browser extensions are not.
>
> In order to "attack" a client side application (being a browser
> extension or a native one) you need to exploit a vulnerability in the
> application itself.
>
> Browser extension could be hacked if they are unsafe, trough the use of
> XSS-like attack techniques, by triggering an external payload into it
> (for example from a website visited by the user).
> Native applications could be hacked if they are unsafe, trough the use
> of buffer/heap overflow like techniques, by triggering an external
> exploit payload (for example by sending an email to a
> thunderbird/enigmail target user).
>

Yes, both are vulnerable to various kinds of attacks. However, the browser
itself is complex software, the interaction between different moving parts
in a browser, e.g. extensions, plugins make it worse. Yes, OS is complex
too, but browsers just add another complex layer on top of the OS.
Complexity is the worst enemy of security. Native apps are superior in this
aspect.


>
> Browser extensions, if exploited, provide less damage to the underlying
> operating system and data due to the Browser Sandbox.
> Native application, if exploited,  provide access to all of the
> underlying operating system an data.
>

Native apps can also be sandboxed.


>
> Browser extensions install and update securely trough the Chrome App
> Store (Ok, it's a wallet guarden, but application are safely distributed)
> Native applications (for windows for example) cannot be install
> securely, unless following complex binary hashing verification and
> comparison procedures that most users does not follow.
>

What do you think about the native apps App Store model of Apple, Google
and Microsoft? The applications are signed and the system only allows
applications signed by a trusted authority by default.


>
> Browser extensions can be run within a dedicated Chrome profile, that's
> effectively a native sandboxing of the environment where the browser
> extension run with it's additional layer of sandbox.
> Native applications are more difficult to be sandboxed with such a
> double layer, unless third party application sandboxing are used.
>

User system of modern OS is designed for this purpose. And you get a
clearer separation between different users.


>
> So, my personal feeling is that chrome browser extensions can provide a
> better secure environment for crypto applictions than the native ones.
>
>
> --
> Fabio Pietrosanti (naif)
> HERMES - Center for Transparency and Digital Human Rights
> http://logioshermes.org - http://globaleaks.org - http://tor2web.org
>
> --
> Liberationtech is public & archives are searchable on Google. Violations
> of list guidelines will get you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20140123/18b86ed1/attachment.html>