Page MenuHomeFreeBSD

stack_protector: Add tunable to bypass random cookies
ClosedPublic

Authored by cem on Apr 16 2019, 5:02 PM.

Details

Summary

Add the new tunable, "security.stack_protect.permit_nonrandom_cookies," in
order to continue boot with insecure non-random stack cookies if the random
device is unavailable.

For now, enable it by default. This is not safe. It will be disabled by
default in a future revision.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

cem created this revision.Apr 16 2019, 5:02 PM
cem added a reviewer: imp.Apr 16 2019, 5:12 PM
cem updated this revision to Diff 56259.Apr 16 2019, 5:16 PM

Add CTASSERT that nitems(__stack_chk_guard) matches our expectations.

cem added a comment.Apr 16 2019, 6:00 PM

Tinderbox passes. I'd appreciate expediency on this one, if possible.

emaste accepted this revision.Apr 16 2019, 6:06 PM

I'm fine with this as an immediate fix for the installer/VM boot issues.

Please expand the commit message a little bit, in that this change is effectively restoring the status quo prior to rS346250.

This revision is now accepted and ready to land.Apr 16 2019, 6:06 PM
imp accepted this revision.Apr 16 2019, 6:29 PM

this is a reasonable stopgap, approved with the understanding that there will be follow on work to allow MD sources of entropy, like RDSEED on x86 etc

delphij accepted this revision.EditedApr 16 2019, 6:34 PM

For a stopgap fix I think it's fine. Note that it's probably better to derive __stack_chk_guard from SHA512 of something that we change often (e.g. __FreeBSD_version) concatenate with something that potentially varies, like getcyclecount(), for the fallback guard data: these are not secure random numbers, but would make it harder for an attacker to develop more generic smashing attack.

This revision was automatically updated to reflect the committed changes.