Ticket #1128 (closed task: fixed)

Opened 10 months ago

Last modified 10 months ago

switching from "-fstack-protector" to "-fstack-protector-strong" in Fedora 20

Reported by: halfie Owned by:
Priority: major Keywords: security,hardening,packaging,meeting
Cc: jakub Blocked By:
Blocking:

Description

Proposal

The new compiler flag "-fstack-protector-strong" in Fedora 19's gcc achieves a better balance between security and performance (when compared against the default -fstack-protector and available -fstack-protector-all options).

I am proposing to switch from using the "-fstack-protector" flag to "-fstack-protector-strong" in Fedora 20. The switch involves changing a single line in /usr/lib/rpm/redhat/macros file.

  1. In preliminary benchmarking, using "-fstack-protector-strong" did not result in any performance regressions.
  1. Benefit over "-fstack-protector-all" => gains big performance while sacrificing little security.
  1. Benefit over the current default "-fstack-protector" => "-fstack-protector" is regarded as "not secure enough" (only "protects" < 2% functions in Chromium project). "-fstack-protector-strong" hits the balance between the over-simplified "-fstack-protector" and over-killing "-fstack-protector-all".
  1. Google Chromium project has been using this compiler option for over an year now with "no securiy degradation".
  1. FWIW, "-fstack-protector-strong" evaluation and possible inclusion is on Ubuntu's road-map as well.

(I have paraphrased and summarized multiple posting by Han Shen, the developer of "-fstack-protector-strong" patch).

Details

  1. The design and implementation of "-fstack-protector-strong" can be found at,

https://docs.google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU/

The stack-protector option is over-simplified, which ignores pointer cast, address computation, while the stack-protector-all is over-killing, using this option results in too much performance overhead.

"-fstack-protector-strong" tries to hit the balance between an over-simplified version and an over-killing protection schema.

  1. "-fstack-protector-strong" chooses more functions to be protected than "stack-protector", it is a superset of "stack-protector", for functions not chosen by "stack-protector". "stack-protector-strong" will apply protection if any of the following conditions meets.
  • if any of its local variable’s address is taken,as part of the RHS of an assignment
  • or if any of its local variable’s address is taken as part of a function argument.
  • or if it has an array, regardless of array type or length
  • or if it has a struct/union which contains an array, regardless of array type or length.
  • or if function has register local variables

I am currently working on running more benchmarks.

Change History

comment:1 Changed 10 months ago by sgallagh

  • Keywords security,hardening,packaging,meeting added; security,hardening,packaging removed
  • Cc jakub added

Setting "meeting" keyword.

This certainly seems beneficial to the system, provided of course that additional performance testing doesn't show a significant degradation.

CCing Jakub for his input.

comment:2 in reply to: ↑ description ; follow-up: ↓ 3 Changed 10 months ago by mitr

Replying to halfie:

  1. Benefit over the current default "-fstack-protector" => "-fstack-protector" is regarded as "not secure enough" (only "protects" < 2% functions in Chromium project).

I don't have a strong opinion on the proposal in general; however, this specific claim is being inherited from one proposal to another and shouldn't stand: "percentage of of functions affected by the compiler option" is useless as a measure.

"Percentage of vulnerabilities mitigated" or "percentage of attacks prevented" would be the relevant measures - much more difficult to estimate, sure, but that doesn't make the "percentage of affected functions" useful, even in comparison.

Also, it seems to me rather suspect that the option can have both much higher coverage and no performance impact. The option is adding extra instructions to every affected function, so how is that possible?

Last edited 10 months ago by mitr (previous) (diff)

comment:3 in reply to: ↑ 2 Changed 10 months ago by halfie

Replying to mitr:

Replying to halfie:

  1. Benefit over the current default "-fstack-protector" => "-fstack-protector" is regarded as "not secure enough" (only "protects" < 2% functions in Chromium project).

I don't have a strong opinion on the proposal in general; however, this specific claim is being inherited from one proposal to another and shouldn't stand: "percentage of of functions affected by the compiler option" is useless as a measure.

Agreed.

I should have mentioned that Google was using "-fstack-protector-all" (probably due to "-fstack-protector" being found "inadequate") earlier. They switched to using "-fstack-protector-strong" around January 2012.

"Percentage of vulnerabilities mitigated" or "percentage of attacks prevented" would be the relevant measures - much more difficult to estimate, sure, but that doesn't make the "percentage of affected functions" useful, even in comparison.

Measuring or even estimating "Percentage of vulnerabilities mitigated" is a very HARD problem to solve on a large scale I think.

My "ssp-coverage" utility (https://bitbucket.org/dhiru/ssp-coverage/src) can help in determining how many function stacks are being protected by stack canaries.

Also, it seems to me rather suspect that the option can have both much higher coverage and no performance impact. The option is adding extra instructions to every affected function, so how is that possible?

I agree with your reasoning.

Maybe after reading http://www-plan.cs.colorado.edu/diwan/asplos09.pdf, I will get some answers.

comment:4 Changed 10 months ago by notting

Jakub - any comments?

comment:5 Changed 10 months ago by jakub

I have no problem with enabling -fstack-protector-strong for hardened packages, and for others as long as benchmarks show it doesn't introduce significant overhead. I'll just note that -fstack-protector-strong option is significantly less tested than -fstack-protector, which is included even in gcc %check build time testing; if -fstack-protector-strong is switched on by default, I could switch %check to test -fstack-protector-strong instead though.

comment:6 follow-up: ↓ 7 Changed 10 months ago by notting

From 2013-06-26 FESCo meeting:

AGREED: Will switch from "-fstack-protector" to "-fstack-protector-strong" in Fedora 20. Any reversion based on poor benchmarks must be decided before any F20 gcc mass rebuild (+:6, -:0, 0:0)

Halfie - please file a bug/patch for redhat-rpm-config?

comment:7 in reply to: ↑ 6 Changed 10 months ago by halfie

Replying to notting:

From 2013-06-26 FESCo meeting: Halfie - please file a bug/patch for redhat-rpm-config?

Done. https://bugzilla.redhat.com/show_bug.cgi?id=978763

Patch uploaded too.

Last edited 10 months ago by halfie (previous) (diff)

comment:8 Changed 10 months ago by sgallagh

  • Status changed from new to closed
  • Resolution set to fixed

At the FESCo meeting on 2013-07-03, this ticket was declared complete. We will follow up on Bugzilla to ensure that the patch lands in time for the F20 mass-rebuild.

Note: See TracTickets for help on using tickets.