Page MenuHomeFreeBSD

stack_protector: Add tunable to bypass random cookies
ClosedPublic

Authored by cem on Apr 16 2019, 5:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 6, 1:11 AM
Unknown Object (File)
Mon, Oct 6, 12:47 AM
Unknown Object (File)
Wed, Oct 1, 2:56 PM
Unknown Object (File)
Wed, Oct 1, 2:07 AM
Unknown Object (File)
Tue, Sep 30, 6:38 AM
Unknown Object (File)
Mon, Sep 29, 3:24 AM
Unknown Object (File)
Sun, Sep 28, 4:25 PM
Unknown Object (File)
Sun, Sep 28, 3:44 PM
Subscribers

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 - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Add CTASSERT that nitems(__stack_chk_guard) matches our expectations.

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

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

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

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.