Intent to Implement: enable Control Flow Integrity for the official Linux Chrome build

[Ivan Krasin]

Hi all,

Contact emails

p...@chromium.org, kra...@chromium.org

Summary

Control Flow Integrity (aka CFI) is a set of schemes, which are designed to abort the program upon detecting certain forms of undefined behavior that can potentially allow attackers to subvert the program’s control flow. For example, it includes strict bad casts checking, and virtual calls checking. See more:

https://sites.google.com/a/chromium.org/dev/developers/testing/control-flow-integrity

http://clang.llvm.org/docs/ControlFlowIntegrity.html

CFI is already enabled on a Chromium.FYI buildbot, and on ClusterFuzz. At this moment, Chrome is known to be bad-casts free (minus a very recent regression, which should be fixed today, https://crbug.com/541708).

We would like to enable this defense mechanism for the official Chrome build on Linux, as it would make writing exploits a bit harder. Later, we would like to implement this feature for other OSes too.

Costs / concerns

The runtime cost is small, less than 1% of CPU. It increases the size of the release Chrome binary by 7%-9%, and it requires an LTO (Link-Time Optimization) build, which slows down the linker by 3x-4x.

Potentially, it could increase the number of crashes of the browser, in case, if there's an existing condition when a bad cast happens, or there's a virtual call to already destroyed object. These are bugs, which must be fixed, and we believe we have reached the stage, where the only open bugs we have are regressions.

Tracking bug

https://crbug.com/464797

Please, raise your concerns, if you aware of any.

krasin

[Ryan Tseng]

From a infra/resource perspective, the main waterfall/cq trybots doesn't have enough resources to run with CFI on everywhere due to the 3-4x linker slowdown.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Ivan Krasin]

On Fri, Oct 9, 2015 at 3:43 PM, Ryan Tseng <hin...@chromium.org> wrote:

From a infra/resource perspective, the main waterfall/cq trybots doesn't have enough resources to run with CFI on everywhere due to the 3-4x linker slowdown.

It does not have to. We don't plan to enable CFI for dev builds. Only official builds are affected, and that's a small fractions of all buildbots, if I understand correctly. 

[Dirk Pranke]

On Fri, Oct 9, 2015 at 3:46 PM, Ivan Krasin <kra...@chromium.org> wrote:

On Fri, Oct 9, 2015 at 3:43 PM, Ryan Tseng <hin...@chromium.org> wrote:

From a infra/resource perspective, the main waterfall/cq trybots doesn't have enough resources to run with CFI on everywhere due to the 3-4x linker slowdown.

It does not have to. We don't plan to enable CFI for dev builds. Only official builds are affected, and that's a small fractions of all buildbots, if I understand correctly. 

We would probably want CFI enabled on the perf bots (which do official builds) as well, but that's still a relatively small fraction of the total # of builds.

-- Dirk

[Michael Moss]

Linux official build is already pretty fast (faster than the other platforms), so I'm not sure 3-4x linking hit is that big a deal. Definitely give PMOs a heads up though.

[Nico Weber]

Thank you for sending this intent!

On Fri, Oct 9, 2015 at 3:22 PM, Ivan Krasin <kra...@chromium.org> wrote:

Hi all,

Contact emails

p...@chromium.org, kra...@chromium.org

Summary

Control Flow Integrity (aka CFI) is a set of schemes, which are designed to abort the program upon detecting certain forms of undefined behavior that can potentially allow attackers to subvert the program’s control flow. For example, it includes strict bad casts checking, and virtual calls checking. See more:

https://sites.google.com/a/chromium.org/dev/developers/testing/control-flow-integrity

http://clang.llvm.org/docs/ControlFlowIntegrity.html

This says "Note that this scheme has not yet been optimized for binary size; an increase of up to 15% has been observed for Chromium." – is work in that area planned? For linux this isn't a blocker, but if you want to launch this on other platforms that are more sensitive to binary size (Android; probably Windows) the size overhead seems like a potential risk.

Since there are other security-related protections that we want to enable that cost binary size (and that are independent of each other in against what they protect form what I understand – e.g. https://code.google.com/p/chromium/issues/detail?id=533294#c9): Are there any guidelines for what the bar for turning on a mitigation technique should be?

 

CFI is already enabled on a Chromium.FYI buildbot, and on ClusterFuzz. At this moment, Chrome is known to be bad-casts free (minus a very recent regression, which should be fixed today, https://crbug.com/541708).

We would like to enable this defense mechanism for the official Chrome build on Linux, as it would make writing exploits a bit harder.

Is it possible to quantify "a bit"? Do you have a rough idea what percentage of exploits this affects?

(I'm only asking out of curiosity, I don't have concerns about launching this for linux.)

[Abhishek Arya]

On Sat, Oct 10, 2015 at 11:52 AM, Nico Weber <tha...@chromium.org> wrote:

Thank you for sending this intent!

On Fri, Oct 9, 2015 at 3:22 PM, Ivan Krasin <kra...@chromium.org> wrote:

Hi all,

Contact emails

p...@chromium.org, kra...@chromium.org

Summary

Control Flow Integrity (aka CFI) is a set of schemes, which are designed to abort the program upon detecting certain forms of undefined behavior that can potentially allow attackers to subvert the program’s control flow. For example, it includes strict bad casts checking, and virtual calls checking. See more:

https://sites.google.com/a/chromium.org/dev/developers/testing/control-flow-integrity

http://clang.llvm.org/docs/ControlFlowIntegrity.html

This says "Note that this scheme has not yet been optimized for binary size; an increase of up to 15% has been observed for Chromium." – is work in that area planned? For linux this isn't a blocker, but if you want to launch this on other platforms that are more sensitive to binary size (Android; probably Windows) the size overhead seems like a potential risk.

Since there are other security-related protections that we want to enable that cost binary size (and that are independent of each other in against what they protect form what I understand – e.g. https://code.google.com/p/chromium/issues/detail?id=533294#c9): Are there any guidelines for what the bar for turning on a mitigation technique should be? 

No formal guideline here, other than mitigation should have measured minimal / zero performance impact and should help to kill a Known pattern of security bugs in the past. Examples like Release assert in blink (e.g. vector.h), PartitionAlloc, Project Awesome (tsepez@), Oilpan (prevent UAFs), etc.

CFI is already enabled on a Chromium.FYI buildbot, and on ClusterFuzz. At this moment, Chrome is known to be bad-casts free (minus a very recent regression, which should be fixed today, https://crbug.com/541708).

We would like to enable this defense mechanism for the official Chrome build on Linux, as it would make writing exploits a bit harder.

Is it possible to quantify "a bit"? Do you have a rough idea what percentage of exploits this affects?

(I'm only asking out of curiosity, I don't have concerns about launching this for linux.)

We don't have exploits data, other than some incoming reports and rewards contests such as Pwn2own, Pwnium, etc. And this technique has been used quite commonly in those reports. Bad-casts continue to be the top three classes of bugs (other than integer overflow, use-after-free) and in the past we have had 167 vulnerabilities (also we had added source code annotations). 

[Primiano Tucci]

This says "Note that this scheme has not yet been optimized for binary size; an increase of up to 15% has been observed for Chromium." – is work in that area planned? For linux this isn't a blocker, but if you want to launch this on other platforms that are more sensitive to binary size (Android; probably Windows) the size overhead seems like a potential risk.

Confirm. On Android a ~10% [1] binary size hit seems rather large and effectively means cancelling the effects of several multi-quarter size reduction efforts [2]. You might want check this early with a Chrome for Android TPM if you plan to ship this on Android.

[1] Your post says 7-9, the doc that Nico pointed out says 15. I'm averaging out to 10%.

[2] Some examples that come on top of my head: linker relro packing, breakpad microdumps

[Anton Vayvod]

+Andrew Hayden who's pioneering the size reduction effort on Android

--

[Ivan Krasin]

On Sat, Oct 10, 2015 at 11:52 AM, Nico Weber <tha...@chromium.org> wrote:

Thank you for sending this intent!

On Fri, Oct 9, 2015 at 3:22 PM, Ivan Krasin <kra...@chromium.org> wrote:

Hi all,

Contact emails

p...@chromium.org, kra...@chromium.org

Summary

Control Flow Integrity (aka CFI) is a set of schemes, which are designed to abort the program upon detecting certain forms of undefined behavior that can potentially allow attackers to subvert the program’s control flow. For example, it includes strict bad casts checking, and virtual calls checking. See more:

https://sites.google.com/a/chromium.org/dev/developers/testing/control-flow-integrity

http://clang.llvm.org/docs/ControlFlowIntegrity.html

This says "Note that this scheme has not yet been optimized for binary size; an increase of up to 15% has been observed for Chromium." – is work in that area planned? For linux this isn't a blocker, but if you want to launch this on other platforms that are more sensitive to binary size (Android; probably Windows) the size overhead seems like a potential risk.

 On Chrome, the real code size penalty is between 7% and 9%. We'll work on reducing this penalty before launching on Android and others. 

Since there are other security-related protections that we want to enable that cost binary size (and that are independent of each other in against what they protect form what I understand – e.g. https://code.google.com/p/chromium/issues/detail?id=533294#c9): Are there any guidelines for what the bar for turning on a mitigation technique should be?

 

CFI is already enabled on a Chromium.FYI buildbot, and on ClusterFuzz. At this moment, Chrome is known to be bad-casts free (minus a very recent regression, which should be fixed today, https://crbug.com/541708).

We would like to enable this defense mechanism for the official Chrome build on Linux, as it would make writing exploits a bit harder.

Is it possible to quantify "a bit"? Do you have a rough idea what percentage of exploits this affects?

(I'm only asking out of curiosity, I don't have concerns about launching this for linux.)

 

One simple example would be preventing a virtual call by the object reference, that has already been destroyed. If the memory, where vtable is stored, is claimed by JavaScript, and a malicious script puts its own vtable there to invoke a naive function inaccessible otherwise, CFI would detect that and won't allow to happen. There's more examples in the paper: http://www.pcc.me.uk/~peter/acad/usenix14.pdf