Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glibc: enable stackprotection hardening #18522

Merged
merged 1 commit into from
Sep 12, 2016

Conversation

fpletz
Copy link
Member

@fpletz fpletz commented Sep 12, 2016

Enables previously manually disabled stackprotector (#1) and stackguard randomization.

From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511811:

If glibc is built with the --enable-stackguard-randomization option, each application gets a random canary value (at runtime) from /dev/urandom. If --enable-stackguard-randomization is absent, applications get a static canary value of "0xff0a0000". This is very unfortunate, because the attacker may be able to bypass the stack protection mechanism, by placing those 4 bytes in the canary word, before the actual canary check is performed (for example in memcpy-based buffer overflows).

@domenkozar Provided it doesn't break any builds, can we maybe get it into 16.09? We missed this in #12895 and we feel it's important. Unfortunately a full rebuild is required. 😞

cc @vcunat

Enables previously manually disabled stackprotector and stackguard
randomization.

From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511811:

    If glibc is built with the --enable-stackguard-randomization option,
    each application gets a random canary value (at runtime) from /dev/urandom.
    If --enable-stackguard-randomization is absent, applications get a static
    canary value of "0xff0a0000". This is very unfortunate, because the
    attacker may be able to bypass the stack protection mechanism, by placing
    those 4 bytes in the canary word, before the actual canary check is
    performed (for example in memcpy-based buffer overflows).
@fpletz fpletz added 1.severity: mass-rebuild This PR causes a large number of packages to rebuild 1.severity: security Issues which raise a security issue, or PRs that fix one labels Sep 12, 2016
@mention-bot
Copy link

@fpletz, thanks for your PR! By analyzing the annotation information on this pull request, we identified @edolstra, @elitak and @vcunat to be potential reviewers

@copumpkin
Copy link
Member

In favor of squeezing it into 16.09, myself.

@domenkozar domenkozar added this to the 16.09 milestone Sep 12, 2016
@domenkozar
Copy link
Member

domenkozar commented Sep 12, 2016

Sure, but let's create a staging-16.09 branch from 16.09 to always have binaries on release-16.09

(I also feel something else might come up in a week or so, then we can get these changes in together).

@vcunat vcunat merged commit 3ba99f8 into NixOS:staging Sep 12, 2016
@vcunat
Copy link
Member

vcunat commented Sep 12, 2016

I was able to build lots of packages without any problem. In standard staging now; Hydra building already.

@fpletz fpletz deleted the fix/glibc-stackprotection branch September 13, 2016 04:54
@fpletz
Copy link
Member Author

fpletz commented Sep 13, 2016

We have not seen any build failures on our hydra either, so should be safe.

I've created a staging-16.09 branch. Can somebody please add a jobset to Hydra?

@vcunat
Copy link
Member

vcunat commented Sep 13, 2016

Maybe we could wait anyway for the regular staging to finish its rebuild (~10k queued ATM), but it seems very unlikely to cause a mass breakage.

@domenkozar
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.severity: mass-rebuild This PR causes a large number of packages to rebuild 1.severity: security Issues which raise a security issue, or PRs that fix one 8.has: changelog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants