 |
| Google Chrome web browser security warning message |
I've been reviewing the current state of Internet Privacy.
It's still a mixed bag and my conclusion is that it will remain so for quite some time.
Efforts to provide Internet Privacy are varied, depending on which ISP is employed.
The primary means for conveyance to a target website to do any kind of task is the web browser.
To put security risk into context, the web browser is a remote code execution tool.
Yep. Let that sink in for a minute.
Where ever the user goes, the browser is set to 'trust' a remote stream of bytes which get 'interpreted' as program instructions on your PC by the web engine.
Sounds quite troubling when you think about it really.
I mean, your browser is one big catcher's mit and absorbs everything it sees in an attempt to execute instructions sent from a remote web server.
So, this catcher's mit is by default a 'security risk'.
Different software vendors take different approaches to the responsibility of writing their software in a manner that ensures it should always operate securely.
For example, Internet Explorer on Microsoft Windows, is written by Microsoft and employs 'protected mode', something akin to a software sandbox, but, technically isn't.
Google Chrome for Windows is designed with a quasi-sandbox by Google Engineers. But they have publicly stated it cannot stop certain kinds of exploits (Javascript DLL injection) from successfully executing and gaining administrative control on Legacy Windows. This is a fact.
But, that isn't really my point. In each software project some 'defensive' coding has or has not taken place.
I've reported in the past that, where Fedora Linux is concerned, users running Firefox, the default installed browser, are placed in a 'real' sandbox, called Linux Security Modules (LSM) and the particular module used by Fedora is SELinux.
From a security standpoint, this is a prime differentiator between Linux and Windows.
An exploit may propagate on Windows running Chrome. It will never propagate using Linux with SELinux.
The word 'never' comes with a catch. You see the browser's memory space is up for 'fair game' and various code, Java, Javascript can execute remotely exposing certain parts of your running PC.
In theory, nothing bad should happen and it is assumed that code in the browser PID will never escalate to the Admin level.
But what it is doing in its own memory space is an open question. The issue of cross site scripting remains an unsolved problem.
In this context, if a user chooses to employ a browser-based security tool designed to protect their local PC, this sets up the conditions -- a 'fictional' exploit may, for example, attempt to steal a local browser's in-memory private keys for encryption.
So, you see, I am revising my thinking. I'm not sure any more about using the browser for any kind of security. It's that risky.
Using compiled, well maintained free standing open source security applications is entirely a different matter.
For example, I have Gmail. But I don't use the browser client to access it.
I use GNOME Shell's integrated Evolution Email client, which is also used to prepare outgoing mail using GnuPG (OpenPGP) encryption.
The PID for decoding/encoding gmail runs in Evolutions local memory space, not in a browser. Once the email is encrypted, signed, it is then and only then sent and a copy gets stored (IMAP) on the Gmail web server, in PGP encrypted form.
That's a routine process I feel confident in completely.
The notion that other software vendors can fork GnuPG and refactor it in Javascript troubles me. This is precisely what Google is doing in their End-to-End encryption project, currently in Alpha.
The whole end to end encryption runs as javascript in the browser.
That puts the whole premise of security in the hands of the browser.
It's not acceptable. Even now, I am rethinking how MEGA works. Again, here, there is secureboot.js code running in your browser.
I believe there has to be a total segregation from the browser for any kind of security tool client application. It must be compiled. It must be open source and it must employ upstream industry standard GnuPG OpenPGP.
The browser will always be a target for attack. Always. Letting it also run your security is a fundamental mistake. -- Dietrich
0 comments:
Post a Comment