Re: Fwd: [friam] Could you/somebody make a safe browser?

On Fri, March 20, 2015 22:58, Tony Arcieri wrote:
> On Fri, Mar 20, 2015 at 1:48 PM, Raoul Duke <[email protected]> wrote:
>
>> >> If you could start from scratch, could you use a better architecture
>> &
>> design to make a fundamentally safer web browser?
>
>
> To wash it all away, eh? ;)
> http://research.microsoft.com/en-us/people/mickens/ToWashItAllAway.pdf
>
> A lot of attention is placed on classical web vulnerabilities like XSS,
> CSRF, cookies, etc, and those things are definitely huge problems...
>
> But I think the biggest problem is that Web Browsers, JavaScript VMs, and
> plugins like Flash are all extremely complicated projects with millions
> upon millions of lines of code written in memory unsafe languages like
> C/C++. Because of this there is an endless cycle of remote code execution
> vulnerabilities. Every Apple SA, for example, contains at least a half
> dozen remote code execution vulnerabilities in WebKit and associated
> plugins (e.g. image format parsers, PDF processing, compression). For a
> long time Flash was a nearly ubiquitous platform that happened to be a
> horrific codebase full of severe security issues.
>
> I think the sorts of appsec 101-style web vulnerabilities that most people
> tend to focus on form quite a small portion of a browser's potential
> attack
> surface, and until we can stem the flood of remote code execution
> vulnerabilities and sandbox escapes, the web will never be a secure
> platform.
>
> This is why I really like the work that Mozilla is doing with their new
> Servo rendering engine, written in Rust, a memory-safe language which uses
> a region typing system to manage memory instead of a garbage collector.
> Building browsers on a memory safe foundation seems like the first step
> towards creating a safe web browser.
>

While I do think Rust is a really promising language, 'modern' C++ style
programming already solved most of the accidental C style C++ memory
insecurity bugs. There is still some mitigation from memory safety, sure,
but the sheer size of the runtime of many memory-safe languages might
actually end up making things worse. What counts is the size of the
trusted code-base. Memory safety helps reduce that, but being fully ocap
down to the runtime implementation should be the only solution that would
have real substance in that account. Rust being an amazing language and
the first serious language that is right there with the low level
languages like C++ has much potential I think IF it could be turned into
an ocap language. Something I think that does have a chance from a
language perspective, that is if the language people on this list act
swiftly. Turning Rust into an ocap language before to much of the emerging
infrastructure irreparably depends on ambient API constructs seems like a
race worth racing and the best chance of ever getting the language part of
least authority sorted in order to become able to use a coarsely grained
process model for secure programming.

But then the language level is not the only front to fight the security
battle. There is also the process sandboxing and IPC front. I think Chrome
made a good step with their multi process approach and with NaCl there.
The big challenge would be to sandbox the big things in a discretionary
IPC way so that a bug in for example webkit should not allow cross web-app
attacks, let alone attacks against the underlying OS user environment or
even the underlying OS. Discretionary IPC based sandboxing is I think just
as important as the idea of a low level ocap language (for what I feel
Rust could be an excellent basis).