Chromium project finds that 70% of security defects are memory safety problems

栏目: IT技术 · 发布时间: 4年前

The Chromium project finds that around 70% of our serious security bugs are memory safety problems . Our next major project is to prevent such bugs at source.

The problem

Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs.

Chromium project finds that 70% of security defects are memory safety problems

(Analysis based on 912 high or critical severity security bugs since 2015, affecting the Stable channel.)

These bugs are spread evenly across our codebase, and a high proportion of our non-security stability bugs share the same types of root cause. As well as risking our users’ security, these bugs have real costs in how we fix and ship Chrome.

The limits of sandboxing

Chromium’s security architecture has always been designed to assume that these bugs exist, and code is sandboxed to stop them taking over the host machine. Over the past years that architecture has been enhanced to ensure that websites are isolated from one another . That huge effort has allowed us — just — to stay ahead of the attackers. But we are reaching the limits of sandboxing and site isolation.

A key limitation is that the process is the smallest unit of isolation, but processes are not cheap. Especially on Android, using more processes impacts device health overall: background activities (other applications and browser tabs) get killed with far greater frequency.

We still have processes sharing information about multiple sites. For example, the network service is a large component written in C++ whose job is parsing very complex inputs from any maniac on the network. This is what we call “the doom zone” in our Rule Of 2 policy: the network service is a large, soft target and vulnerabilities there are of Critical severity.

Just as Site Isolation improved safety by tying renderers to specific sites, we can imagine doing the same with the network service: we could have many network service processes, each tied to a site or (preferably) an origin. That would be beautiful, and would hugely reduce the severity of network service compromise. However, it would also explode the number of processes Chromium needs, with all the efficiency concerns that raises.

Meanwhile, our insistence on the Rule Of 2 is preventing Chrome developers from shipping features, as it’s already sometimes just too expensive to start a new process to handle untrustworthy data.

Staying still is not an option

We believe that:

  • Attackers innovate, so defenders need to innovate just to keep pace.

  • We can no longer derive sufficient innovation from more processes or stronger sandboxes (though such things continue to be necessary).

  • Therefore the cheapest way to maintain the advantage is to squash bugs at source instead of trying to contain them later.

What we’re trying

We’re tackling the memory unsafety problem — fixing classes of bugs at scale, rather than merely containing them — by any and all means necessary, including:

  • Custom C++ libraries
    • //base is already getting into shape for spatial memory safety.
    • std and Abseil assume correct callers ‘for speed’, but can be modified to do basic checking with implementation changes (Abseil) and compile-time flags (LLVM libcxx).
    • Generalizing Blink’s C++ garbage collector , and using it more widely (starting with PDFium).
  • Hardware mitigations, e.g. MTE .
  • Using safer languages anywhere applicable

These options lie on a spectrum:

Chromium project finds that 70% of security defects are memory safety problems

We expect this strategy will boil down to two major strands:

  • Significant changes to the C++ developer experience, with some performance impact. (For instance, no raw pointers, bounds checks, and garbage collection.)

  • An option of a programming language designed for compile-time safety checks with less runtime performance impact — but obviously there is a cost to bridge between C++ and that new language.


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

创业维艰

创业维艰

本·霍洛维茨 Ben Horowitz / 杨晓红、钟莉婷 / 中信出版社 / 2015-2 / 49

本·霍洛维茨,硅谷顶级投资人,与网景之父马克·安德森联手合作18年,有着丰富的创业和管理经验。2009年创立风险投资公司A16Z,被外媒誉为“硅谷最牛的50个天使投资人”之一,先后在初期投资了Facebook、Twitter、Groupon、Skype,是诸多硅谷新贵的创业导师。 在《创业维艰》中,本·霍洛维茨从自己的创业经历讲起,以自己在硅谷近20余年的创业、管理和投资经验,对创业公司(尤......一起来看看 《创业维艰》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

html转js在线工具
html转js在线工具

html转js在线工具

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具